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

Feature: Security

Three tools to help you configure iptables

By Chris Lynch on May 23, 2005 (8:00:00 AM)

Share    Print    Comments   

Every user whose client connects to the Internet should configure his firewall immediately after installation. Some Linux distributions include firewall configuration as a part of installation, often offering a set of defaults configurations to choose from. However, to ensure that your machine presents the minimum "attack surface" (a measure of the number of vulnerable ports, user accounts, and sockets exposed to attack) to the predatory inhabitants of the Internet, you may need to do some manual configuration of your firewall. Here are three tools that can help.

The Linux kernel (version 2.4 onwards) contains a framework for packet filtering and firewalling using netfilter and iptables. Netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. Iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target). Iptables has extensive documentation that can be accessed online or by typing man iptables at the command line. Yet despite the depth of the documentation available for iptables, its complexity can be baffling.


The GPL-licensed FireHOL allows you to configure iptables through its abstract, extensible configuration language, enabling you to write your configuration in something approaching a fourth-generation programming language.

Safety in Linux
In December, the Honeypot Project released findings indicating that an unpatched Linux machine could survive for months connected to the Internet, compared to reports of a lifespan as short as four minutes for a some Windows operating systems.

FireHOL can be downloaded from SourceForge as an RPM binary or as source code. I downloaded the RPM and installed it on my Mandrakelinux system.

FireHOL runs a service/daemon, checking its own configuration file at startup and writing out an iptables configuration before automatically starting the iptables firewall. FireHOL backs up any existing iptables configuration during this process, so it should be safe to install alongside any existing configuration you have for iptables.

Configuring FireHOL requires that you learn the FireHOL configuration language. FireHOL configuration files are actually bash scripts. As such, you can use bash features such as functions, loops, and variables within your FireHOL configuration. The actual FireHOL configuration language itself is simple to learn but powerful.

My relatively simple FireHOL configuration looks like this:

version 5

# Allow BitTorrent server ports

# Accept all client traffic on any interface
interface any world
        client all accept
        server bittorrent accept

Documentation for FireHOL is excellent. The SourceForge-hosted site for the project documents the FireHOL configuration language in detail, gives an excellent tutorial, and includes links to sites that will test the integrity of your firewall via the Internet. If I have any complaint about the FireHOL documentation, it is that the use of frames on the Web site makes it difficult to read any large section of the documentation without lots of scrolling. It would be nice to see a PDF manual on offer for this otherwise professional offering.

FireHOL scores highly for its mix of simplicity and flexibility. I was able to configure a basic "I can go out, but you can't come in" firewall quickly using it, and the resultant configuration passed every test I threw at it.

Personally, I like the approach that FireHOL takes in simplifying the language used to configure iptables without placing a barrier between you and the system itself. I remain confident that, using FireHOL, I can make my firewall do whatever I want with just a few commands.


Guarddog is a GUI-based iptables configurator for KDE. Like FireHOL, Guarddog is application- and protocol-based, but unlike FireHOL Guarddog provides extensive guidance on which protocols to allow and disallow both through its documentation and through the GUI itself. Guarddog bills itself as a firewall maintenance tool, with the implication that you will return to Guarddog to reconfigure the firewall to meet your changing requirements over time.

You can download a binary installation file for Guarddog for a variety of distributions, including SUSE, Red Hat, Fedora Core, Debian, and Mandrakelinux. I installed Guarddog using URPMI and Mandrake's cooker repository.

The first time that I ran Guarddog it issued a warning that the file /etc/rc.firewall was not a valid Guarddog file, and failure to cancel immediately out of Guarddog following the message would overwrite the contents of this file. Taking this into account, I would advise that you back up your existing firewall configuration before installing and running Guarddog for the first time.

Guarddog offers a comprehensive, but at times bewildering, list of options. Guarddog's configuration is based on the concept of allowing different protocols to be served between different zones. The two default zones that are configured are local and Internet. You can define additional zones, if you require them, based on IP address ranges.

