Article submitted by David A. Thompson. We’re running out of articles! If you like Debian Package of the Day please submit good articles about software you like!
Grumble… a postgresql server on an old Sun workstation isn’t visible to another old Sun workstation which (in theory…) is storing data on the postgresql server. The culprit was a misconfigured firewall. Rather than wading through a bunch of iptables commands, it seemed time to revisit the world of iptables front-ends on the off-chance there was an undiscovered treasure I’d missed on earlier visits. It turns out that there was one: ferm.
A revisit to firestarter, a straightforward GUI interface, ended when firestarter segfaulted and then, when started again, automatically started its firewall. Fortunately, I had altered the firestarter rule set and opened port 22 before firestarter segfaulted. Otherwise I would have been hundreds of miles away from an inaccessible server. After firestarter crashed again with a memory error, I decided to move on…
Like several other firewall front-ends, ferm is aware of the issues associated with working on servers hundreds of miles away from one’s physical location. Ferm starts with a default configuration which leaves the default SSH port open. Even better, ferm has a ‘try-before-you-buy’ feature (shared with a few other packages such as firehol):
ferm --interactive activates a specific ruleset and, if a user response isn’t given within 30 sec, the system reverts to the previous ruleset.
Rather than using a GUI interface (e.g., firestarter, gnome lokkit, guarddog, kmyfirewall, knetfilter, …), ferm is configured via a text configuration file and can be controlled in a straightforward manner from the console. This may be a desirable feature for running on a box with limited disk space as GUI interfaces generally require the presence of X windows-related packages, often along with several KDE- or Gnome-related packages.
My main concern wasn’t with whether the application had a GUI or console interface but was with whether the application facilitated straightforward configuration of an iptables ruleset (translation: it shouldn’t take 20 min of reading documentation to get a simple firewall up). Other front-ends (e.g., shorewall and firewall builder) appear to be designed for complex rule-sets and require a substantial investment of effort to learn the syntax of configuration files or a ‘rule-making language’.
Along with ferm, another front-end, firehol seemed to also hit the mark with respect to having a straightforward syntax. Unfortunately, I found that firehol ended up being a time-consumer. In my experience, preparing a firehol configuration file which didn’t trigger multiple errors from firehol/iptables did not prove to be straightforward. In contrast, ferm gave me no such problems. A few tweaks of the default system configuration file —primarily opening a few ports—:
proto tcp dport ssh ACCEPT; proto tcp dport http ACCEPT; proto tcp dport https ACCEPT; proto tcp dport postgres ACCEPT;
/etc/init.d/ferm restart and things were running smoothly. Minimal effort, satisfying results…
The bottom line is that, for simple rulesets, using ferm is definitely easier than preparing iptables rules by hand. However, ferm can also be used to put together more complex firewall rulesets. It uses a reasonably powerful configuration language (including support for variables, function definitions, and arrays) which facilitates addressing more complex situations than the one I faced. To top it off, ferm seems to be under active development with bugs being squashed and features being added relatively regularly.
Update, editor’s note: I’d like to add to this article my personal experience with ferm. Being a SysAdmin, I’ve been using netfilter/iptables for many years, after migrating away from ipchains; and the day I’ve found ferm my work changed completely. To me, being able to write your rules in clean structures, with blocks, variables and ‘functions’ is, by far, the most important feature of ferm. Thanks to this, I was able to write very complicated rule-sets, which were still readable to the point that the more junior SysAdmins, with little exprience on netfilter, have no difficult modifying it to open up ports or creating a new NAT rule.
Having said that, a warning to the newcomers to netfilter: there’s no tool that will magically allow you to write non-trivial rule-sets if you don’t understand the underlying stuff. You will be able to manage your home server, but if you want to do more serious work, you’ll need to really understand how TCP/IP works, and after that, read a lot about the details of routing and packet filtering in Linux. Having seen many people get frustrated by this, is better for you to know that this beast is quite tricky.