Table of Contents

How did you come with this idea?

When you have to manage several dozens of Linux systems and you have a team of engineers to do the job, then for the firewalling of all those you have to find solutions so that:

I believe that FireHOL solves all these problems in an ideal way. Of course there are many wonderful iptables generators out there, many of them with many more features than FireHOL, with GUIs, centralized configuration of many systems, etc. But consider the following:

For all the above, I consider FireHOL as the most functional way for working with iptables firewalls.

Who are you and why should I trust you for handling my firewall?

Well, don't trust me. I don't want you to do so and you are not supposed to do so. I have made the most to make it possible for you to audit the generated firewall. You have the explain feature where FireHOL interactivelly produces iptables statements for the configuration directives you enter, the debug feature where FireHOL produces all the iptables statements for the entire configuration for you to examine, and extensive automatically generated documentation for all the services supported.

Don't trust me. You are supposed to audit FireHOL services at least once, and if you agree, trust it, not me.

Is the produced iptables firewall optimized?

You have to understand that FireHOL is a generic tool. As such, you gain something and you loose something. Except the fact that all FireHOL configuration rules take one iptables chain (that is one "jump") the produced rules are fully optimized. In many cases, this "jump" optimizes the firewall even further (for example in interface and router statements), while in other cases the "jumps" could be moved to a place where they are really necessary (it is not possible to avoid them). The good thing is that these "jumps" are not so expensive. So, although there is some room for improvement, I have reports from users saying that a huge FireHOL firewall did not introduced a noticable increase in CPU utilization compared to a hand made firewall, for the same traffic.

For the moment, I prefer to keep all the "jumps" there, since it makes the iptables rules a lot more clear and easy to understand. If you believe that I should work on this and you can prove that the "jumps" that could be moved deeper are really expensive at the place they are now, send me a note and I'll do my best.

If you are so interested about performance, you should know that FireHOL places all rules in the iptables firewall, in the same order they appear in the configuration file. So placing your most heavy interface at the top, and within this interface the most heavy service first will really save a lot of processing for iptables.

FireHOL is toooooooooo slow!

This is partially true and partially false. FireHOL runs in two phases: Configuration Processing and Firewall Activation.

Processing of FireHOL configuration files is somewhat slow since all processing is done by BASH (I have not programmed a parser, BASH runs the configuration as if it was a BASH script). This processing however, even if it takes several seconds, it does not affect your security, since the running firewall is not touched during this phase.

Firewall activation is again slow in a few situations, especially if you have lists of hosts that should be allowed or rejected (like UNROUTABLE_IPS). During the processing phase, FireHOL produces a list of the iptables commands to be executed at the activation phase. This list of iptables commands, first clears the running firewall and then it runs iptables commands, one-by-one, until all have executed. As an example, my personal machine configuration file is about 50 lines. These 50 lines produce about 900 iptables statements. For BASH these 900 iptables statements are also followed by another statement to check if the command succeded or failed, which totals to about 1800 BASH statements to be executed. In my machine these 1800 commands take about 8 seconds to be executed. During these 8 seconds the firewall is from totally empty (all traffic allowed) to simply incomplete (some traffic is allowed or dropped explicitly, all other is allowed to pass).

I have written FireHOL in such a way that you can restart the firewall any time you like without disrupting the running traffic. Try it. Start downloading a file, and in the middle of it, restart FireHOL. No change. The download proceeds without any disruption. The only chance for traffic disruption is when you have NAT rules. For just a fraction of the total activation time (normally less than a second, since NAT rules are the first to be executed - i.e. the first few of the huge iptables list) your system will run without them, meaning that no new NATed traffic will be accepted (established connections will work). Again, this will be just for a fraction of a second.

I see you now thinking: OK, but what happens if someone connects to my systems to unwanted services during the activation time? Well, FireHOL's beauty is that it explicitly allows the connections in both ways of the firewall. Most of the other iptables generators allow all established connections to pass unchecked. FireHOL doesn't. It allows the established connections that match the services you have allowed. Nothing more. This means that even if someone is lucky enough to connect to a non-allowed service during the activation time, he will simply be blocked as soon as the firewall activation completes. This gives a window of just a few seconds at which someone could be able to connect to and use private services. Even if he manages to get access within these few seconds, his socket will simply timeout after FireHOL completes.

I installed FireHOL but where is it located? I cannot run it!

FireHOL has been designed to be a startup service. Its exact location depends on the distribution you are using. Most probably you will find FireHOL in /etc/init.d and in RedHat systems you can also access it with the service command.

On Ubuntu, become root and modify /etc/default/firehol to have START_FIREHOL=YES, then, as root, start it with "/etc/init.d/firehol start". To make it start automatically run "update-rc.d firehol defaults".

Is there a list of the system commands FireHOL needs?

As of v1.121 and later, you can find a list of such commands at the top of the FireHOL program file. Currently, FireHOL uses the system path to find these commands and will exit with an error if some command is missing or exists multiple times.

I really need help designing the configuration. Could you help?

You can use the helpme feature of FireHOL to get a configuration file quickly. The helpme feature reads various system parameters of your system and generates a configuration file especially for the host it runs. Helpme is safe to use: it does not alter your running firewall, it does not modify anything on your system. Just try it (give the keyword helpme as a command line argument to FireHOL).

In general, I will try to avoid helping you on manual configuring your specific firewall; I commit however on making helpme detect correctly every single case. I believe, this will benefit all the community, not just you.

In any case, I guess I have done a good job in designing FireHOL the way you expect it to work, and that the documentation is helpful enough, since all the support tools are pretty silent. Of course you are welcome to ask anything you might need regarding FireHOL.

How can I mangle the packets (set TOS, MARK, etc)?

For MARKing packets, you can use the mark helper. For all the other iptables features that FireHOL does not support directly, you can put normal iptables statements anywhere in the configuration file, using the iptables helper. If you really like the FireHOL optional rule parameters for doing this job, just send me an e-mail and I'll write a few helper statements especially for TOS, or whatever.

Why I cannot use the service definitions in helpers?

As you have noted, the service definitions cannot be used in helper statements (mainly NAT). The reason is that currently FireHOL's core logic is limited to one iptables table (filter). To extend this to all iptables tables a new core logic is needed that should be based on something that can be shared across all iptables tables. The only such thing today is MARKs. MARKs are also used for QoS unifying all major traffic management applications.

I have made a few experiments with MARKs but I stuck because there are bugs in the iptables logic when using MARKs. These bugs exist in most kernels distributed today with the main Linux distributions.


SourceForge Logo $Id: faq.html,v 1.7 2007/05/20 18:36:49 ktsaou Exp $

FireHOL, a firewall for humans...
© Copyright 2004 Costa Tsaousis <costa@tsaousis.gr>