I believe that any network or system administrator who wishes to maintain an iptables firewall should learn iptables well, and be able to easily whip up a basic firewall from scratch. But learning how to do this is the tricky part, so this is where firewall builder programs earn their beans. With a firewall building utility you can get a functioning firewall up and running, and have scripts and rulesets to study. There are gazillions of the things, so today we’ll look at three that I think are pretty good: Lokkit, KMyFirewall, and Firewall Builder.
Netfilter/iptables is the basis for the vast majority of Linux-based firewalls. It filters on any of the fields in IP, TCP, and UDP packets, which gives the ace admin great flexibility and packet-filtering powers. The netfilter/iptables package is an amazing construct, and very effective. However, there is a rather steep learning curve, and the various Linux distributions do not make it any easier. Red Hat and its derivatives, and Debian and its spawn, make iptables way too complicated with large tangled scripts. Debian 3.1 does away with init scripts entirely, and now wants users to control iptables with ifupdown, so that iptables comes up and down with the networking interfaces. While I’m always game for good new ways of doing things, this one has me puzzled. I prefer to keep networking and iptables separate for easier debugging, and having iptables come up at boot means I don’t have to worry about introducing an additional potential point of failure. It remains in whatever state I want it, up or down, regardless of whatever networking craziness might be happening.
You can still use traditional init scripts with Debian, or try out the newfangled method; see /usr/share/doc/iptables/examples/oldinitdscript.gz and /usr/share/doc/iptables/README.Debian.gzfor more information.
Lokkit is a decent choice for a personal firewall. Lokkit is not for the ace admin with a large complex network to protect. Lokkit uses an ncurses interface, so you don’t need X windows. Users who want a nice X windows interface can use Gnome-Lokkit.
Debian users will find that the installer creates and activates a basic firewall, which may or may not suit your needs, so you should re-run Lokkit to make sure it has the correct settings. Using it is dead easy- just start it up and answer a few questions. Lokkit uses only the Filter table, and creates a custom chain named “RH-Lokkit.” When you try writing your own rules, this makes it easy to separate what you did from Lokkit’s rules. It’s good practice, and if you irreversibly gum things up, just delete the iptables source script and reboot.
Red Hat and Fedora users can try the system-config-securitylevelcommand, which looks like Lokkit with a SELinux configuration menu.
Looking at Your New Rules
There are two ways to view iptables rules: read the source script, which for Lokkit is /etc/default/lokkit on Debian, and /etc/sysconfig/iptables on Red Hat, or use the iptablescommand. The Filter table is the default, so you must specify the NAT and Mangle tables to see them:
# iptables -L
# iptables -L -t nat
# iptables -L -t mangle
KMyFirewall is a recent addition to the world of firewall builders. It’s still a bit rough about the edges, but it has a lot of good things going for it. It writes nice clean scripts, and it tries to be educational. It requires KDE to run, but the scripts it generates can be used in any environment. It sets up complex firewalls easily, and you have the choice of using the wizard, the menu interface, or editing the scripts directly. It’s especially good at creating a strong, sensible workstation firewall with a few mouse clicks. This has some nice touches, like allowing ICMP echo_requests with a rate limit of five per minute. Blocking ICMP requests entirely is a popular thing these days, but it’s a bad thing to do, as a lot of network services depend on it.
(courtesy KMyFireWall project)
Another nice feature is the wizard configures egress filtering- be a good Netizen and don’t let bad packets leak out of your network. If you have any Windows hosts, be especially diligent with your egress filtering.
KMyFirewall is careful- you may preview your firewall script before activating it, and then you can test it before installing it. It lists all the files it creates, and gives you the commands you need to flush all rules and chains.
Its major drawback is it’s difficult to set up a proper multi-homed NAT firewall with the wizard, which makes it difficult to build a firewall/gateway that shares an Internet connection. You can use it to create all the custom rules you want, but if you know how to do that, you probably don’t need a firewall builder.
Firewall Builder is a good choice for more complex needs, such as a multi-homed NAT firewall, or a network with multiple firewalls. It is both a firewall builder and a management system. It incorporates RCS (Revision Control System), so you can easily track all versions of your firewall configurations.
(Courtesy Firewall Builder Project)
It comes with several good templates, such as simple Internet connection sharing with a dynamic WAN IP/ static LAN IP, which is typical of home networks on cable or DSL. A second template adds internal DNS/DHCP. A third template includes rules for a DMZ on a third network interface. There is a “host” template for protecting a workstation, and a Web server template. You’re not stuck with the default template rules, because all files generated by Firewall Builder are editable, and you can create your own templates.
Firewall Builder has a useful graphical interface that shows current states, rules, and interfaces all across your network. It is SNMP-aware, and includes a Network Discovery Druid for mapping your network. Be sure to get the User Manual .pdf, as it is a lot more useful than the man pages.
Just Say Yes to Firewalls
Every time the subject of firewalls comes up, you can count on two dissenting voices arising:
1. “If you properly configure your box you don’t need a firewall”
2. “Software firewalls are lame. Use a hardware firewall.”
#1 is theoretically true, but we live in the real world. Things change, mistakes happen, and layered defenses are a standard best practice. And why let your hosts be pummeled and your LAN congested by outside attacks? Head all that crap off at your Internet gateway. Even public services benefit from being firewalled. For example, there’s no need to subject your Web server to the endless SSH attacks infesting the Internet- block everything but port TCP 80. Same goes for all of your public services; reduce the load and potential compromises by diverting the junk.
#2 is one of those silly arguments from the Planet Bizarro. There is no magic in a “hardware firewall.” All firewalls are a combination of software and hardware. A firewall is effective because it is well-configured. A more accurate question is “is it better to have a standalone, dedicated firewall, or are host-based firewalls good enough?” I prefer a standalone, dedicated box. It reduces the load on the host PC, and it’s easier to maintain and secure, because you can jettison all the irrelevant bits. But well-made host-based iptables firewalls are perfectly good, too. So the definitive answer is “whichever you prefer.”