This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


A Linux firewall primer

By Mark Stone on October 14, 2004 (8:00:00 AM)

Share    Print    Comments   

You've heard the familiar arguments: commercial firewall products 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.


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.


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.

Share    Print    Comments   


on A Linux firewall primer

Note: Comments are owned by the poster. We are not responsible for their content.

Re:A nice GUI...

Posted by: Anonymous Coward on January 23, 2005 08:18 AM
Who needs a GUI when a Bash script can do it all and do it simply and elegantly.

Try Firehol:


A nice GUI...

Posted by: Administrator on October 18, 2004 02:40 PM
...would be fwbuilder. Check it out at



Posted by: Administrator on October 14, 2004 11:15 PM
Shorewall is an excellent example of Linux firewall configuration utility, but I don't think a serious mention of shorewall would be complete without a look at one "meta-Shorewall" application.
While shorewall is a utility to ease the configuration of the Linux firewalling capabilities, it does require editing configuration files and a learning curve. This learning curve can be reduced by using a shorewall configuration utility (a utility to configure a configuration utility???) such as the excellent <A HREF="" title="">webmin shorewall module</a>, which is a standard module for <A HREF="" title="">webmin</a>.
The shorewall webmin module allows the admnistrator to configure the most useful capabilities of shorewall from a web interface. While it does not support all of the most esoteric features of shorewall, it does allow most standard configurations to be quickly and easily set up.
More advanced features of shorewall can still be setup by hand, and I would recommend keeping an ssh session open to the firewall machine when using the module. The module has a nasty habit of committing whatever changes you specified. It does a decent job of picking out errors, but sometimes something gets by that shorewall will refuse to use. When you hit "restart shorewall" you may inadvertently shut the firewall down, meaning no new traffic gets from, to, or through the box. If you don't have an already open connection with ssh, you may have to log in at the console to fix it. I think this is a minor problem with the module, and every release of the module gets better at preventing you from shooting yourself in the foot. It is still better to use the module and get a little error checking, than to hand edit the files and get none.
All in all, you will probably be a lot more productive using the module than you would be hand editing all the config files, unless you spend some really quality time with shorewall. I think most of us want it up quick and never want to deal with it again.

disclaimer: I have nothing to do with either webmin, Shorewall, or the webmin Shorewall module. I just use them. A lot.



Posted by: Administrator on October 14, 2004 10:34 PM
Amazing that he didn't mention IPCop ( More functional than Smoothwall and GPL'd.



Posted by: Administrator on October 15, 2004 01:08 AM
I'll second this. Though it does have some limitations (primarily that outbound connections always come from the same public IP address regardless which internal IP address is used, and that NAT is required), IPCop is VERY easy to install and administer. VPN connections (at least with other IPCop machines) are a snap using Openswan, and plenty of 3rd party addons are available. And it can probably run on hardware you have laying in a closet somewhere.

Also, for the (few) cases I've found where IPCop isn't appropriate, <A HREF="" title="">Firewall Builder </a> provides an X-Windows based easy-to-use frontend for manipulating iptables (or ipfilter, or Cisco Pix, or OpenBSD ipf) rules, which is extremely flexible and powerful.


Shorewall and Webmin

Posted by: Administrator on October 15, 2004 05:10 PM
To say that Shorewall does not have a graphical interface is not true, as pointed out by the previous comment.

I think it is important to emphasize this point as the article, with all due respect to the author, seems to be a little underinformed.

Shorewall and Webmin together are the easiest way I have found to create a "stateful" firewall environment. That does not mean to say that there aren't others, but when you have found one that easy why go looking for others?

I consider myself neither to be a firewall or Linux expert and I am not affiliated in any way with the good people of Webmin or Shorewall.


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya