Set up your firewall with Firewall Builder

Firewall Builder (fwbuilder) is a graphical application that can help you to configure IP traffic filtering. It can compile the filtering policy you define into many specifications, including iptables and various languages used by Cisco and Linksys routers. Separating the actual policy you define and the implementation in this way should let you change what hardware is running your firewall without having to redefine your policy for that platform.

Packages for fwbuilder are available in the Ubuntu Hardy and Fedora 9 repositories. fwbuilder is packaged as a 1-Click install for openSUSE 10.3, but not for version 11 as yet. In this article I’ll build from source on a 64-bit Fedora 9 machine using fwbuilder version 2.1.19. fwbuilder is shipped as two tarballs: libfwbuilder and fwbuilder. You have to install the library first. Install the two packages using the normal ./configure; make; sudo make install procedure. I found the below warning during configuration; if you get it, you can ignore it.

Running qmake: /usr/lib64/qt-3.3/bin/qmake
WARNING: icns.path is not defined: install target not created

When you start fwbuilder, you’ll see the window shown behind the new firewall dialog in the screenshot below. By right-clicking on the Firewalls item in the tree view you can create a new firewall. If you choose to enable firewall templates and create an iptables firewall, you will see the dialog window shown. Because fwbuilder has a selection of firewalls that are identical or close to what many users will want to use, it makes getting started much simpler.

Template 1, shown in the screenshot, supports a dynamic IP address assigned by your ISP and a local fixed private subnet on a second network interface of the server. Template 2 is similar to template 1 but is designed for the server to be a DHCP server for your local network. Template 3 is designed for setting up a demilitarized zone (DMZ) subnet by having three network interfaces on the server — one facing the Internet with a static IP address, a local private subnet, and a DMZ subnet that is accessible from the Internet.

The fourth item on the list, host fw template 1, simply protects a single host, only allowing incoming SSH access. While the policy for this sort of firewall is simple, having it in the list allows laptop users to install a firewall quickly. The linksys firewall template is designed specifically to run on Linksys routers, while the c36xx is an example for Cisco routers. The web server template allows HTTP and SSH traffic for the server that is running the firewall.

The firewall rules for Template 1 are shown in the screenshot below. As you click on each cell in the grid in the top of the window, the bottom pane changes to allow you to edit the data in that cell. Instead of simply entering a TCP connection type and a port number, the template firewall offers the SSH service as an option in the tree view on the left side, which is what this rule is using to define where the connection is destined. The service that the template refers to is part of the system definitions and is read-only, allowing you to see the details in the pane but not edit them. If you are running SSH on a custom port, you can either edit the system catalog for SSH or right-click it in the left tree view in the standard (system) catalog and select “Duplicate/Place in library User” to create a personal copy of the service. The drop-down list just above the tree view on the left lets you select either the standard (system) or user catalog.

When you have your own copy of the SSH service port definition you are free to edit it. To use your version of the SSH service definition, you can drag and drop it from the left tree view into the service cell of a rule for your firewall. Although this all works well, one user interface issue here is that both the definition in the standard (system) catalog and your user catalog for the SSH service have the same name. That means that if you drag your user SSH service into the service cell, you will see two SSH entries in that cell and have no indication that one is your personal catalog version while the other is the standard (system) catalog version. This is easy to work around by renaming your user catalog SSH service definition.

When you click on the firewall itself in the left tree or any cell in the grid showing the firewall policy in the top of the window, you can edit both the host and firewall settings. In the host settings you will find options to set the paths of specific tools on the machine, override various TCP settings such as the FIN and keep-alive timeouts, as well as turn on Explicit Congestion Notification (ECN), timestamps, and SYN cookies. More general host options include turning on kernel antispoofing support, whether source routing should be ignored, and how to treat various ICMP packets. The template 1 firewall does not explicitly change any of these settings from their defaults.

Clicking on the firewall in the left tree and clicking on the “Firewall settings…” button in the Firewall details section of the window lets you to set global options such as limits on the number of packets that are logged in a given interval, add a prolog and epilog to the generated firewall rules for handy tweaking, and specify various system paths that might need to be changed for custom installations. You can specify how to reject packets (which ICMP message to send back), say whether packets that are not associated with a known connection should be dropped by default, and specify whether shown established and related connections should be accepted before the first firewall rule is executed.

The NAT tab allows you to set up how the source and destination addresses of IP traffic are changed as it moved through the server. To have the server modify these addresses you set up a collection of rules and drag the network interface from the tree list in the left pane into the source and/or destination in the grid for a rule. NAT rules can be configured to be effective for source, destination, and service. They modify the connection source and destination address or change the port that the connection is finally sent to.

As shown in the screenshot below, the network interfaces are given descriptive names and shown in the left pane underneath the current firewall (here generated with template 1). You can of course modify the names and which network interface is associated with them and add new interfaces as needed. In the screenshot, any attempt to connect to myssh service on the Internet will have the source of the connection translated so that it appear that the connection originated from the firewall machine.

A particularly useful feature of fwbuilder is the ability to see all the uses of a service in your firewall and NAT policy. When you right-click on a service in the left side tree view or in the grid in the top of the window, you can select “Where used” to bring up a pane in the bottom of the window that allows you to jump to any rule in the NAT or firewall that references the service. This lets you audit what is able to connect to a service and see whether any NAT is being performed to allow that service to be used.

Defining rules that directly use services alone is often inconvenient, as there can be many services that work together to provide a desired functionality. fwbuilder lets you define “groups” that allow many individual service definitions to be considered as a single logical unit. For example, the Useful_ICMP group includes ICMP time exceeded messages, ping packets, and all ICMP unreachable packets. Groups allow a particular piece of server functionality to be defined as a single unit. The use of groups lets you edit more logical “functionality” units rather than having to remember each time exactly what services are used for a particular interaction you want to allow.

Having NAT and routing definitions in a single tool is convenient. It lets you set up how traffic flows, is mangled as it flows, and possibly denied in a single tool. The ability to set up a firewall using drag and drop and by copying network addresses and services from a grid, together with the templates shipped with fwbuilder, make this a very useful tool for quickly creating a packet filtering policy. The standard repository in the left tree view includes a nice selection of 192.168 and 172 and 10 private subnets, services and groups of services, and some time definitions, to allow the firewall rules to change during the week.

Wish list

Changing the color of the tree view on the left side when it is showing the user or system catalog is a great touch that allows you to keep track of which catalog you are viewing without much thought. Unfortunately, there are some areas where fwbuilder is not so user-friendly. For example, when you compile a firewall, if your policy is not 100% correct, error presentation requires you to remember which rule was causing the error, dismiss the compilation error dialog, and manually select that rule. It would be nice if fwbuilder made an attempt to parse the output and let you double-click the error message to jump directly to the offending rules, perhaps with the error message shown in an additional pane at the bottom of the window so you retain the context information. It would also be nice if, when you are planning to move a rule up only a few rows, you could right-click a rule and select Move Rule and then drag and drop the rule instead of having to manually enter the new rule number. Finally, when you install a firewall from fwbuilder, you are prompted for the user name and server to connect to for installation, and a connection is then made over SSH to that machine to install the firewall policy. It would also be nice to be able to simply export the iptables file for manual installation.