Author: Preston St. Pierre
are overpriced; proprietary firewall code leaves you at the mercy of
a vendor’s timetable in the event of a security hole; the cost of
underlying hardware/software platform for Windows is high and puts
you on an escalating upgrade path. As your company’s key IT
decision-maker you can’t afford to spend money needlessly nor ignore
even temporary security issues, so you’re thinking seriously about
deploying a Linux-based firewall solution. What do you need to know?
Network security is a broad topic, and while a good firewall is an
essential part of network security, it does not work in isolation. A
secure system also requires effective monitoring and intrusion
detection, as well as a “respond and restore” plan in the
event of a security breach. We’ll be restricting our discussion to
firewalls, but keep in mind that your firewall plan must coexist with
your other security measures.
In this article we’ll look at some of the decision considerations
in selecting a Linux-based firewall, including both considerations
specific to firewall technology and general considerations about
understanding Linux-based and open source options.
Firewall basics
A firewall is just a combination of two other network server
functions: a gateway and a proxy. A gateway machine is a facilitator:
before a computer on your local area network (LAN) can “talk”
to another computer on the Internet at large, it must know how to
find that computer and be able to establish a connection to it. A
gateway machine facilitates making this connection. All
Internet-bound traffic on your LAN passes through the gateway.
A proxy server is a mediator: it does not allow direct
communication between two computers, but rather acts as a go-between.
Neither end computer talks directly to the other, but instead they
talk to each other through the proxy. A consequence of this
arrangement is that a proxy server can filter the kinds of
communication are allowed between two computers.
A firewall, then, is both a facilitator and a mediator. It
facilitates by providing the gateway functions that all computers on
the LAN need to communicate outside. It mediates, in that computers
on the LAN have their communications proxied by, and potentially
filtered by the firewall.
How complex your firewall must be depends on what kind of network
traffic it must handle. This traffic falls broadly into two
categories: stateless and stateful (session-based). Stateless
firewalling is a relatively simple affair. Stateful firewalling adds
considerable complexity.
Statelessness and sessions
Stateless transactions refer to a situation in which a server
responding to a request need not know about previous requests in
order to respond. A simple Web page request is a classic example of a
stateless transaction: your browser requests all the files associated
with a particular Web page, and the Web server need not know whether
the same browser has previously requested other pages.
Obviously a great deal of network activity is session-based: VPN
access, extended database transactions, more complicated Web
interactions like online purchases. In some of these cases the
functionality of a session can be added at the application level.
This is the function that cookies often serve in Web transactions,
for example. Sometimes, however, session functionality must be
implemented at the network level; this level of session awareness is
required for VPN access, for example.
If users on your LAN require no more than email and Web access to
the Internet, then you’re operating in a stateless environment, and a
simple, out-of-the box firewall configuration for Linux should
suffice. If, on the other hand, your users have network session-based
requirements such as VPN access, then either your IT staff has some
additional work to do, or you need a commercial Linux solution.
The evolution of Linux firewalls
Firewall code has been included in standard Linux distributions
from early on. Alan Cox ported BSD’s ipfw firewall tool to Linux with
the 1.1 version of the Linux kernel, and this has been augmented with
ipfwadm, a more feature-rich extension of ipfw, and more recently by
ipchains. With ipchains you get a set of configuration files
(iptables) that specify what filtering rules to apply under what
conditions, as well as a set of commands for manipulating these
tables. For several years ipchains has been the standard for
firewalling in Linux.
These tools work well in a stateless environment. A Linux firewall
turns off unused or unwanted ports, and listens to network ports
designated by the system administrator configuring the firewall. The
firewall examines packets inbound and outbound on those ports, and
applies a set of rules (again, part of firewall configuration set by
the sys admin) to determine whether an individual packet should be
allowed. These rules can be based on allowable originating and
destination hosts, ports, packet header information, or any
combination of these. The firewall looks at each packet in isolation;
hence statelessness.
The stateless approach to firewalling comes at a price. A
stateless firewall offers a good balance of simplicity and security,
but with a resulting limitation in functionality. It’s as if you
locked all the doors and windows to your house except the front door,
and posted a security guard there. Sometimes it’s more convenient to
just give someone a key to another door. Providing for trusted use in
that sort of network environment, however, is more functionality than
a stateless firewall can provide. Session-based applications, such as
VPN access to applications on the company intranet, require this
higher level of functionality.
The current generation of firewalling code in Linux provides this
higher level of functionality. This code is based on netfilter,
a set of loadable kernel modules that extends Linux’s firewalling
capabilities to allow session-based packet examination. Performing
these operations at the kernel level increases performance, assuming
your IT staff is comfortable with configuring and compiling a custom
Linux kernel. Relying on kernel modules also means that when new
functionality is needed, it can be added on a module by module basis
without tampering with the kernel as a whole.
Netfilter is still relatively new; it debuted with the 2.4 Linux
kernel in January 2001. Consequently many of the front-end programs
intended to ease firewall setup and configuration are still based on
the older ipchains code (netfilter is backward-compatible with
ipchains). In other words, the most current firewall code in Linux is
quite powerful, but not as easy to work with as the older ipchains
code.
The problem of plenty
One of the most difficult problems in evaluating open source
software is not that there aren’t enough options; rather it’s that
there are too many.
Both Freshmeat and SourceForge
return hundreds of results in response to “firewall” as a
search term. These range from student and hobby projects in early
development stages to mature open source projects to vendor-supported
commercial solutions. Some are programs to install on a multi-purpose
Linux machine; others are software to turn a Linux machine into a
dedicated firewall device. Some assume a great deal of prior Linux
system administration knowledge, while others are designed to render
firewalling as much of a point-and-click solution as possible.
The first step in evaluating which packages might be right for
your organization is to choose whether you want to “roll your
own” solution or deploy an off-the-shelf package. The former
approach does not require significant financial commitment. It does
require a heavier initial investment in IT staff and resources during
the ramp up to deployment.
“Out of the box” configurations available on standard
distributions like Red Hat or SUSE require minimal financial and
staff time commitments. The same is true of fully supported
commercial Linux products, though they come with a significant
up-front price tag.
All of these considerations are part of the process of assessing
total cost of ownership (TCO). Open source products have a lower
up-front cost than commercial ones, but if your IT staff is not
familiar with the operating system on which the product runs, then
your resource commitment in time and personnel will be higher.
Furthermore, an open source product may be too complex or simply
impractical to implement if it needs to interoperate with other “off
the shelf” commercial software.
Fortunately a firewall is, by definition, a fairly self-contained
piece of software rather than a component of a more complex
application stack. For this reason alone it makes an excellent point
of entry into the IT world of Linux.
Don’t assume that a Linux firewall is going to be less “user
friendly” to your system administrators. Linux software may have
deserved that reputation three or four years ago, but the whole area
of Linux application user interface design has undergone steady and
significant improvement. Furthermore, since firewalling is built into
Linux, the whole point of many of the firewall projects is to create
an easy user interface experience, either through a GUI or a Web
interface.
Don’t underestimate the value of querying the open source
community directly for starting points. While this approach is
unorthodox in traditional IT circles, it’s a mode of communication
that is second nature to open source professionals. Look at the most
active projects in your problem area on SourceForge, or projects with
a high vitality rating on Freshmeat. Post a well-formed question on
popular discussion forums such as “Ask
Slashdot”.
If all of this doesn’t narrow your options enough for you, or give
you enough of a sense of what your TOC will be by going with an open
source application, then maybe Linux isn’t ready for your IT
department yet.
Linux firewall examples
We’ll conclude with a brief survey of some of the available
choices for Linux firewall solutions. What follows are typical
examples only; they are by no means to be taken as recommendations or
endorsements.
GNOME and KDE
As we’ve seen, firewall capability is now built directly into the
networking code of the Linux kernel via netfilter. Administrators typically access and adjust firewall features
using a graphical interface to netfilter. The two common graphical
environments for Linux are GNOME and KDE.
GNOME offers several GUI front ends to netfilter. Firestarter
is typical (see, for example, this
screenshot). KDE has a standard front end to netfilter,
imaginatively called knetfilter
(here’s a
screenshot).
Open source projects
The PCX Firewall
project is typical of many open source firewall projects. While
the Perl-based application lacks a direct graphical front end, PCX
Firewall does offer a CGI mode for Web-based configuration and
administration. The project is fairly mature; the current version is
2.22. PCX currently has support for netfilter/iptables but not ipchains.
The Shorewall project,
also known as Shoreline Firewall, offers a contrasting approach to an
open source firewall project. The code base is fairly mature, and
Shorewall does make extensive use of the newer netfilter
capabilities, including connection state tracking, to enable
session-based functionality for the firewall. Like other projects,
Shorewall is really just a front end to netfilter: “Once
Shorewall has configured Netfilter, its job is complete and there is
no ‘Shorewall process’ left running in your system.” (See the
project’s Introduction
page.) Unlike many other projects, however, Shorewall does not
provide a graphical front end, and instead assumes administrators
will have a fair amount of familiarity with reading and editing Linux
configuration files. To its credit, though, Shorewall is an unusually
well-documented open source project.
Commercial software
Probably the best-known commercial firewall applications for
Linux, and among the oldest, come from Smoothwall Limited. Smoothwall
Express is a freely available, fully open source firewall
application. It is basically a customized Linux distribution that you
download and install on a standalone machine intended to be a
dedicated firewall. The installation process walks administrators
through some easy configuration steps. Once the software is
installed, you can easily monitor and administer it via a Web
interface. For the majority of firewall installations, Smoothwall
Express will likely suffice.
SmoothGuardian is a
proprietary commercial firewall product with a number of advanced
features, such as VPN access and content-based filtering, that are
not available in Smoothwall Express. Offering an open source
component with basic capabilities and a second, full-featured,
commercial product is a common practice among companies trying to
profit by selling open source software, because it leverages the
network effects that enable open source programs to gain such wide
market penetration.
Conclusion
As an IT decision-maker, you increasingly have to consider Linux
alternatives. The more specific your business needs, the more likely
it is that you’ll need a commercial product or one built by your own IT
staff. The more your problem has in common with problems faced by
other IT departments, the more likely it is that a freely available
open source solution will work for you.
