Temporary employees can present special security challenges for network administrators. Here's how you can control where guest employees go by using reverse firewalls.
As IT specialists and technicians, we always do our best to provide the solutions our customers need, all the while trying to standardize as much as possible in order to make our lives a little easier as well. However, sometimes our customers' needs are so specific that they require a fully customized solution.
I ran into this myself when one of the departments in the R & D shop I support brought in a developer to design and implement a custom application. This didn't sit too well with me, since I didn't want this person to have full access to the LAN. The problem was that I couldn't just disconnect him from the network since his application interfaced with Oracle databases on our LAN. So what did I do? I decided to investigate reversing the firewall concept.
The other side of the wall
Firewall software or hardware is typically designed to keep people from the outside out while the local users can do almost whatever they want. In this case, I needed to limit the local user's access to the LAN while keeping the workstation fully visible from the network. This allowed my staff to still be able to remotely support the firewalled workstations just like all the other workstations in my environment.
I purchased a copy of Symantec Firewall and installed it on the workstation the developer was going to use. The great thing about this software is that even though the local user has administrative rights to the workstation, you can configure it so that it still requires a password to configure or terminate. (Note: Other software might have comparable functionality, but for the purposes of this article, I'm focusing only on Symantec's offering.) This was a big relief since, wouldn't you know it, the software being developed required local admin rights to run. Now that I had the tool in place, I needed to adapt it to my predicament.
Designing firewall rules
Designing firewall rules isn't as hard as it sounds. The tricky part is identifying all of the services/ports that you want to allow. This may take some research depending on the services you need to provide to the workstation. The second part is designing the actual rules, which, once you get into the right mindset, is really easy. Let me use my developer situation as an example.
Let's say that my corporate LAN/WAN spans IP addresses 192.168.1.1 to 192.168.254.254 using a 24-bit subnet mask. The developer works from a Windows workstation using a local user account, so we don't have to worry about network authentication against a server. His application needs access to two Oracle database servers at IP addresses 192.168.100.100 and 192.168.200.200 on ports 1521 and 2021, respectively.
In this case, the ports were easy to identify since the developer told me what database instances were going to be used. I just needed to check the local TNSNAMES file to find out what ports they corresponded to on the remote Oracle host.
Since I didn't want the firewall software to assume its traditional role of protecting the computer from the outside, I had to delete all existing default rules and start from scratch. I know that I need to provide access only to a single port on two different IP addresses, so I basically need to design rules that black out the rest of the network.
To get into the right mindset, you'll want to break your network down to the port level. This is easier than it sounds. For this example, it's safe to say that I won't want our guest to have access to any IP addresses from 192.168.1.1 to 192.168.100.99. Then for IP address 192.168.100.100, where the first Oracle server is, you'll want only port 1521 to be available. This means ports 1 through 1520 and ports 1522 through 65536 should be blocked. Do you see a pattern emerging?
There are two more dimensions that make this a three-dimensional problem. The protocol used to address these ports also needs to be identified (TCP or UDP) along with the direction of the traffic. The trick is to see the network addresses and ports as some sort of complex series of numbers with a beginning and an end. Instead of just a straight series of decimal numbers starting at 1 and ending at 100, your LAN starts at the "lowest" address of 192.168.1.1, port 1 (192.168.1.1:1). Because there are a potential 65,536 TCP/IP ports on any address, you'll reach port 65536 on 192.168.1.1 (192.168.1.1:65536) before you move on to port 1 of 192.168.1.2 (192.168.1.2:1).
As far as rule design is concerned, most firewall software will allow you to specify either address or port ranges. There will therefore be two kinds of rules: the ones that span ranges of addresses and cover all ports for those addresses, and the ones that pertain to specific ports or port ranges for a particular address. If I continue with the same methodology, I'll end up with the configuration as being appropriate for this situation, as shown in Table A.
Note that the rules allowing communication to the database ports should probably be restricted to the appropriate protocol only. This also means that another rule has to explicitly block traffic for the unused protocol on the same port.
Identifying required ports and more complex scenarios
Of course, most scenarios will require a little more research in identifying required ports/services, but the basic principle for rule creation remains the same. For example, if a user in the same situation requires Windows authentication and access to file shares, rules to allow for communication to the appropriate ports on the domain controller or file server will need to be configured. You can find more information on specific ports by checking out the article "Ports: What's in and what's not."
Don't forget security at other levels
In this article, you saw how I blocked almost the entire network from our guest by using a simple reverse firewall. However, don't forget that there may be other security vulnerabilities on your network for guest users. For example, credentials provided for the Oracle database might grant the user access to data that isn't meant to be seen. Also, in the case of a file share, make sure the permissions are set appropriately at the share and file levels so that sensitive data is not viewable.
Blocking IP addresses and ports isn't everything. The ports that remain open may also provide information or services that aren't required, and you must take this into consideration in order to obtain a secure environment for your guest. The more ports you open, the more exploits you're making your systems vulnerable to. Furthermore, all of this work will be in vain if this guest can potentially have unsupervised physical access to a computer that isn't configured in this manner. Remember, any security system is only as good as its weakest link.