Assuming that you are setting up a simple personal firewall, the first thing that you will want to do is make sure that all of the protocols that you routinely use to connect to online services are allowed to be served to the local zone from the Internet zone. You do this by selecting the allowed protocols from Guarddog's extensive list. For example, allowing the local zone to connect to the Internet zone using the HTTP (port 80) protocol allows Web browsing. A large number of protocols are preconfigured, including all the ones that I required, but it did take some time to find them. Should a protocol that you use be missing from the list, you can define your own additional protocols in the advanced options. Root access is, of course, required to modify the firewall settings.

In my testing of Guarddog, I couldn't find an easy way of saying "let my machine connect to anything," as I had done with FireHOL previously. Whilst this kind of configuration is not a strong firewall, finding all of the protocols that I use within Guarddog's list was particularly time-consuming, and I was tempted to use the simple, insecure approach to start. If you share your computer with other people (or they share your firewall) you will want to make sure you at least cover the common protocols.

Guarddog has a complete online handbook that includes tutorials and a wealth of good advice on firewall configuration in general.

Guarddog is a well-documented and easy to use tool for iptables configuration. The tool is aimed at producing strong firewall configurations with a minimum number of exposed ports and services, and should be applauded for that. However, you're likely to employ Guarddog as a firewall tool that you return to time and again in order to add and remove ports from the available and blocked lists and to, potentially, add new protocols to the configuration. Guarddog encourages, and requires, firewall maintenance.

Easy Firewall Generator for iptables

Not all iptables configuration tools need to be installed or run on your machine, as the Easy Firewall Generator proves. Easy Firewall generator works through a simple Web-based interface to generate a basic firewall script for iptables.

Testing your firewall

Irrespective of which firewall configuration tool you choose, you should always test your firewall configuration after applying it. There are tools available on the Internet that allow you to do this, some of the best being Web-based services that attempt various attacks and exploits on your machine. A word of caution, though -- if you use a tool to test your firewall, be sure that you trust the tool itself not only to give you accurate results, but also to keep those results private and not make use of any vulnerabilities that it detects on your system.

Recommended firewall testing tools

  • Shields Up! -- One of the first Web-based port scanners, GRC's Shields Up! has now scanned more than 35 million firewalls for vulnerabilities. Scans of both common ports and the complete port list are supported, as well as checks for file sharing and IM client vulnerabilities.
  • SOS Scan -- SyGate's suite of scanning tools offer you several different ways to test your firewall, including stealth scans and checks for known trojans.

The Easy Firewall generator requires you to enter the name for your network card, commonly eth0, and the specification of several simple options, such as whether the IP address of the machine is obtained dynamically, whether the machine is to act as a gateway (with subsequent configuration options for the gateway itself), and what services the machine will allow remote users to connect to (from a short list of common services). The Web page then generates a bash script for configuration of the firewall.

Whilst this tool may seem limited in comparison to FireHOL or Guarddog, it serves to show that firewall configuration in Linux can be simple, quick, and relatively painless. If your goal is to configure a simple "allow me out, allow nothing in" firewall, this tool serves the purpose well.

Documentation around Easy Firewall Generator is light, but sufficient to explain the function of the page and to give some additional insights into firewall configuration through some well-chosen links. I advise approaching the links page as a tool, rather than as a solution in itself.

Easy Firewall Generator does exactly what is says it will do and no more. If you ever find yourself at a machine with no firewall and want a quick, safe configuration without the need to install additional tools, this utility can be a big help.

Choosing the right tool for you

There are more iptables configuration tools than the three tools highlighted here, but these three serve to illustrate that there are as many approaches to configuring your firewall as there opinions for what you should and should not have within the configuration itself.

My personal favorite of these three is FireHOL, which I feel provides the optimum mix of flexibility and power. You can configure any firewall with this tool, and you are free to apply your own logic and preferences in that configuration. Guarddog, for me, imposes too many restrictions on what I, as a user, can and cannot do.

Share    Print    Comments   


on Three tools to help you configure iptables

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


Posted by: Anonymous Coward on May 24, 2005 04:26 AM
What about Firewall Builder?

<a href="" title=""></a>


Bastille and Arno's firewall

