Building your firewall, Part 1

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

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.