by [Cfengine|http://www.cfengine.org] is an awesome tool for managing any number of machines between 2 and 200,000. You probably already knew that. If you’re using Cfengine, you probably also know that it can get pretty verbose, especially for more complex edits. If you have a configuration file wherein order matters, adding a line suddenly becomes nontrivial.
iptables is an exemplar in this regard: it needs a carefully ordered config file in order to work properly. Redhat and Redhat-based distros keep a config file in /etc/sysconfig/iptables; like many iptables config files, it contains a number of lines that open and close some necessary stuff, set up a few chains, and then has any number of lines like this:
{{{
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp -s 10.9.2.16 –dport 5308 -j ACCEPT
}}}
The first line opens port 22 (SSH) to any hosts; the second line opens the port cfservd uses to our Cfengine host. (We use that to collect SSH keys, among other things.)
The config file then ends with a few lines to reject everything else.
!Basic technique
When adding a line to the file, we either need to skip forward past the initial lines, or skip backwards past the final lines. In Cfengine language, that looks roughly like this:
{{{
{ /etc/sysconfig/iptables
BeginGroupIfNoLineMatching “-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT”
LocateLineMatching “.*REJECT.*”
IncrementPointer “-1”
InsertLine “-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT”
EndGroup
DefineClasses “restart_iptables”
Backup “single”
}
}}}
That’s pretty verbose for just adding one line. If you have a lot of hosts with a lot of services — and you almost certainly do if you’re reading this — you don’t want to add that stanza every time you add a service to your list. And, moreover, you don’t want to wade through hundreds of lines of that crap in order to find out if you’ve added a given service, or to troubleshoot a problem.
!Cfengine modules
When I faced this problem, my first attempt at a solution involved a Cfengine module. Unfortunately, Cfengine’s module hooks are remarkably weak; modules only get a list of defined classes from Cfengine, not a list of defined variables and their values, which would include such necessities as base config directories, the policy host(s), etc. I found the modules to be almost absurdly underpowered for my purposes, so I took a different tack.
!A real solution
Instead of writing a module, I wrote a short Perl script that parses a config file into a Cfengine config file. I even made the syntax of my iptables config file like a Cfengine config file. Here’s a snippet:
{{{
any::
Open 22/tcp
Restrict 5308/tcp,5666/tcp To $(policyhost)
ldapservers::
Campus 389/tcp
webservers::
Open 80/tcp
}}}
Since it creates a Cfengine config file, variables like $(policyhost) will be parsed later. With this config file in place, and the parsing script in cron, you need only to define a class with Cfengine and define its list of ports in the new config file (which I called cfiptables.defs), which is much less verbose than what you saw above. The following directives are available in the script:
;Open
;Restrict
;Campus
;Self
;Not
Note that you can add ports to the iptables config file apart from Cfengine and they will stay open unless they are specified in a “Not” directive. (This is in line with the convergent operation of Cfengine.) I didn’t design this script to protect against potentially malicious, foolish, or dunderheaded admins.
You can specify a comma-separated list of ports, or you can specify a port range with, e.g., “4000:4004/tcp” to open all ports (inclusive) in that range.
!Non-Redhat boxes
We use this successfully without modification on boxes running RHEL 3 and 4, Centos 4, and YellowDog Linux. We also use the same scheme on SuSE boxes (9.3 and 10.0), but that requires a little more work. SuSE uses a firewall based on iptables, but their config file is __very__ different. What we do is simply disable SuSEFirewall, copy over a modified version of the iptables SysVinit script from Redhat, and install basic /etc/sysconfig/iptables and /etc/sysconfig/iptables-config files; from there, our rules above can do the rest. (iptables-config manages a few options for iptables; we don’t actually edit that file at all.) You can find those files here:
* [iptables-init|http://www.nebrwesleyan.edu/people/stpierre/iptables/iptables-init]: Init script for SuSE boxes
* [iptables-base|http://www.nebrwesleyan.edu/people/stpierre/iptables/iptables-base]: Base /etc/sysconfig/iptables
* [iptables-config|http://www.nebrwesleyan.edu/people/stpierre/iptables/iptables-config]: /etc/sysconfig/iptables-config
I use the following Cfengine directives to distribute these files:
{{{
classes:
iptables_exists = ( FileExists(/etc/sysconfig/iptables) )
copy:
iptables.SuSE::
$(master)/iptables-init dest=/etc/init.d/iptables mode=744
type=checksum owner=root group=root server=$(policyhost)
backup=false
$(master)/iptables-config dest=/etc/sysconfig/iptables-config mode=644
type=checksum owner=root group=root server=$(policyhost)
backup=false
iptables.!iptables_exists::
$(master)/iptables-base dest=/etc/sysconfig/iptables mode=644
type=checksum owner=root group=root server=$(policyhost)
backup=false
}}}
The iptables class is specified explicitly elsewhere as a list of hostnames.
!Other stuff
In addition to all of that setup, you need to make sure that iptables gets started initially and on every subsequent reboot, and that it gets restarted every time its config file is changed. These rules will suffice:
{{{
shellcommands:
iptables.restart_iptables::
“/etc/init.d/iptables restart”
iptables::
“/sbin/chkconfig –add iptables”
“/sbin/chkconfig iptables on”
}}}
The restart_iptables class is defined automatically when the iptables config file is edited by Cfengine.
!Get the script
If you’ve read this far, you’re probably champing at the bit to get the script. It can be found [here|http://www.nebrwesleyan.edu/people/stpierre/iptables/cfiptables.pl]. By default, it reads “/var/cfengine/inputs/cfiptables.defs” and writes to “/var/cfengine/inputs/cfiptables.conf”; you’ll want to use the import directive of Cfengine to include cfiptables.conf in your config. You may also need to edit your update.conf to make sure that cfiptables.conf gets copied out to all of your Cfengine clients.
You may also want to edit cfiptables.pl and make the “Campus” directive more meaningful to you, in both name and function; change lines 43 and 44 if you so desire.
!The “So What?”
Setting up iptables is a largely trivial way to make your machines more secure. While the payoff might not be huge, setting it up is so simple that there’s really no reason not to do it. Using Cfengine to set it up can be even easier, especially if you use this script; once you get a sizable cfiptables.defs file written, turning on iptables for a host should be as simple as adding it to the iptables class. With such a low barrier to entry, making iptables another layer in your security onion becomes a practically mandatory in terms of a cost-benefit analysis.
As with any post this long, it’s altogether probable that I’ve forgotten something. The post will probably be edited several times over the next few days, so if something doesn’t jive, drop me a line and check back later.