Building your firewall, Part 3

Unix Insider –

Last month's column described the operating system installation that lays the groundwork for firewall implementation.

Implementing firewall software is not really that hard. Maintaining it is. If you can take a step back and look down the road at the possible traffic jams, you can make maintenance easier by spending a little extra time with the implementation. This column will attempt to offer some advice that could save you some maintenance headaches.

I always find that examples are the best way to explain a point. The problem with using examples when discussing firewalls is that there are many types to choose from. Trying to give examples of each would be tedious (assuming that I even could). To keep it simple, I'll try to stick to general issues and give examples from two of the most popular firewalls available: Checkpoint Firewall-1 (stateful inspection) and TIS Gauntlet (proxy). This is not to be construed as an endorsement of either -- I'm just more familiar with these.

Know your firewall

It doesn't matter what type of firewall you are installing; you're going to have to take the time to learn it. For vendor-proprietary firewalls, this means that you will probably have to take a class to learn the vendor interface. Of course, this does not necessarily make you a firewall expert, but it is worth taking the time to learn how to use the product in the manner intended. Some vendors are pretty good at supporting backward compatibility so that future releases just require reading over the documentation.

For a firewall based on open source standards, there is more that you have to learn, and the management interface may not be as easy to use. The bright side is that the technology learned can be used in other places. Once you develop the technical skills, you can customize the firewall.

Prune the architecture

It's easy to get carried away when designing a security architecture. Just remember, the more complex you make it, the harder it will be to maintain with efficient performance. Once you've learned more about the particular firewall that you are implementing, see where you can streamline the architecture. For example, if you are requiring users to authenticate on the firewall before going out to Web sites, you will take a performance hit and add a lot of maintenance. Is it worth it? If it is that important to make sure that users are not going to inappropriate sites, it might be better to implement a Web-caching product that also provides filtering.

Along with the services, consider how many firewalls are in the architecture. If you're looking at an architecture with more than 50 firewalls, you will need a centralized management mechanism. For very large implementations, a firewall farm that runs on high-capacity systems may be a more efficient method than maintaining hundreds of little firewalls. Some firewalls support load balancing, which uses the resources efficiently and provides redundancy.

Can't get there from here

Quite a lot of time is wasted in firewall implementations because the basic network connectivity is not there. It cannot be stressed enough: test your network routes before you even begin to install the firewall software. Otherwise, you will find yourself wasting an inordinate amount of time trying to debug firewall rules when it's not a firewall problem. Almost every firewall admin I know uses

<font face="Courier">traceroute</font>
and
<font face="Courier">snoop</font>
for testing. In his Unix Insider column last month, Peter Galvin brought up a very useful feature of the Solaris
<font face="Courier">route</font>
command called
<font face="Courier">route get</font>
. I found this to be immediately useful during a firewall implementation recently (thanks, Peter!):

<font face="Courier"># route get ns2.someplace.com
   route to: ns2.someplace.com
destination: default
       mask: default
    gateway: rtr-r-37.company.com
  interface: le0
      flags: <UP,GATEWAY,DONE>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu
expire
       0         0         0         0         0         0      1500
0

#
</font>

The nice thing about this command is that it tells you the netmask and interface that is being used. The fact that it is native to Solaris is another plus.

Have you seen my keys?

Have you ever found yourself frantically searching for your car keys when you're already late for something important? It's frustrating that something as mundane as misplaced keys can have such an impact. Vendor firewalls have license keys with various mechanisms for activation. Don't wait until you have firewall consultants waiting to configure the firewall to find out how to activate the keys. Make sure you understand how the license keys work. An incorrect date on your system could keep the licensing from working. Make extra copies of the license keys (including a hard copy) and keep them in a safe place.

Firewall rules

Blue laws

It is a source of amusement for many people to review the so-called blue laws of a region. These silly, outdated laws are technically enforceable, but no judge in his right mind would uphold them. As humans, we rely on our common sense to determine if a rule is appropriate. Computers have no common sense -- they just do what they are told no matter how silly it is. With a firewall, it is critical to keep the rulebase as efficient as possible and to periodically review the rules to make sure they are still relevant. It is better, of course, to write good rules in the first place.