Posted by: Anonymous Coward on May 24, 2005 04:49 AM
Here are a few other easy iptables configuration options:
- Bastille: <a href="" title=""></a>
(good for other security settings too, but available for too few (the biggest) distributions only though)
- Arno's iptables firewall script: <a href="" title=""></a>
(relatively easy to configure after reading the documentation while still flexible enough for quite complicated situations)


this one is very easy and flexible:

Posted by: Anonymous Coward on May 24, 2005 05:09 AM
Firestarter <a href="" title=""></a>

a very well-designed graphical front-end for iptables which you can configure in 30 sec max.

Firestarter features

        * Open Source software, available free of charge

        * User friendly, easy to use, graphical interface

        * A wizard walks you through setting up your firewall on your first time

        * Suitable for use on desktops, servers and gateways

        * Real-time firewall event monitor shows intrusion attempts as they happen

        * Enables Internet connection sharing, optionally with DHCP service for the clients

        * Allows you to define both inbound and outbound access policy

        * Open or stealth ports, shaping your firewalling with just a few mouse clicks

        * Enable port forwarding for your local network in just seconds

        * Option to whitelist or blacklist traffic

        * Real time firewall events view

        * View active network connections, including any traffic routed through the firewall

        * Advanced Linux kernel tuning features provide protection from flooding, broadcasting and spoofing

        * Support for tuning ICMP parameters to stop Denial of Service (DoS) attacks

        * Support for tuning ToS parameters to improve services for connected client computers

        * Ability to hook up user defined scripts or rulesets before or after firewall activation

        * Supports Linux Kernels 2.4 and 2.6

        * Translations available for many languages (38 languages as of November 2004)

==>and most importantly its *truly* free software - its GPLed!!


Re:this one is very easy and flexible:

Posted by: dukeinlondon on May 24, 2005 06:13 AM
Looks like exactly what I am after. Thanks


not the holy grail

Posted by: Anonymous Coward on May 24, 2005 06:24 AM

have no idea if firewall works or not when X fails to start, or if computer is automatically restarted after a power outage/restoration of power.

can't click on an ip of an intrusion attempt to have that ip address automatically added to the block list

clicking on an ip address to have the ip address resolved, what about going back to ip addresses instead of resolving all?

how do I admin the firewall from another computer using ssh/telnet, when it is running as an X client in X on the original computer?

Adding as a subnet to block doesn't seem to work. How do you block subnets? What is the exact entry? Is a space required, ie:<nobr> <wbr></nobr>/24 ? Different style?

When the firestarter window freezes, is the firewall still working?

Inbound/outbound setup/explanation/window is confusing.

blocking ping/pong, ICMP, source quenching, other items, should they all be blocked? Which to keep open so I can see which computers are alive on the local network, ping, pong, msping, others I can't see right now because I'm on a different computer

If firewall window is open on desktop, can't ssh into box from elsewhere on local or remote network, with X forwarding, to open firestarter window remotely for administration. Have to either kill the firestarter process remotely then start firestarter over ssh -X connection to do this, then kill firestarter from original computer through another ssh session to remote computer, kill firestarter window on remote computer and restart on local computer.

Can't guarantee throughput and/or reliability to local voip ip address, rather than server/workstation options

lack of options to add ability of above line/access to command line

lack of access to/display of command line prevents learning of iptables

all of the above being said, the benefits of firestarter outweigh the problems. Put the docs in the deb package, install locally, instead of remote website location.


Re:not the holy grail

Posted by: Anonymous Coward on May 25, 2005 09:45 PM
> have no idea if firewall works or not when X fails to start, or if computer is automatically restarted after a power outage/restoration of power.

The firestarter firewall loads when you boot, before X starts. It says so on the screen.

> clicking on an ip address to have the ip address resolved, what about going back to ip addresses instead of resolving all?

Choose the resolve option again, it reverts to the IP.

> how do I admin the firewall from another computer using ssh/telnet, when it is running as an X client in X on the original computer?

The same as any other remote X program? "ssh -X someserver", start firestarter, and there you are. Or VNC if you need to attach to an existing instance (but why bother?).


Re:not the holy grail

Posted by: Anonymous Coward on May 27, 2005 12:12 AM
> have no idea if firewall works or not when X fails to start, or if computer is automatically restarted after a power outage/restoration of power.

The firestarter firewall loads when you boot, before X starts. It says so on the screen.

What about when the firestarter window freezes up? Is the firewall still running when the firestarter window fails to respond to any click, fails to respond?

> how do I admin the firewall from another computer using ssh/telnet, when it is running as an X client in X on the original computer?

The same as any other remote X program? "ssh -X someserver", start firestarter, and there you are. Or VNC if you need to attach to an existing instance (but why bother?).

If firestarter is already running, with the firestarter window open on the computer, ssh'ing into the computer from another location doesn't allow you to see the original firestarter window. You have to kill the firestarter process, then restart it in the ssh session to "see" the window and admin firestarter. But what happens when the ssh session ends? How do you restart firestarter on the original computer so the firewall is running when your ssh session ends?

Try starting another instance of a mail client while the same mail client is running on the target computer (as the same user). Process dies. Would one want to take the chance of not being able to get their firewall running again when the ssh session is finished?


Re:this one is very easy and flexible:

Posted by: Anonymous Coward on May 24, 2005 08:39 AM
Firstarter is a great firewall, you can see in real time what programs on your computer are accessing the internet, and what they are accessing, see the log of flagged packets, and setup your firewall based on a blacklist or whitelist method. It can also be used to set up a router (I installed it the other day just to forward my friend's desktop though my laptop's ethernet to the wireless network).

I like Firestarter a lot, though I don't use it anymore because I feel that having a firewall on my laptop is kinda over kill (I don't have any ports open anyways, and when I do it is for KDE's public file server which will only be open for a few minutes on my home network).


Guarddog to secure?

Posted by: Anonymous Coward on May 24, 2005 06:20 AM
So you main gripe about Guarddog was that it wouldn't allow you to produce rubbish insecure firewall rules?

In fact it made it easier too develop the most secure setup, than the worst? and worked in such a way that you had to go back and maintain the firewall when your setup changed?

This is bad because?

I've used several firewall rule generators, including guarddog, and its that one I use exactly because of those points. Maintenance isn't such a burden in fact I've only had to touch it twice since I initially set it up, once to allow bittorrent through, and the other for Samba.

Its a GUI setup tool to make it easier to setup the most secure firewall. I simply can't see what could be wrong with that.


Re:Guarddog to secure?

Posted by: Anonymous Coward on May 24, 2005 12:24 PM
One of the basic steps to diagnose problems with a firewall is to turn parts of it off. In Guarddog, at least in this reviewer's take, that's hard to do.

Not a problem I've had, just RTFM, but hey, this is a newspaper, after all.


Re:Guarddog to secure?

Posted by: Anonymous Coward on June 02, 2005 02:09 AM
So he wasn't bright enough to spot disable firewall?

Hmmm, Maybe... they did put it in the advanced tab, just didn't see it?


One thing confusing about iptables

Posted by: Anonymous Coward on May 24, 2005 06:32 AM
setting up iptables, I've visited the sites that build the firewall rules. And I've gotten a few sites to build some usable rules. Once this is done, then what?

Where do the rules go? Copy and paste to a bash window, then hit enter? Save as a text file? And put it where? Make it executable? Owned by? Group? Need to make start/stop files for startup? Need to make it a cron job?

I've read the man pages. The docs. But when you get an application that you can't figure out the basics because it is assumed you know the basics, that's what newbies waste hours and hours on, what we throw up our hands at, what makes us go back to windows or go on to something else and work without a firewall.

Step-by-step, what do I do with a ruleset once I have it made? Step-by-step, what do I do to ensure that it runs on every startup? Step-by-step, what do I do to get a warning message in case it doesn't start up, so I can start manually or stay off the web?

Why don't the docs and man pages include step-by-step instructions on what to do with the ruleset once it has been generated?


Re:One thing confusing about iptables

Posted by: Anonymous Coward on May 24, 2005 07:17 AM
Here are the basics:

The kernel itself holds the 'rules' when the system is up and running. The 'iptables' command is used to add, delete, or list rules that the kernel uses. In order to have the rules loaded at boot time, the iptables command must be run with each rule described by parameters.

This is usually done with a simple shell script containing multiple invocations of the iptables command, but it can be more complicated if the rule file is generated in an intermediate format that has to be processed by something other than a shell. In that case you may need to just add the preprocessing command to an already existing startup script.

Unfortunately, because the start up procedures are different for each linux distribution, it isn't easy to specify where ANY start up script should be installed, in general. They all use different means to make sure that things get executed in the proper order, and it is all reconfigurable.


Re:One thing confusing about iptables

Posted by: Anonymous Coward on May 24, 2005 07:26 AM
Put it in a bash script. Configure to run the bash script at boot up. You could call the script from<nobr> <wbr></nobr>/etc/rc.d/boot.localnet depending on your distro.
chown root:root <script>
chmod 755 <script>


Re:One thing confusing about iptables

Posted by: Anonymous Coward on May 24, 2005 11:49 AM
I found reading already existing script files helpful in understanding how iptables functions.
A site called <a href="" title=""></a> contains alot of example scripts. Once you find a script that is appropriate, you can simply save it as a text file and customise it for your requirement. Make the script executable (e.g. chmod +x firewall-script) and make sure it is executed at system start. Testing with a vulnerability detector, such as <a href="" title="">Nessus</a>, after you have installed your firewall will tell you if your iptables configuration was successful.


Don't get locked out of your own server

Posted by: Anonymous Coward on May 24, 2005 02:50 PM
While experimenting with or learning IP Tables, it's easy to make rules that block your SSH connection and unintentionally lock you out. Use of iptables-restore, iptables-save and an at job can save an embarrasing call to people on site.

$ iptables-save ><nobr> <wbr></nobr>/home/me/works.txt

$ echo "/sbin/iptables-restore <<nobr> <wbr></nobr>/home/me/works.txt" | at now +3 minutes

$ iptables-restore < mightwork.txt</tt>

That gives you three minutes to test the rules in "mightwork.txt" before the last known working copy is restored from "works.txt' If it works, or at least doesn't lock you out, then the at job can be cancelled with atrm


Re:One thing confusing about iptables

Posted by: Anonymous Coward on May 24, 2005 03:15 PM
"Why don't the docs and man pages include step-by-step instructions...?"

That's purpose of howtos. Seriously, <a href="" title="">search google</a> for your answers.




Posted by: Anonymous Coward on May 24, 2005 09:38 AM
Why is it that when most people think security the word firewall is bandied about so often without mentioning where real security comes into play?

Is the Windows security mentality that prevalent?

True security arises not from blocking packets and closing ports (though these practices do help) but in a combination of the above with user limits, login limitations, and the latest security fixes.

Bastille-linux combines four of the five above, the fifth is left up to the administrator to download and install the latest security fixes.

Bastille-linux combines four of the five above, the fifth is left up to the administrator to download and install the latest security fixes.



Posted by: Anonymous Coward on May 24, 2005 01:52 PM
I've got to agree with the general thread of comments. You cover two tools --that based on learning curve are for people who will be configuring setting them up constantly-- and one very basic web-based wizard. I suspect a lot of of us fall in the middle. We need more power that a cheesy wizard but don't build systems every week or two. That leaves the comments the only useful part of the article. Except... I already figured out FWbuilder seems to be the way to go. Too bad this article doesn't confirm that or provide an alternative.


Just one little suggestion

Posted by: Anonymous Coward on May 24, 2005 02:26 PM
This article illustrates the most serious failing of the Free Software community.

  1. Somebody builds a great tool, iptables.

  2. Unfortunately the documentation, while fairly complete, is hopelessly inadequate for most users.

  3. Instead of fixing the documentation, uncoordinated bits of the Free Software community go and build 3 or more "front-ends" to the tool.

This is a disaster, because none of the 3 add-ons is needed, but the end-user will have to research them to find that out. None of them will be as widely-used as the underlying tool, which means there will be less community support for any of them than for iptables itself.

It's really easy to write a front-end. It's really difficult to fix documentation.


Re:Just one little suggestion

