- About Us
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.
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.
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.
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.