What's New in Firewall Builder 3.0

Mick Bauer introduced Firewall Builder to Linux Journal readers in 2003 with his article “Using Firewall Builder”. A lot of time has passed since 2003, the project has evolved, the appearance of the GUI has changed and many features have been added.

Open-source firewall implementations have gained momentum in recent years and now offer a viable alternative to commercial systems. These implementations include iptables (Netfilter) on Linux, PF on OpenBSD and FreeBSD, and ipfilter and ipfw on FreeBSD. These systems provide very respectable feature sets and good performance, but they provide only command-line access and plain-text configuration files. The syntax often is rather complex and different between the different tools, and definitely different from commercial firewalls. Administrators have to understand the internal structure and logic of the given firewall system in order to be able to design and maintain a configuration with the required level of confidence and reliability. For example, for iptables, you need to understand internal packet flow in the Netfilter engine to choose chains and targets correctly. Using the chain INPUT instead of FORWARD can mean the difference between a working service and a broken service. A simple error like this can cause the server behind the dedicated firewall to become inaccessible and at the same time create a hole allowing access to the firewall itself.

Many firewall appliances based on iptables or PF offer a Web-based GUI interface that helps configure them, but these interfaces tend to reflect the structure and ideas of the underlying configuration language closely.

Complex configuration languages and the need for the administrator to be aware of the internal packet flow in the packet inspection engine make management of these firewalls difficult. This is especially so in multivendor installations where the administrator manages router access lists, several dedicated firewalls and perhaps local firewall rules on servers. Constant switching between different configuration languages leads to errors. Coordinating changes across multiple devices in the network becomes difficult and risky. When a new service is added, administrators need to implement the same policy rule using different languages for different devices. Administrators have to become experts in all platforms in order to be able to make the same change everywhere. An error leads either to service downtime or a hole in the security policy, and both can be very costly.

Modern IT organizations most often operate on a network built with products from different manufacturers. Even in installations that standardize on one kind of OS for servers, there is usually the need to configure access lists on routers and rules on dedicated firewalls, which often are products of a different vendor.

One of the ways to help the situation is to switch to automated generation of the configuration. Several commercial systems and open-source projects try to tackle this problem. Automatic generation of the configuration has many advantages over manual processes. Automated systems treat configuration as a combination of standardized blocks, or objects, that present information in an abstract way. When administrators work with such an abstracted system, they do not need to switch between the configuration paradigms of different vendors in order to implement the same rule; they just work with the same abstract firewall all the time. Firewall Builder implements this approach to the generation of firewall configuration.

Firewall Builder is a GUI firewall configuration and management tool. It helps administrators design and build complex firewall rules for several open-source and commercial hardware and software platforms. With Firewall Builder, administrators can create configurations for iptables, PF, ipfilter, ipfw, Cisco IOS extended access lists and Cisco ASA (PIX). Administrators can configure policies for servers, dedicated firewalls and routers, all from the same GUI running on a workstation or laptop. Once all rules have been created or modified, administrators can use the same program to update the configuration of all devices using SSH for secure connections.

Firewall Builder is an open-source project hosted on SourceForge at https://sourceforge.net/projects/fwbuilder. It comes with most major Linux distributions, such as Debian, Ubuntu, Fedora, OpenSUSE and Mandriva. You can install it using your favorite package manager—just look for the package fwbuilder and its dependencies. Because these distributions work on their own schedules, which are not coordinated with Firewall Builder releases, the packages they offer usually are one or two revisions behind the latest released package. Because of this, we offer our own repositories of deb and rpm fwbuilder packages. Packages in these repositories are signed with our GPG key for verification. We offer two repositories: stable and testing. The stable repository provides the latest stable release of Firewall Builder, and the testing repository is used to distribute packages to the beta testers while we work on the next version. Instructions for how to set up your system to use our repositories are available on our Web site (www.fwbuilder.org/docs/firewall_builder_packages.html).

Once the program has been installed, you can launch it from a command line using its name fwbuilder or via a main GNOME or KDE menu under System→Administration.

