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.