Anyone with a computer science background is familiar with the flowchart model that should be written before the actual program. It helps to define the flow of logic so that an efficient program can be written. While it's tempting to avoid this step, it could help prevent problems later. It doesn't matter what level of Brand X certification you have; if you don't fully understand the logic of what you are doing, you will probably write sloppy rulebases. Don't expect the requesting organization to know how to word its request. Often, a request could be worded as, "We need all our people to get to vendor X to use the SOME_APP service." Not very helpful, is it? If this is how you get your requests, you will be spending a lot of time on the phone with follow-up calls chasing down information. It is easier to have a form that specifies the required information, such as:

<font face="Courier">Name of Requestor: John Doe

Department: XYZ

Reason for request: The application is required to provide a database
lookup service from Vendor X to users in group A.

Name of application: SOME_APP

Connection initiation: (I) Internal (E) External B (Both): I
(who opens the connection)

IP Address of Server(s):  183.17.53.42/32
(the destination side)
IP Address Client(s):  192.168.10.0/24
(the source side)
Type of service and port:  TCP/5678

Users who will use this service:  All

Type of authentication (Internal services Only):  (P) Password (T) Token (N)
None: N

Service Access Time Period:  Any

Originating Dept. Approval:  manager from XYZ

Firewall Dept Approval:  Firewall group manager
</font>

Even with all this information, don't hesitate to question the request. If you need to provide a connection to an external vendor for a service, it is up to the vendor to require and support authentication. Unless there is a good reason for it, the source of the connection could be defined to be anywhere in your address space. If you write very tight rules on a per-workstation basis, you might find yourself constantly updating rulebases when people move around.

I've seen some rules written badly because the administrator was confused about how the TCP/IP protocol works. Administrators could mistakenly think that they have to write a rule for both directions in order to provide a return route.

For example (using a Checkpoint format), the above requirement may be written like this:

<font face="Courier">Source       Destination     	Service        	Action  Track   Install Time
My_net       Their_net        	SOME_APP  	accept  short   My_fw1  Any
Their_net     My_net          	SOME_APP 	accept  short   My_fw1  Any
</font>

If the application does not originate from the external network, the second rule is useless at the very least. Some admins may not realize that the TCP/IP protocol keeps track of the return route to the originator of a connection, and that it is unnecessary to write a rule for it. In fact, the other rule would allow the other side to open connections to the client side on the SOME_APP port. If you are lucky, you might not be running any process that is listening on that port. If you do have such a process, you have opened a hole in your infrastructure. Understand your rules before you create them.

Definitions

The next step in writing a program is to define the variables. Each administrator has a different style that becomes her own personal standard. The problem arises when you have multiple administrators maintaining multiple firewalls. It is very likely that the same variable names will be chosen with different definitions. Aside from the administrative headache of having to look them up all the time, there is an even bigger headache if you have to move an application to another firewall.

It will look like the network objects are defined, but they may not have the values that the application requires. Changing the values will break another application. For a very large installation, it helps to establish a standard.

While I personally hate long variable names, I must grudgingly admit that more descriptive names make maintenance easier. For host names, you may want to incorporate the IP address into the name of the application, as in

<font face="Courier">h1.2.3.4_VendorX</font>
. For service names, you might want to choose something like
<font face="Courier">t5678.SOME_APP</font>
. Just make sure everyone follows the same standard. Also, don't just start renaming objects to follow a new standard without planning it out!

Now we can take the form and fill in variable names for the rule:

<font face="Courier">Remote host IP:   1.2.3.4
Remote host name: h1.2.3.4_VendorX
Service type and port:  tcp 5678
Service name:   t5678.SOME_APP
</font>

The TIS Gauntlet package can use the same information to generate the new rules. You can use the GUI interface to define the new services (e.g., simple plug-gw), set down the rules for which addresses can use it, which addresses they can go to, what port to use, the users who are allowed to use it, and even a time of day for the use of the service. And for those of you who are feeling macho enough to set up rules without the GUI, you can always edit

<font face="Courier">netperm-table</font>
. I personally wouldn't recommend it except in a case in which you are testing out rule changes to make sure you have the correct rules. Just make sure you go back to the GUI and update the rules there. The following is an example from a TIS Gauntlet
<font face="Courier">netperm-table</font>
with some comments:

1 2 Page
Insider: How the basic tech behind the Internet works
Join the discussion
Be the first to comment on this article. Our Commenting Policies