Posted by: Anonymous Coward on May 24, 2005 03:08 PM
Nonsense, iptables is a very flexible and professional firewall application. And with a bit of effort you'll find a LOT of documentation and HOWTO's for any type of firewall. AND, you'll even find many frontends (not add-ons) for it. It's the inherent complexity of firewalls that is the problem. And that is because TCP/IP is not designed for safety, as we all know. So, if the front-ends don't work for you, that's possible (none of them work for me), you're forced to concentrate on iptables itself. Buy yourself a good book (Linux Firewalls, by Ziegler, New Riders) and get ready for some work. And stop complaining that other people can't make it easy on you.


PF vs. iptables

Posted by: Anonymous Coward on May 24, 2005 07:33 PM
The major problem with iptables/netfilter is that it is so cryptic to understand and configure in itself (ok, maybe not if you're a semi-guru or have read that much documentation...). That's why there are so many interfaces to iptables - but many of them are still a bit too tough for your average Linux newbies.

Compare iptables to the (Open)BSD firewall, PF: easy to understand, intuitive rules, comparable to the FireHOL rules that the author praises here. Sigh, I dunno if it were possible, but I hope that they could port PF to Linux too. Or maybe they could somehow clarify/simplify the complexity of iptables already on the iptables UI level?



Posted by: Anonymous Coward on May 24, 2005 11:33 PM
FYI, though I haven't used it for this, Webmin has rule editing features.



Posted by: Anonymous Coward on May 24, 2005 11:42 PM
Yeah. Firewalls and security. So let's use a swiss cheese for security app to tighten down a system.

Kind of like using frontpage extensions on a web server while discussing securing a web server...



Posted by: Anonymous Coward on May 25, 2005 12:13 AM
I have found Shorewall (<a href="" title=""></a>) to be extremly flexable and powerfull Netfilter rule generator. Be that, it doesn't have a GUI interface (configuration is done in a set of text files), it isn't hard to get a grasp of.

I have used it in environments ranging from single computers (Mandrake uses it for it's firewall), small networks (under 5 systems behind a Shorewall box) to large (over 200 computers, VPNs, multiple internal zones, DMZ, etc).

There is a Webmin addon for that point-and-click interface, but I find it quicker to just edit the files.



Posted by: Anonymous Coward on May 25, 2005 01:04 AM
I evaluated all of these this year and chose Shorewall. Second place went to FireHol and all the others fell very far behind these two.

The way shorewall separates config into multiple files in a common-sense manner makes it a no-brainer to use. It also makes the format of each config file as simple as possible.

I'm going to evaluate these again next year to see if my preference changes (everyone should re-evaluate their choices every year instead of being blindly loyal to software).

For now Shorewall beats these hands down.


Easy Firewall Generator

Posted by: Anonymous Coward on May 25, 2005 03:56 AM
I noticed the link given for EFG is running a pretty old version (1.05). The current version is 1.17 and the site is:

<a href="" title=""></a>

As your article noted, it's very much designed for a specific need: either single system or as a gateway for a small (usually home) trusted private network for people with fairly limited knowledge about iptables. At the time I wrote it, there really wasn't anything to fill that niche and I knew a number of people who had that specific need. I never really expected it to get the attention it has received.

Scott Morizot


Re:Easy Firewall Generator

Posted by: ciscocertifiedgeek on May 30, 2005 08:09 PM
Hi Scott,

I've been using EFG for a couple of years now, thanks for your effort putting up EFG.

I build gateways (I'm a system admin in a publishing media company in Indonesia), so I dont need any X-based GUI. EFG comes handy to me.

Again, thanks. EFG rocks!


I tried a few a while back...

Posted by: Sam Leathers on May 25, 2005 09:16 AM
I don't know how far they have come recently, but when I tried a few frontends back when 2.4 first came out I found all of them really inadequate and went to <a href="" title="">the source</a> to learn the iptables syntax, and just wrote my own debian startup script I've used for a few years now, and even re-used in customizations for customers. If anyone wants a copy of my script, feel free to hop on my irc server and<nobr> <wbr></nobr>/msg me.


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

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya