New Features In Firewall Builder 4.0 - Page 2

Customazable templates ("configlets")

Configlets: generated firewall script (for all platforms) is assembled from small fragments we call "configlets". These fragments are located in the "/usr/share/fwbuilder-4.0.0/configlets" (on Linux). Each configlet is a template that uses specially defined macros which the program replaces with actual strings and values when it generates firewall configuration. There are separate templates for different firewall platforms and for different parts of the configuration file to be created. Supported macro language includes simple variable expansion and conditional "If - then" construct. You can override configlets we provide with your own if you create directory "fwbuilder/configlets" in your home directory and place files with the same name there. You need to retain the structure of subdirectories inside this directory, that is, the directory should be "$HOME/fwbuilder/configlets/linux24" for the configlets installed in "linux24" subdirectory under "/usr/share/fwbuilder/configlets". This way, you can change virtually all aspects of generated configuration file to suite your needs without having to touch C++ code and recompile the whole project.

Built-in policy installer also gets commands that it needs to execute on the firewall from configlets. Two configlets are used for Unix-based firewalls (Linux, OpenWRT, Sveasoft, IPCOP and its variants, OpenBSD, FreeBSD, MacOSX, Solaris): "installer_commands_reg_user" and "installer_commands_root". You can change the behavior of the installer without having to touch C++ code, just create a copy of the configlet file in $HOME/fwbuilder/configlets and modify it.

This is the first time we introduced configlets to Firewall Builder. At this time, the macro language is rather primitive and will improve in the future, for example we need to add support for the if-then-else construct and interations. Most configlets document variables they use (and fwbuilder knows about) at the top of the configlet file.

Chapter “Configlets” in Firewall Builder 4.0 User's Guide explains the macro language used in configlets and demonstrates how administrator can use this feature to change script generated by fwbuilder.

Changes in the structure of generated Linux firewall script

Generated iptables script now has standard structure per LSB ("Linux Standard Base Core Specification 3.1"). The script supports standard actions controlled by the command line arguments "start", "stop", "reload", "status". Action "start" reconfigures interfaces, flushes current iptables tables and chains and finally loads new iptables configuration. Action "stop" flushes all tables and chains and sets default policy in all chains to "DROP" to shut down the firewall to all kinds of traffic. Note that the "backup ssh access" rule that was available in the previous versions of fwbuilder now has an option that can make the script install this rule even when it drops all other iptables rules when called with command "stop". This means, you can call the script with command "stop" to completely shut down all traffic to and through the firewall, but still retain access to the firewall via ssh. Action "status" finishes with return code per LSB specification. Code 0 means the firewall is loaded and is running (but it does not check that the rules it is running with are those defined in fwbuilder). Return code 3 means iptables modules are not loaded or there are no tables. This return code means the firewall is not running or not configured. The script also supports additional actions "interfaces" and "test_interfaces". Action "interfaces" executes only commands that manage ip addresses of interfaces, configure vlan, bridge and bonding interfaces. Action "test_interfaces" runs the same commands in the test mode when it prints commands that would be executed but does not actually execute them. Chapter “Configuration of interfaces” in Firewall Builder 4.0 User's Guide explains interface configuration in great details.

Support for high availability firewall configurations

The most significant improvement in Firewall Builder 4.0 is of course introduction of support for the firewall clusters. The code for this feature was originally contributed to the project by the developers from Secunet Security Networks AG, Germany. Their original add-on supported SecunetWall firewalls, we have extended it, improved the GUI and added support for OpenBSD (CARP) and PIX clusters as well.

In a typical High Availability (HA) configuration the firewall or a server is replaced with two or more machines running special software that alows them to monitor status of each other. These machines share common resources, such as IP addresses, and when one of the machines fails, others take over resources it used. Firewall Builder generates firewall configuration for each member of the cluster.

The idea is to manage configuration for multiple member firewalls using single object that we call "Cluster" in Firewall Builder GUI. The program then makes sure generated configuration for each member firewall includes necessary rules to permit packets generated by the HA software. You can build policy and NAT rules just using object that represent the cluster and the program will use IP shared addresses that belong to the cluster and addresses that belong to each individual machine. This saves time and helps avoid errors because you do not need to replicate configuration changes manually in the rules of each member firewall.

Firewall Builder can generate firewall rules that support both failover and state synchronization protocols for clusters build with iptables, PF or PIX and in some cases cluster configuration itself as well. The following state synchronization and failover protocols are supported at this time:

Table 1. Supported state synchronization and failover software

Firewall Builder automatically generates policy rules to permit packets of these protocols when it sees firewall cluster configured with one of them. You can use cluster object and its interfaces instead of the member firewall objects or their interfaces in policy and NAT rules and the program will substitute correct addresses when it generates iptables script or PF or PIX configuration.

The new object "Cluster" represents an HA pair of firewalls. To establish correspondence between interfaces of the pair, we add Interface objects to the Cluster. Cluster interface object is an abstraction that serves two purposes: it ties together corresponding interfaces of the member firewalls and also it provides the place to store configuration of the failover protocol that runs on these interfaces of the members. Each cluster interface object has child object "Failover group" with the name "firewall:eth0:members" or similar. This is where you configure associated member firewall interfaces. Figure 8 illustrates this. Blue arrows show that failover group object "linux-cluster:eth0:members" holds pointers to interfaces "eth0" of member firewalls "linux-test-1" and "linux-test-2". Interface object "eth0" that belongs to the cluster "linux-cluster" represents interfaces "eth0" of these member firewalls in all policy and NAT rules. IP address objects that belong to the cluster interface represent shared IP addresses managed by the cluster software. In Linux cluster, these are the addresses managed by vrrpd or heartbeat daemons. In OpenBSD cluster, these addresses belong to the "carp0" interface. Cluster interface object can have more than one address, just like the cluster software can manage several addresses.

Now if you need to build a policy rule for the cluster that should match eth0, you can just use cluster interface object "eth0" in the rule and the program will use IP address of eth0 of the member firewall when it compiles rules for that member.

Failover group object also has an attribute that defines the type of the failover protocol used on these interfaces of the member firewalls and a set of parameters for this protocol, such as VHID for CARP, an address and port for heartbeat and so on. Since failover protocol configuration is stored separately with each cluster interface object, it is easy to configure clusters running different protocols on different interfaces or running failover protocol only on some interfaces.

Another new type of object that is used to build cluster configuration is "State Sync Group" object. This object is a child of a Cluster and is located immediately under it in the object tree (Figure 9).

State synchronization group object is used to store information about interface of the member firewalls used to run state synchronization protocol and parameters of this protocol. At this time Firewall Builder supports conntrackd protocol for Linux, pfsync for OpenBSD and PIX synchronization protocol for Cisco ASA (PIX) appliances. Firewall Builder automatically generates policy rules to permit packets of the protocol and in some cases configuration of the protocol software.

Firewall Builder provides convenient wizard-like dialog that helps create new cluster object from existing individual firewall objects. You start with the list of firewall objects where you choose which firewalls should become members of the cluster. Next, the program finds interfaces of the member firewalls that have the same name and can be part of the cluster and creates cluster interfaces with the same name (Figure 6). Not all interfaces are eligible, for example bridge ports, bonding interface slaves or parents of vlan interfaces can not be used for the cluster. You can add, remove or rename cluster interfaces, as well as change which interfaces of the member firewalls are used with each one. On the next page of the wizard you can change failover protocols and add, remove or change IP addresses of cluster interfaces. Finally, you can choose to use policy and NAT rules of one of the member firewalls to populate Policy and NAT rule sets of the new cluster. If this is done, all references to the original member firewall and its interfaces in rules are replaced with references to the cluster and its interfaces. The program also creates backup copies of the member firewall objects with the name with suffix "-bak" and clears Policy and NAT rule sets of the member firewall objects used with the cluster before new cluster is created.

Figure 6. New cluster wizard

To generate script or configuration files for both member firewalls, you need to compile cluster object just like you normally compile standalone firewall. Use toolbar buttons or context menu to do this. The program will compile cluster Policy, NAT and Routing rule sets twice, for each member firewall. As the result, it produces two scripts or configuration files, one for each member. Built-in policy installer then can install these geenrated files on the member firewalls.

Figure 7. Compiling and installing cluster configuration