Firewall Builder is a rather old project; it has been around since 2001. During this time, the program has evolved into a mature, production-ready tool used by hundreds of system administrators every day. The most recent version, 3.0, was released in fall 2008, and since then, it has seen a few maintenance releases that provided bug fixes and minor improvements. This article focuses on the features that were introduced in Firewall Builder 3.0.

Figure 1. Main GUI Elements

The main window of the program (Figure 1) includes an objects tree on the left (1), brief information about the object selected in the tree (2), current firewall policy view (3) and a dialog panel where administrators can edit object parameters (4). All servers, firewalls, subnets, individual addresses and services are represented by objects in the tree. Each object has attributes that describe its parameters; the combination of these attributes is different depending on the object type. Objects are arranged in the tree so that each object type has its own folder or branch.

Figure 2. Main Window with Two Data Files Opened at the Same Time

Expanding on this concept, Firewall Builder 3.0 allows you to open multiple data files at once (Figure 2) and move objects between them using drag-and-drop or copy/paste operations. You can expand one data file so that it occupies the whole window, or you can arrange several data files so they are all visible at the same time.

Once objects are created to represent a network, you can create a firewall object and start building security policy rules. Firewall Builder 3.0 comes with a library of templates representing some typical firewall configurations. The simplest way to get started is to create a new firewall from one of these templates and then make changes to reflect your network's addresses and configuration.

Figure 3. Creating Firewall Object Using a Template

Figure 3 shows the dialog where you can choose which template to use to create a new firewall object. This view shows the creation of a new firewall object with three interfaces that will have the IP addresses shown in the dialog. Most likely, your network uses a different addressing schema, and these addresses don't match what you have. You can use the “search and replace” function in the GUI to replace them. Other templates that come with the program represent a firewall with one or two interfaces, a Cisco router, a server and a small residential firewall based on Linksys hardware. Firewall objects created from templates come not only with all the interfaces already configured, but they also come with a small set of rules to implement a basic security policy. Of course, you should edit these rules to adapt the configuration to your security policy requirements. The rules created by the templates serve as an illustration of how practical rules can be built in Firewall Builder and as a starting point for your own policy design.

Template objects provide a quick way to create new firewall configurations, but they are limited in number and variety. If no template is close to your configuration, you can create a firewall object and all its interfaces manually. In addition to that, if your firewall machine runs the SNMP dæmon, you can have Firewall Builder “discover” its configuration automatically.

Now that the firewall object and objects for its interfaces have been created, you can add some rules. Figure 4 shows a fragment of a firewall policy.

Figure 4. Example of Policy Rules

As in the previous versions of Firewall Builder, policy rules have fairly typical columns: source, destination, service, interface, direction, action, time, options and comment. An address object placed in the source rule element means the packet's source address must match it in order to match the whole rule. The same goes for the destination. A service object defines ports for TCP and UDP protocols or type and code for ICMP messages. When a service object appears in the service rule element, the packet must match attributes of the object in order to match the rule. You can place objects in rules by dragging them from the tree or by using a copy/paste operation.

Firewall Builder 3.0 adds support for rule grouping. Figure 4 shows a group of rules with the title “Access to and from firewall” that consists of four rules. These rules form a group that can be collapsed so that only its title is visible (Figure 5).

Figure 5. Example of a Collapsed Group of Rules

You can greatly improve the readability of the whole rule set if you arrange rules in groups. This helps maintain a good visual reference to the internal logic when several rules work together to implement some part of the security policy. You also can collapse groups you are not working with at the moment to make more rules fit on the screen at once.

With IPv4 address space depletion on the horizon, IPv6 roll-out is starting to pick up speed. Firewall Builder 3.0 comes with support for IPv6. The program provides several new types of address and service objects that represent IPv6 addresses, networks and services. An example of an interface with an IPv6 address is shown in Figure 6.

Figure 6. Interface eth1 has an IPv6 address.

In Firewall Builder 3.0, an interface object can have several different types of child objects: a MAC address, an IPv4 address and an IPv6 address. Policy and NAT rule set objects now have an attribute that defines which address family they should match. Figure 7 shows an example of an IPv4-only policy.

Figure 7. Example of a Policy Object Configured as IPv4-Only

The drop-down list of address family options is shown in Figure 8. The address family options are:

