Building your firewall, Part 1

Unix Insider –

I am often asked, "What is the best firewall?" -- a leading question if ever there was one. It reminds me of a time when I went to a popular cigar shop to purchase a humidor and cigars as a gift. I told the proprietor that I knew nothing about cigars, but would rely on his judgment to choose "the best." He explained that it really was a matter of taste, which was a point I could relate to my feelings about wine. I personally don't care for Chardonnay, no matter how expensive. A reasonably priced Margaux is more to my taste and, therefore, the better wine for me.

Firewall selection is not much different. There are many types that suit different requirements. Simply purchasing "the industry leader" is not necessarily the best solution. There's more involved than installation. A firewall solution must be maintainable and adaptable as well.

Part 1 of this three-part series will focus on the planning stage of firewall architecture. We'll be focusing on what is required for a firewall rather than how to make one work, although the consequences of these decisions will be discussed as well. Next month, Part 2 will focus on the implementation issues, including platform security, installation, performance tuning, and maintenance.

What is a firewall?

Anyone who has worked with firewall technology at all should be familiar with the terminology used to describe it. I won't repeat here what has already been covered at length in Unix Insider and elsewhere.

My focus is more elemental. What do you consider a firewall to be? A network appliance that you drop in place and forget, or a design concept that must adapt to changing requirements? Firewall vendors seem to encourage the Internet toaster mindset. After all, the idea that you can drop something in place and forget about it is very appealing. While this certainly makes implementation easier, there can be significant hidden costs in both money and resources over time.

I consider a firewall to be more of a design concept rather than an Internet toaster. The goals of a system's design should be driven by the business initiatives, policies, and procedures of the particular organization. How, then, can a firewall be purchased off the rack and fit all my organization's needs exactly? The answer is that it can't. It must be tailored to fit. Well, in order to do any tailoring, you have to know what you're working with.

Many system administrators try to avoid performing an architecture review by purchasing from a vendor a one-stop shopping firewall solution that will do anything they might ever want to do. While this scattershot approach may seem to make sense, it might result in you supporting (and upgrading!) features that are not necessary. There is an old rule in system design that seems to have been ignored by firewall vendors: keep it simple, stupid (KISS). Choose the firewall that best fits your requirements, yet allows the flexibility to add additional applications as needed.

Technical expertise goals

Does it make sense for your organization to maintain staff with a high level of expertise? For a large company with a high demand for technical services, it does. For a small sewing shop with one system, it does not. The important thing to consider is the goal with regard to this branch of your organization. Evaluate what you want from your technical staff, not the expertise of the present staff. In regards to firewall selection, this determination is important in deciding whether you need a point-and-click interface or an adaptive model that a highly technical person can integrate with other solutions. If you have a high-quality technical department, you may want to consider integrating some open source solutions with vendor products.

I recently went through a complete kitchen renovation -- an enormous task in which the kitchen was gutted down to the subfloor. It occurred to me that renovating the kitchen could serve as a good metaphor for building a new security infrastructure. The typical solution for the average person is to go down to the local building center, pick out some ready-made cabinets, and have someone from the building center plug in the standard cabinet sizes and appliances into the available space. There's usually a lot of compromise necessary to accommodate the products chosen.

Homeowners could also opt to install such cabinets themselves if they are assured of an easy installation with no special tools required. As installation commences, however, they may soon discover that not one of their support walls is plumb. The solution that is then considered the most desirable is to have custom cabinets made by a skilled craftsman. Homeowners get exactly what they want and need with no wasted space. The downside is that this is very expensive.

Another alternative is to build your own kitchen cabinets. This requires some pretty sophisticated skills (and tools). We considered all the renovation projects that we had done and planned to do in the future and decided that it was worth the initial outlay in time and effort.

For some organizations -- particularly consulting companies -- it makes sense to develop in-house technical skills. Hands-on experience is much more effective than sending staff out for training. If the organization does not have the technical expertise, a consultant can be brought in to direct the project and provide training.

Policy review

Many organizations do not have an appropriate security policy that reflects the objectives of the organization -- that is, until there is an incident. While the site security policy should not specify the exact brand of firewall to implement, it should at least suggest an acceptable architecture. A review of the policy should produce a prioritized list of objectives for evaluating firewall products.

Auditing requirements

If the site intends to take action on security incidents, then it is important to gather the appropriate data for evidence. Be sure to review local requirements for gathering evidence. Intrusion detection mechanisms range from simple logging on the firewall to separate systems whose sole purpose is to trace all network traffic. The site policy should suggest the importance of intrusion detection logs and the manner in which they should be reviewed and archived. If it is a priority for the site to pursue every security incident, there should be a reporting interface that filters the data for timely review. While it may sound like a good idea to have 24/7 intrusion detection, make sure you have the staff to support this and an appropriate procedure to follow if problems arise. I know I wouldn't want to get called at 3:00 a.m. because someone tried to telnet to my firewall.

