FireHOL - Frequently Asked Questions
Please see the standard installation instructions. These cover both installation from distribution-specific packages and downloads from this site.
Please see the source installation documentation. This covers downloading from the repository and the extra steps needed to perform a build (./autogen.sh && ./configure –enable-maintainer-mode).
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 Debian or Ubuntu, become root and modify /etc/default/firehol to have START_FIREHOL=YES, then, as root, start it with:
/etc/init.d/firehol startTo make it start automatically run:
update-rc.d firehol defaultsIf you want to investigate why some traffic is being blocked, the best place to start may be with the troubleshooting guide.
To get a listing of the actions FireHOL would take based on your configuration, you can run:
firehol debugIn the event of an unexpected problem, FireHOL will leave behind its temporary files (and let you know where they are located) in order to help you diagnose the problem.
FireHOL runs as a bash script so if you need detailed information about what is going on internally you can add these lines to your configuration:
set -x
set -v
eth0:1 is not really a virtual Ethernet device. The eth0:1 is just a naming convention for tools such as ifconfig to be able to use multiple IP addresses on a single interface.
If you have interfaces with these names, it is for the purpose of having multiple IP addresses on an interface. Netfilter does not recognise the aliases. You cannot use them in your firewall and must match on the IP address instead.
In practice, iptables does not prevent you creating rules to try to match eth0:1. However, when running, the incoming packets will be seen as from eth0 and will match only the eth0 rules. FireHOL inherits this behaviour.
Note that VLAN interfaces such as eth0.1 are genuine interfaces that will work as expected within firewall rules.
To get a configuration file quickly, you can run:
firehol helpmeThe 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.
In general, I will try to avoid helping you on manual configuring your specific firewall; I commit however to 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.
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.
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.
By default, FireHOL logs all dropped packets (subject to rate limiting) via standard iptables commands.
We are often asked how to stop FireHOL logging so much, even after the logging of invalid packets is silenced.
First consider a Switch to NFLOG.
If you decide NFLOG is no good for you and you are sure you want to go ahead (it will make things harder if you later want to debug a connection), there are a couple of options:
If you then set FIREHOL_LOG_MODE=“NFLOG” in /etc/firehol/firehol-defaults.conf then FireHOL will use NFLOG with iptables, rather than the output going to normal syslog.
If you really don’t want any logs, then you could stop here.
We recommend capturing NFLOG output, though, by installing ulogd 2.x. Most distributions provide a package.
The default ulogd configuration logs to a user-controllable file in a syslog style. It uses a system of plugins and is highly configurable.
Most modern syslog setups allow you to control what is logged and where. Here are some detailed suggestions for rsyslog, including lg rotation of the output
So long as a rule is hit, FireHOL won’t log anything (unless that rule is one that you have attached the log target to, of course!)
If you want to ignore certain packet drops, just set up an explicit rule, e.g. to not log ssh connection packets:
interface first eth0
policy drop
client all accept
server ssh dropNote we match the policy, so the behaviour is unchanged, except we never reach the default logging rules.
If you really want to get rid of everything, finish each interface and add a final router (if you have any) as follows:
interface first eth0
policy drop
...
server anystateless nolog drop # Prevent logging
interface second eth1
policy drop
...
server anystateless nolog drop # Prevent logging
# more interfaces / routers
# Only add this if you have other routers
router nolog
server anystateless nolog drop # Prevent loggingThis will catch all default locations for logging of unmatched packets and has the advantages of being explicit about what you are trying to achieve and more fine-grained than a global variable.
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:
Each member of your team can setup firewalling in a consistent way.
In the past, I have seen all kinds of misconfigurations in iptables, even when I was building the rules. Iptables is not easy, it provides many alternatives for doing the job and each engineer knows or likes just a few of them.
Each member of your team knows exactly how each service operates, which ports it needs, how to prevent various attacks, etc.
Again this is not easy stuff. Some techies are more experienced than others and many have very limited knowledge of the underlying stuff. To see the complication, if I tell you to setup a firewall for an FTP server supporting active and passive mode, how much time do you need to find the exact iptables rules and successfully configure the firewall?
Each member of your team can examine and modify the firewalling rules that another member build some time ago.
This is a real nightmare. If I give you 200 iptables rules, how much time do you need to figure out what is happening and make a few changes?
For Quality Assurance, ensure that there is an easy way for auditing the firewall quickly.
This is very important. Firewalling is the place that tells you exactly what is allowed and what is not.
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, centralised configuration of many systems, etc. But consider the following:
FireHOL abstracts the service definitions from the firewall rules.
In FireHOL you say “I run a FTP server here” and you don’t care what FTP means for iptables. FireHOL takes care of this detail, so the engineers can focus on what they already know: The machine runs an FTP server.
FireHOL minimises the configuration directives.
Do you know how many iptables statements this represents:
route "smtp http ftp" accept src not "a.client b.client c.client" dst "a.server b.server c.server"It is 92 iptables statements and it would be more than 1000 if in the clients list there was the UNROUTABLE IPS variable.
The FireHOL configuration file is the best place to look for what a server does.
This is actually the first thing I use to audit the configuration of my servers. I just take a look at the firewall configuration. Even if something more is running, I am sure that it cannot be accessed from the outside world.
Also, this is why I like the client statement so much. Personally, I expect all production systems to be configured with client statements that specifically allow only client requests that are really needed. Although it is pretty helpful for workstations, I consider
client all acceptas a security threat for production servers.
For all the above, I consider FireHOL as the most functional way for working with iptables firewalls.
Well, don’t trust us. We don’t want you to do so and you are not supposed to do so. We have done the utmost to make it possible for you to audit the generated firewall.
You have the explain feature where FireHOL interactively 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.
Ideally you should audit the results at least once to ensure you are happy with the rules produced. The rules that get output are extremely regular which should make the task fairly straightforward.
You should also read When FireHOL Runs in order to understand how FireHOL gets its results.
Please consider signing up to the support mailing list to ensure you are kept informed in the event that a security problem is discovered.
Overall it is your responsibility to ensure the final firewall produced behaves as you want it to. If in doubt we recommend that you seek help from a firewall/networking professional.
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 optimised. In many cases, this “jump” optimises 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 introduce a noticeable increase in CPU utilisation 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.
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 succeeded 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.
If you would prefer to ensure no traffic passes whilst the firewall is being activated, read about the ACTIVATION variables, which are able to control this behaviour.
FireHOL and FireQOS share a common version number. Release numbers used follow the Semantic Versioning scheme (daily builds not).
Thus releases will be 3 digits e.g.:
3.0.0Pre-release versions will have an additional identifier e.g.:
3.0.0-rc.5Git checkouts and daily builds add a branch id to what will be the next release e.g.:
3.0.0_master
The _whatever indicates the version is prior to even the -rc.nn versions.
Older daily builds used the commit id from which they were built:
$ sudo ./sbin/firehol
FireHOL commit-61d70a2When checked out from git, the programs will report internal version numbers e.g.:
$ ./sbin/firehol.in
FireHOL $Id: 8c6fd57f0b7a3c76fe848dc118f0637cb853f1e4 $Version 1 packages were in the form 1.xxx, which related to the CVS revision of the FireHOL script.