Building your firewall, Part 1

Are you letting your firewall vendor decide your architecture?

Summary
Planning a firewall architecture is a time-consuming process. Many sites try to take shortcuts by installing a vendor firewall loaded with features that they might not need. In Part 1 of a three-part series, Carole discusses the importance of firewall architecture planning. (2,700 words)

WIZARD'S GUIDE TO SECURITY

By Carole Fennelly

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.

Series title: Read the whole series!

Part 1. Are you letting your firewall vendor dec ide your a rchitecture?
Part 2. How to make sure your OS i s ready to go

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 SunWorld and elsewhere. Peter Galvin wrote several excellent articles on the subject that are listed in the Resources section below.

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 (see the firewall comparison tests links in Resources). 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. There is an excellent white paper on NAT -- see Resources for the URL.

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
Many people fail to consider the maintenance issues of the firewall. With the rapid rate of change in the computer industry, a large organization may have to update the firewall frequently in order to support new requirements. For a very large infrastructure, this can become a nightmare. Some support and maintenance issues to consider are:

How many systems will be in the firewall architecture?
Is a central management station important?
How frequently will the firewall rules have to be modified?
Is it likely that on-the-fly solutions will be required? Would the technical staff be able to implement these easily? Are the vendor's engineers available, if necessary?

Intranet firewalls -- trust relationships
No matter how good the external firewall is, you may still be at risk. In large organizations, more than one division may have an Internet connection. The problem is that you can't control their security and, by trusting their network, you may be vulnerable.

For example, if you are in a brokerage environment, the trading desks may need to attach market data feeds to your network. Most market data vendors will simply convince the trading desk to hook their connection right to your network without going through a firewall. After all, the firewall will slow down the feed and make them look bad. However, in such a situation the market data vendor is controlling your security, because you are relying on them to protect you. Many vendors do provide security capabilities, such as secure lines and network segments to your site. The question is, are you willing to rely on them to make sure they don't make mistakes? I certainly don't with regard to either scenario.

An intranet firewall is a good tool for protecting yourself from the rest of the company. This type of firewall may be much more complicated than an Internet firewall. You will have company applications that may have to be passed through. You may also have market data vendors who have varying ways of supplying data, such as an X Windows-based delivery, FTP, etc. The point is that this firewall may be a very different beast from the external firewall. Where a stateful inspection may be appropriate for the external link with general services, a proxy may be better for an intranet firewall.

Final thoughts
There are, no doubt, other issues to consider. Every site is different and may have different issues. If you think of issues that you'd like to share, please send me email. If there's enough input, I'll post a comprehensive checklist that reflects the real requirements of the industry from the people who have to make it work -- not just the vendors. Next month, we'll examine firewall implementation and performance issues.

Disclaimer: The information and software in this article are provided as-is and should be used with caution. Each environment is unique and the reader is cautioned to investigate with his or her company as to the feasibility of using the information and software in the article. No warranties, implied or actual, are granted for any use of the information and software in this article and neither author nor publisher is responsible for any damages, either consequential or incidental, with respect to use of the information and software contained herein.

About the author
Carole Fennelly is a partner in Wizard's Keys Corporation, a company specializing in computer security consulting. She has been a Unix system administrator for more than 15 years on various platforms and has particularly focused on sendmail configurations of late. Carole provides security consultation to several financial institutions in the New York City area.