Figure 8. Different Address Family Configuration Options for a Policy or NAT Object

Let's see how the program converts some simple rules in the combined IPv4+IPv6 rule set into an iptables script. The rules are shown in Figure 9.

Figure 9. Example of Mixed IPv4+IPv6 Rules

The first rule uses the interface object of the firewall that represents its loopback interface, and the second uses the object representing the firewall itself and two service objects: “http” and “ipv6 any ICMP6”. The rule that permits any protocols on loopback should be similar for IPv4 and IPv6, but the rule that permits http and any ICMP6 will look different. Here is what the generated iptables script looks like:

# ================ IPv4
#
# Rule Policy_mix 0 (lo)
#
iptables -A INPUT  -i lo -m state --state NEW -j ACCEPT
iptables -A OUTPUT  -o lo -m state --state NEW -j ACCEPT
#
# Rule Policy_mix 1 (global)
#
iptables -A INPUT -p tcp -m tcp --dport 80 \
    -m state --state NEW -j ACCEPT

# ================ IPv6
#
# Rule Policy_mix 0 (lo)
#
ip6tables -A INPUT  -i lo -m state --state NEW -j ACCEPT
ip6tables -A OUTPUT  -o lo -m state --state NEW -j ACCEPT
#
# Rule Policy_mix 1 (global)
#
ip6tables -A INPUT -p tcp -m tcp --dport 80 \
    -m state --state NEW -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m state \
   --state NEW -j ACCEPT

IPv4 rules are loaded using the iptables command-line utility, while IPv6 rules are loaded using ip6tables. The rule that permits anything on loopback produces very similar iptables commands. The difference is only in the choice of the command-line tool used to add them. The rule that permits http and any ICMP6, when compiled for IPv4, generates only an iptables command to match TCP port 80. This is because ICMP6 service makes sense only in the IPv6 context, so it is dropped from the rule when it is compiled for IPv4. When this rule is compiled for IPv6 though, both services are used and we get two iptables commands, one for TCP port 80 and another for protocol ipv6-icmp.

Mixed IPv4/IPv6 rule sets can be especially useful when IPv6 is added to an existing IPv4 network. Because most firewalls and routers require different syntax for IPv6 ACL and rules, you have to implement a second rule set for IPv6, carefully trying to copy existing IPv4 rules to preserve the general structure and meaning of the security policy. Things become even more complicated after that, because every change in the policy should now be reflected in two sets of ACL or firewall rules. Keeping these synchronized quickly can turn into a major task that can increase the probability of human error and network outages significantly. Mixed IPv4+IPv6 rule sets in Firewall Builder help solve this problem, because two iptables scripts are generated automatically from the same set of rules.

Figure 10. How to Create a Branch in the Rule Set

Another important new feature in Firewall Builder 3.0 is support for branching rules and multiple rule sets. Firewall objects now can have several sets of policy rules; each set is represented by a Policy object in the tree. Figure 10 shows firewall object fw2 that has two Policy rule sets that appear as objects in the tree: one has the name Policy, and the other has the name rate_limit. When the firewall object platform is set to iptables, rules in each of these additional Policy rule sets are placed in a chain with a name that is the same as the name of the rule set object. If the target firewall platform is set to PF, rules are placed in an anchor with the same name.

To create a branch in your rules, choose the Chain rule action, and drag another policy object into its editor panel, as shown in the screenshot.

This configuration translates into an iptables command with the target option -j rate_limit that passes control to that chain.

Multiple rules can use the Chain action to pass control to the same branch rule set if necessary. Abstraction of branching rules in Firewall Builder opens access to the very powerful mechanism of chains and anchors in the underlying firewall software. This can be used for rule optimization or to build dynamic policies where a branch rule set is populated by an external script at runtime.

Firewall Builder 3.0 comes with a large Users Guide in PDF and HTML formats, full of examples and step-by-step instructions. The Guide includes the Firewall Builder Cookbook that describes many typical problems and solutions.

As you can see, Firewall Builder 3.0 comes with many new features and improvements that make the upgrade worth your while. The main driver in the development is bug reports and feature requests that come from users, so please visit our Web site at www.fwbuilder.org, and help us make Firewall Builder even better.