If you never plan to press charges for security violations, an elaborate logging mechanism adds unnecessary cost and complexity. However, even if a site has no plans to pursue security incidents, some form of logging is necessary for debugging problems.

Filtering

Any action that requires data-stream interpretation is going to adversely affect the performance of the firewall. If additional security benefits are achieved by this, the performance hit may be acceptable. If the systems on your network are vulnerable to viruses, some benefit may be derived by deploying a firewall with virus scanning capabilities. One question to keep in mind, though: if encrypted data is permitted, can the scanner recognize an encrypted virus in the data stream?

There are other forms of filtering that generate little security benefit, but may be required for other reasons. Some sites want to restrict which users may use HTTP, or even which Web sites are permitted. My personal feeling is that this type of filtering adds too much complexity for a feature that can be circumvented. There is a lot of maintenance overhead to consider as well.

Authentication

Some sites require authentication for outbound sessions. If this is the case, the firewall must support it in a manner that is easy to maintain. Will users be able to change their password? Does the firewall permit this? How is the user database stored? Can user records be moved between firewalls easily? Would the technical staff be able to write custom scripts to manipulate the user database?

Remote access

Will inbound sessions be required? If so, what are the requirements the for authentication and encryption of those sessions? You may already be using a token device, such as SecurID, for the authentication of inbound sessions. There are many one-time password mechanisms available; make sure the firewall supports yours. You may also want to consider using a virtual private network (VPN) to encrypt the session. Many firewalls come with a VPN rolled in. My preference is to use a third-party VPN so that, if I decide to use a different firewall later, I won't have to worry about changing the VPN and all the client machines that use it. If you decide to use the firewall vendor's VPN, be sure to determine if the VPN is tied into the firewall software version. Otherwise, you may find yourself trying to coordinate firewall upgrades with other sites just so the VPN will work.

Architecture review

Whether you presently have a firewall or not, your current architecture must be reviewed to determine if it is able to support the new architecture, and vice versa. Some of the technical considerations follow.

Performance requirements

Applying security to an architecture usually has an adverse effect on performance. It is important to first determine the acceptable trade-off between security and performance for the site. Many security experts will tell you that security should never be sacrificed for functionality, but the reality is that almost every firewall evaluation test emphasizes performance. Management needs to have a thorough assessment of the risks involved in order to determine what is acceptable. For example, if a brokerage house is performing trades, a significant slowdown in the execution of the trade could cost more money than a minor security risk. However, it should be noted that a misconfiguration that slows down performance does not add to security! Performance issues will be discussed in more detail next month. For now, just determine your requirements.

Application and network requirements

What type of network traffic must be supported? Will you need network address translation (NAT)? Static routing? Dynamic routing? Will simply masquerading a block of internal addresses be sufficient? A poor understanding of the requirements can lead to implementing a complicated architecture that might not be necessary. For example, NAT provides a mechanism that allows internal systems to have a unique public IP address. It might not be necessary unless the application on the public side of the firewall needs to initiate the communication. In many cases, applications are originated by the internal system; as a result, the return route is known. In these cases, using a masqueraded address is sufficient.

The applications that must be supported dictate the technical aspects of the firewall. Determine the protocols and services the applications require:

  • Use of TCP-based connections (such as telnet or FTP) must be accompanied by an evaluation of your usage requirements. Do you need to limit by user or time of day? Does the service need to be proxied?

  • UDP-based services are usually considered dangerous for an external firewall. I'd recommend looking for alternatives, but if you have to support UDP, consider NAT or stateful inspection-based firewalls.

  • If you have private data feeds, it is strongly recommended that you deploy a separate intranet firewall. This allows you to maintain security with other sites without potentially exposing them to the Internet by putting them on the same firewall.

  • Internal routing table issues determine if NAT or stateful inspection can be used. If you have UDP-based services, you are probably looking at using a NAT or stateful inspection firewall rather than one that is proxy based. However, neither NAT nor stateful inspection will work if you can't route the traffic to them. A proxy-based firewall works with applications that can handle the definition of the proxy, so you do not need routes or DNS to Internet networks on your private network. An example of this is Netscape or RealAudio, which allow you to define a proxy to which to send the traffic. Be sure to check with your networking people on this.

  • Some application clients utilize SOCKS. Almost any firewall can support this, but if you must have this support, it is best to double-check. Many vendor applications now support a SOCKS 5-based proxy that can be added to most firewalls.

  • Do you need to support X Windows through the firewall? There are some major security implications with using X in this way. For outbound X support, an application proxy works well. For inbound, I would use a VPN. Be aware that, aside from the security issues, there is a lot of overhead. Make sure you really have to have this feature and that you can secure it.

  • What operating system platform is acceptable? This is getting into the territory of religious debate, but I always recommend a hardened Unix platform. Whatever your choice, be sure to evaluate all the risks and apply all security patches.

Support and maintenance issues

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