Ubuntu Linux Help » fwbuilder

Using The Host Object in Firewall Builder

Vadim Kurland — Wed, 15 Jul 2009 20:58:06 +0000

This article continues the series of articles on Firewall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced on this site earlier with articles Getting Started With Firewall Builder, Using Built-in Policy Importer in Firewall Builder, Using Firewall Object in Firewall Builder.

More information on Firewall Builder, pre-built binary packages and source code, documentation and Firewall Builder Cookbook can be found on the project web site at www.fwbuilder.org. Watch Project Blog for announcements and articles on all aspects of using Firewall Builder.

This article demonstrates how you can work with Host objects in Firewall Builder.

The Host Object

The host object in Firewall Builder is designed to represent real hosts in the network: workstations, servers, and any other network node with an address. Just like real hosts, the host objects have interfaces, representing different physical connections to the network. Most Internet hosts will have just a single (visible) interface with a single IP address. In that case the actual interface and its name do not matter. For most foreign hosts, Firewall Builder will assign an arbitrary name “interface1” to the hosts interface. By using a tree-like hierarchy of hosts -> interfaces -> addresses it is possible however to specify the exact address and/or interface of a host in the case when it does matter. Both interfaces and addresses are represented by objects, which are organized in a tree. Interface objects sit in the tree directly under the host, and the address objects are located under their interfaces. The interface object can have either one or multiple addresses. An example of a host with one interface with multiple addresses is shown in the screenshot below. Host “test server” has three virtual IP addresses that all belong to the same interface “eth0”.

In Firewall Builder, the host object is an abstraction. It does not have to be restricted to an individual host. The following host object may represent single physical computer with three ip address, or a web farm that accepts connections on three IP addresses, each on a different computer.

Note: The host object cannot have any access, NAT or routing policy associated with it; only firewall objects can have policies.

Creating Host Object

To speed up the process and make it simpler, creating a new host object is aided by the wizard which collects all data needed for both the host and its interfaces and then creates the object. The screenshot above represents the first page of the wizard.

Enter the host name. Generally, this name does not have to be the same as the real host’s name. However, if you are going to use SNMP to populate the host’s interfaces, or if you are going to use DNS to look up interface IP addresses, the name does have to match.

You can create a new host from a template by checking corresponding checkbox on the first page of the wizard, or you can do it manually. Lets look at the manual process. To do this, click “Next” button to switch to the page where you can enter interfaces and their addresses.

If the new host object has a single interface (this, perhaps, is the most common case) then you just need to fill the entry field for its address and maybe MAC address and click Next. If the object’s name is the same as the real host name, then you can use the DNS Lookup button to get the address from DNS.

Here you can add interfaces to the new host object. Enter the interface name, address, and netmask in the appropriate fields, then click “Add” to add it to the list. (If the interface is dynamic or unnumbered, then click the appropriate checkbox instead of entering address information.) The “Update” button updates information for the interface that is selected in the list, and the “Delete” button deletes the currently selected interface.

This method only works for IPv4 addresses. If you need to add an IPv6 address, save the host object without the IPv6 address, then add the IPv6 address to the interface.

Note: You can always add, modify and remove interfaces of the new host object later using controls provided by the main window and the object tree view.

Editing a Host Object

The Host object dialog allows you to edit the following parameters:

Name — The Host object name.
MAC matching — If this option is activated, the policy compiler uses the MAC addresses of all interfaces of this host in the ﬁrewall rules. Not all ﬁrewall platforms support MAC address ﬁltering, so this option may have no effect on the generated ﬁrewall script. This is treated as a non-critical situation, and the policy compiler will only generate a warning while processing a ﬁrewall policy where such a host is used.
Comment — This is a free-form text ﬁeld which can be used to add comments.

Using Host Object in Rules

When Host object is used in a rule, it acts as a group of all of its addresses, that is, adresses that belong to all of its interfaces. The only exception is loopback interface; compilers skip its address when they replace Host object with its addresses.

Consider the following Host object. It has interface eth0 with two IP addresses and a MAC address, interface he-ipv6 with IPv6 address and a MAC address, interface lo (loopback) with its own IP address and interface sit0 (tunnel) with no address.

Lets put this host object in a rule as follows:

The rule set is configured as “IPv4 only”, so even though interface he-ipv6 has IPv6 address, fwbuilder will ignore it while generating iptables commands for this rule. Interface eth0 has two IPv4 addresses and both will be used. Here are iptables commands generated for this rule:

$IPTABLES -A FORWARD -p tcp -m tcp –dport 22 -m state –state NEW -j Cid6066X5981.1
$IPTABLES -A Cid6066X5981.1 -d 10.3.14.44 -j ACCEPT
$IPTABLES -A Cid6066X5981.1 -d 10.3.14.55 -j ACCEPT
$IPTABLES -A Cid6066X5981.1 -d -j ACCEPT

Lets see what we get for the same rule if we configure rule set object as “IPv4+IPv6″:

Since rule is now configured to compile for both address families, fwbuilder processes it twice, using on each pass only those addresses of the host that match address family. Here is what we get (these are relevant fragments of the generated script):

# ================ IPv4

# ================ IPv6

$IP6TABLES -A FORWARD -p tcp -m tcp –dport 22 -m state –state NEW -j Cid6066X5981.1
$IP6TABLES -A Cid6066X5981.1 -d fe80::a3:e2c -j ACCEPT

Using Firewall Object in Firewall Builder

Vadim Kurland — Thu, 02 Jul 2009 15:09:52 +0000

This article continues the series of articles on Fireall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced on this site earlier with articles Getting Started With Firewall Builder and Using Built-in Policy Importer in Firewall Builder.

Firewall Builder supports variety of object types, both simple such as address, network, host, or IP, TCP, UDP and ICMP services, as well as more sophisticated such as Firewall, Host, Address table, DNS name, User service. Firewall object is central to the program and is in the focus of this article.

General Description

A firewall object is designed to represent a real firewall device in your network. This firewall object will have interface and IP address objects that mirror the real interfaces and IP addresses of the actual device. In addition, the firewall object is where you create the access policy rule sets, NAT rule sets, and routing rule sets that you assign to your firewall device.

By default, a firewall has one Policy rule set, one NAT rule set, and one routing rule set. However, you can create more than one rule set using branching rules (for firewalls that support them). On the other hand, you don’t have to populate all the rule sets. You can, for example, create a Policy ruleset and leave the NAT and Routing rule sets empty. We explains more about policies and rule sets below.

To speed up the creation of a firewall object, Firewall Builder has a wizard that walks you through creating the object. The wizard has three options for creating a firewall object:

From a template: Firewall Builder comes with several pre-defined templates. You can use these to create a firewall that is close to your configuration, the modify it to fit your needs. This method is demonstrated in the “Getting Started with Firewall Builder” here or here.
Manually: You can provide interface IP address, subnet mask, gateway, and other parameters manually. You can add this information when you create the firewall, or you can add it later.
Via SNMP: Firewall Builder uses SNMP queries to learn about the network.

Creating Firewall Object Manually

To start the firewall object creation wizard, right-click the Firewalls folder in the User tree and select New Firewall.

The first page of this wizard is displayed.

Give the firewall object a name. Usually, this name will be the same name as the device, but it doesn’t have to be if you’re assigning interfaces manually. (If you will use SNMP or DNS to populate the interfaces, then the name must be the same as the device name.) Then specify the firewall software and OS. Leave the Use pre-configured template firewall objects checkbox unchecked. Click Next.

Select Configure interfaces manually and click Next.

Use this screen to add firewall interfaces. Populate the following fields for an interface, then click Add to add the interface. Then, populate the fields again for the next interface. If you make a mistake, click on the interface in the list, make your changes, then click Update.

Interface type: Indicate the type of interface. We explain interface types in more detail below. Briefly, though, a Regular interface has a static IP addresses, a Dynamic address interface has a dynamic address provided by something like DHCP, an Unnumbered interface never has an IP address (PPPoE connection, for example), and a Bridge por t is an interface that is bridged in the firewall.
Name: The name of the interface object in Firewall Builder must match exactly the name of the interface of the firewall machine it represents. This will be something like “eth0″, “eth1″, “en0″, “br0″, and so on.
Label: On most OS’s this field is not used and serves the purpose of a descriptive label. The label is mandatory for Cisco PIX though, where it must reflect the network topology. Firewall Builder GUI uses the label, if it is not blank, to label interfaces in the tree. One of the suggested uses for this field is to mark interfaces to reflect the network topology (’outside’, ’inside’) or interface purpose (’web frontend’ or ’backup subnet’).
Address: If the interface has a static IP address, specify it here. (In Firewall Builder version 3, this must be an IPv4 address. If you need it to be an IPv6 address, create the interface without an IP address, then add the IPv6 address after you have created the firewall object.)
Netmask: Use either a traditional netmask (255.255.255.0) or slash notation (24, without the actual slash) to specify the interface netmask.
MAC: If you like, you can also specify the interface physical address. The MAC address is not necessary, but it can be used to combat spoofing. If the feature is turned on and available, and interface object with MAC address is used in a policy rule, then the firewall will only accept packets from the given IP address if the MAC address also matches the one specified.

Once all the interfaces are configured, click Finish to create the new firewall object.

Note: You can always add, modify and delete interfaces later using controls provided in the main window.

Creating Firewall Object using SNMP discovery

If your firewall runs SNMP daemon, you can save yourself some time by using SNMP discovery to automatically create interfaces of the new firewall object.

Start by checking checkbox “Use SNMP” on the second page of the wizard and enter SNMP “read” community, then click button “Discover interfaces using SNMP”.

Firewall Builder will run series of SNMP queries to the firewall to read the list of interfaces and their addresses. Both IPv4 and IPv6 address can be imported. For IPv6 the firewall must support IP-MIB RFC4293. Once discovery process finishes, click “Next”.

Next page of the wizard offers an opportunity to review discovered interfaces and make adjustments if necessary. To change something, highlight an interface, edit its parameters in the dialog, then click “Update”. Finally when the process is done and you click “Finish” in the wizard, the program creates new firewall object in the tree and adds all configured interfaces and their addresses.

Editing Firewall Object

The Firewall Object represents the firewall machine and is the most complex object in Firewall Builder. It has three sets of controls that you can modify, not including the policy rule sets. All these controls become available when you double-click the firewall object in the tree.

The base controls let you specify the basic settings of the firewall, such as the name and firewall platform.

Name: Specify/change the name of the firewall object.
Platform: Specify/change the firewall software.
Version: Specify/change the version number of the firewall software. In most cases, you can leave this set to any.
Host OS: Specify/change the host operating system of the firewall device.
Inactive firewall: Check this box to make the firewall inactive. The firewall name will change to a regular font (instead of bold) to indicate that it is inactive, and the firewall will not be available for compiling or installation. Essentially, it’s a way to “comment out” the firewall without deleting it.
Host OS Settings: Opens the Advanced Settings dialog for the indicated Host OS.
Firewall Settings: Opens the Advanced Settings dialog for the platform/firewall software.

Host OS Settings Dialog

For explanations of the various controls, click the Help button in the dialog.

Firewall Settings Dialog

For explanations of the various controls, click the Help button in the dialog.

Interface Object

Interface objects belong to firewall or host objects. Interface objects cannot exist alone. The dialog for the interface object that belongs to the firewall or host provides controls for the parameters described here.

Name: The name of the interface object in Firewall Builder must match exactly the name of the interface of the firewall machine it represents. This will be something like “eth0″, “eth1″, “en0″, “br0″, and so on.
Label: On most OS’s this field is not used and serves the purpose of a descriptive label. Firewall Builder GUI uses a label, if it is not blank, to show interfaces in the tree. One of the suggested uses for this field is to mark interfaces to reflect the network topology (’outside’, ’inside’) or the purpose (’web frontend’ or ’backup subnet’). The label is mandatory for Cisco PIX though, where it must reflect the network topology.
Management interface: When firewall has several network interfaces, one of them can be marked as the ’management interface’. The management interface is used for all communication between Firewall Builder and the firewall. For example, built-in policy installer uses address of the management interface to connect to the firewall via ssh when it copies generated script or configuration file to it.
External interface (insecure): Marks an interface that connects to the Internet.
Unprotected interface: Marks interface to which Firewall Builder should not assign any access lists or firewall rules. Unprotected interfaces are recognized by policy compilers for Cisco IOS access lists and PF. Compiler for IOS ACL just skips unprotected interfaces and does not assign any ACL to them when it choses which interface to associate given ACL with. Compiler for PF generates “set skip on ” clause for unprotected interfaces.
Regular Interface: Use this option if the interface has an IP address assigned to it manually (static IP address).
Address is assigned dynamically: Use this option if the interface has a dynamic address (obtained by means of DHCP or PPP or another protocol). In this case an address is unknown at the moment when Firewall Builder generates the Firewall policy. Some firewalls allow for using the interface name in the policy instead of its IP address; the firewall engine then picks its address either when the policy is activated or even at run-time. Some other firewalls support special syntax for rules that are supposed to match packets headed to or from the firewall machine. Examples of these two cases are OpenBSD PF and Netfilter. PF rules can be constructed using interface names; PF automatically uses the current interface address when it loads rules into the memory. Netfilter supports special “chains” called “INPUT” and “OUPUT” that are guaranteed to inspect only packets headed for the firewall machine (“INPUT”) or originated on it (“OUTPUT”). Both methods allow Firewall Builder to build correct firewall policy rules that affect the interface with a dynamic IP address, however the interface must be marked as such for the policy compiler to use proper technique depending on the target firewall platform. In cases where the rule has to use actual IP address of the interface (example: anti-spoofing rules), compiler emulates this feature by adding shell script fragment to determine the address at the time when firewall script is executed and then uses the address in rules. Such emulation is only possible on platforms where firewall configuration is in the form of the shell script, most notably this is iptables script on Linux.
Unnumbered interface: Use this option if the interface can never have an IP address, such as the Ethernet interface used to run PPPoE communication on some ADSL connections, or tunnel endpoint interface. Although unnumbered interface does not have an address, firewall policy rules or access lists can be associated with it.
Bridge port: This option is used for port of bridged firewall. Compilers skip bridge ports when they pick interfaces to attach policy and nat rules to. For target firewall platforms that support bridging and require special configuration parameters to match bridged packets, compilers use this attribute to generate proper configuration. For example, in case of iptables compiler uses -m physdev –physdev-in or -m physdev –physdev-out for bridge port interfaces.
Security level: Depending on the firewall platform, the security level is either External/Internal or a numeric value between 0 and 100, with 0 being least secure and 100 being most secure levels. This field in the GUI dialog automatically shows controls appropriate to the current firewall. Not all firewall support the concept of a security zone.
Network zone: Network zone of this interface, used only with Cisco PIX (ASA). Network zone drop-down list shows all network objects and groups of addresses and networks present in the tree. Choose one of them to tell the compiler which networks and blocks of addresses can be reached through this interface. Usually the external interface (the one which connects your firewall to the Internet) has the Network Zone set to Any. It is also recommended that you create a group of objects to represent Network Zones for all other interfaces on the firewall. The compiler uses this information to decide which interface each ACL rule should be associated with based on the addresses used in the destination of the rule.

We will take a look at other object types in the next article.

Using Built-In Revision Control in Firewall Builder

Vadim Kurland — Thu, 25 Jun 2009 13:15:36 +0000

This article continues the series of articles on Firewall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced earlier with the article Getting Started With Firewall Builder. The series continued with articles on built-in policy importer and other topics.

This article demonstrates one of the more advanced features of Firewall Builder – built-in Revision Control System (RCS).

Firewall Builder GUI has built-in revision control system that can be used to keep track of changes in the objects and policy rules. If data file has been added to the revision control system, every time it is saved, the system asks the user to enter a comment that describes changes done in the file in this session and stores it along with the data. The program also assigns new revision number to the data file using standard software versioning system with major and minor version numbers separated by a dot. When you open this data file next time, the program presents a list of revisions alongside with dates and comments, letting you choose which revision you want to use. You can open the latest revision and continue working with the file from the point where you left off last time, or open one of the older revisions to inspect how the configuration looked like in the past and possibly create a branch in the revision control system. Here we take a closer look at the built-in revision control system.

We start with a regular data file which we open in the Firewall Builder GUI as usual. Note that the name of the file appears in the titlebar of the main window, here it is [test2.fwb]:

You can always see additional information about the file using main menu File/Properties. There is not much the program can report about this file that we do not know already. It shows full path where it is located on the file system and the date and time of last modification, but otherwise since it has not been added to the revision control system, there is no additional information it can report.

To start tracking revisions of this data file, use menu File/Add File to RCS, the program creates all necessary files and reports result in a pop-up dialog. If for some reason adding file to the revision control has failed, the program reports error in the same pop-up dialog. Firewall Builder FAQ “Using RCS” has a list of typical problems that may occur at this point.

Few things have changed in the GUI after the file has been added to the revision control system. First, besides its name the titlebar now shows its revision. Inital revision number after the file has just been added to the revision control is 1.1.

The File/Properties dialog shows that the file is now being tracked by revision control system and its current revision is 1.1. There is only one revision in the history and the comment is “Initial revision” which is added automatically by the program.

Let’s see how revision control system keeps track of the changes done in the data file. To demonstrate this, I am going to make a change in one of the objects, save the data file and check it (this creates new revision), then I’ll close it and open it again, first the latest revision where the change is present, and then previous revision where the change is absent.

Here is the rule set of this firewall I have started with, it is very simple and consists of just 5 rules:

Now I added one more rule (to permit HTTP to the firewall). This is rule #3, it is colored yellow:

Now I save ths file using menu File/Save and exit the program. Before I can do that, however, the program tries to check the file in to the RCS and presents a dialog where I can add a comment to document the change I made. I enter the comment and press Check file in button to complete operation. The file is now checked in and the program exits.

Now I restart the program and try to open the same file using File/Open. Since the file is now in RCS, the program presents the dialog with the list of its revisions. Each revision has a comment associated with it, shown at the bottom of the dialog. Note also that each revision also shows the user name of the user who checked it in which is very useful in a multi-user environment.

If I choose revision 1.2 (the latest) and open the file using button Open, I get my rules including rule that permits HTTP to the firewall:

If I choose revision 1.1 and open the file, I get the policy that looks like this (note revision number in the main window titlebar, it is 1.1):

The rule to permit HTTP to the firewall is not there because I opened old revision of the data file. Essentially, I rolled back the change I made in rev 1.2. If I only wanted to look how rules looked like in rev 1.1, then I can now just close the file and open its latest revision to continue working with it. I can not only just look at the rules in the old revision, I can compile them and install on the firewall if that is what I need to do. Note that this can break things if some protocols were added to the firewall rules later, but this can be useful if you need to test things as they were few days ago.

However if I want to roll back the change and continue without it, all I need to do is make the change in this revision (1.1) and then save and check it in. This will create a branch in RCS and I will be able to continue working with it later. The previous change, checked in as rev 1.2 will always be there though and I will always be able to revert to it if I want. The program does not merge branches, merging changes in XML files is a complex task and is not implemented at this time.

To illustrate creation of a branch, I am making a change to the revision 1.1 of the data file as shown on the next screenshot:

I then save and check this file in with appropriate comment. To check it in I use menu File/Commit. I then close the file using File/Close and reopen it again using File/Open. This accomplishes the same operation as in the example above in this document, except I do not close the program. When I try to open it, the program shows the branch and new revision 1.1.1.1 that I just created. Note that the time of the revision 1.1.1.1 is later than the time of revision 1.2:

Now if I open rev 1.1.1.1 and continue working with and check new changes in, the program will create revision 1.1.1.2 and so on.

This document demonstrates how built-in revision control system (RCS) in Firewall Builder GUI can be used to document changes in the file. It can also be used to roll back changes to previous revision both temporary or permanently. Using RCS helps establish accountability if several administrators can make changes to the policy of firewalls because RCS keeps track of the user name of user who checked changes in. RCS in Firewall Builder works on all supported OS, that is Linux, FreeBSD, OpenBSD, Windows and Mac OS X. On Linux, *BSD and Mac OS X it relies on system-wide installed rcs package, while on Windows rcs tools are installed as part of the Firewall Builder package. In general, I recommend always using RCS even in simple cases when only one administrator uses the tool. Ability to document changes and roll back if necessary are great advantages that help a lot to improve the process of security policy management.

Using Built-in Policy Installer in Firewall Builder

Vadim Kurland — Wed, 17 Jun 2009 16:32:36 +0000

This article continues the series of articles on Firewall Builder, a graphical firewall configuration and management tool that supports many Open Source firewall platforms as well as Cisco IOS access lists and Cisco ASA (PIX). Firewall Builder was introduced on this site earlier with articles Getting Started With Firewall Builder and Using Built-in Policy Importer in Firewall Builder.

After firewall configuration has been generated by one of the policy compilers and saved in a file on disk in the format required by the target firewall, it needs to be transferred to the firewall machine and activated. This function is performed by the component we call “Policy Installer” which is part of the Firewall Builder GUI.

Starting with version 2.0, Firewall Builder comes with built-in installer that uses SSH to communicate with the firewall. Installer works on all OS where Firewall Builder is available: Linux, FreeBSD, Windows and Mac OS X. On Linux, *BSD and Mac OS X it uses standard ssh client that comes with the system; on Windows it uses putty.

Installer needs to be able to copy generated firewall script to the firewall and then run it there. In order to do so, it uses secure shell. The program does not include ssh code, it uses external ssh client. On Linux, BSD and Mac OS X it uses standard ssh client ssh and secure shell file copy program scp that come with the system; on Windows it uses plink.exe and pscp.exe. Full directory path to ssh client program can be configured in the Preferences dialog (accessible via Edit/Preferences menu), however if you are on Linux, *BSD or Mac and use standard ssh client that is available via your PATH environment variable, you do not need to change default value there.

Installer works differently depending on the targert platform. In case of Linux and BSD based firewalls it uses scp to copy generated configuration files to the firewall machine and then uses ssh to log in and run the script. In case of Cisco routers or ASA appliance (PIX), it logs in, switched to enable and then configuration mode and executes configuration commands one by one in a manner similar to expect scripts. It inspects router’s replies looking for errors and stops if it detects one. In the end, it issues command write mem to store new configuration in memory and logs out.

Built-in policy installer has been designed to work with dedicated firewall machine, that is, when computer where you run Firewall Builder GUI and actual firewall are different machines. Nevertheless, it can be used when they are the same machine as well. The only difference is that in all commands below you would use the name or address of the machine where you run Firewall Builder instead of the name or address of the dedicated firewall. SSH client will then connect back to the same machine where it runs and everything will work exactly the same as if it was different computer.

How does installer decide what address to use to connect to the firewall

Installer does not use the name of the firewall to connect to, it always connects to its IP address. It starts by scanning interfaces of the firewall object looking for one that is marked as “Management interface” using checkbox in the interface object dialog. Installer will use address of this interface to connect to. The “management interface” checkbox looks like shown on the next screenshot:

If your firewall has multiple addresses and you want to use the one that is not assigned to its interface in the fwbuilder object, then you can overwrite the address using entry field in the “installer” tab of the “advanced” firewall object settings dialog, like this:

More about other input fields in this dialog below.

Finally you can overwrite the address on one-time basis just for the install session using entry field in the installer options dialog. This is the same dialog where you enter password:

This works for all supported firewall platforms, i.e. iptables on Linux, pf on OpenBSD and FreeBSD, ipfw on FreeBSD and Mac OS X, ipfilter on FreeBSD, Cisco IOS access lists and Cisco ASA (PIX). Regardless of the platform, installer follows the rules described here to determine what address it should use to connect to the firewall.

Configuring installer on Windows

You can skip this section if you run Firewall Builder GUI on Linux, *BSD or Mac OS X.

Here is the link to slide show that demonstrates the process.

Download and install putty.exe, plink.exe and pscp.exe somewhere on your machine (say, in C:putty). Download URL is http://www.chiark.greenend.org.uk/~sgtatham/putty/

Installer does not use putty.exe but it will be very useful for troubleshooting and for setting up sessions and ssh keys.

In the Edit/Preferences dialog, in the “SSH” tab, use “Browse” buttons to locate plink.exe. Hit “OK” to save preferences. If you installed it in C:putty, then you should end up with C:puttyplink.exe in this entry field. Do the same to configure path to pscp.exe.

You may log in to the firewall using regular user account or as root. See instructions below for an explanation how to configure sudo if you use regular user accounts. This part of the configuration does not depend on the OS you run Firewall Builder.

Before you try to use fwbuilder installer with plink.exe and pscp.exe, test it from the command line to make sure you can log in to your firewall. If this is the first time you try to log in to the firewall machine using putty.exe, plink.exe or pscp.exe, then it will discover new host key and ask you if it is correct and if you want to save it in cache. There are lots of resources on the Internet that explain what does this mean and how you should verify key accuracy before you accept it. If the key is already known to the program it will not ask you about it and will just proceed to the part where it asks you to enter password. Enter the password and hit “Return” to see if you can log in and see command line prompt from the firewall.

Here is the command (assuming you use account “fwadmin” to manage firewall “guardian”):

C:Usersvadim>c:PuTTYplink.exe -l fwadmin guardian

NOTE: Built-in installer does not use GUI ssh client putty.exe, it uses command line utilities that come from the same author plink.exe and pscp.exe. You can test with putty.exe but do not enter path to it in the SSH tab of the Preferences dialog in fwbuilder, it won’t work.

Configuring installer to use regular user account to manage the firewall:

Before v3.0.4 built-in installer could only use regular account to activate policy if this account was configured on the firewall to use sudo without password. Starting with v3.0.4 this is not necessary anymore because installer can recognize sudo password prompts and enter password when needed.

Create an account on the firewall (say, “fwadmin”), create a group “fwadmin” and make this user a member of this group. Most modern Linux systems automatically create group with the name the same as the name of the user account.
useradd fwadmin
Create directory /etc/fw/ on the firewall, make it belong to group fwadmin, make it group writable
mkdir /etc/fw
chgrp fwadmin /etc/fw
chmod g+w fwadmin /etc/fw
Configure sudo to permit user fwadmin execute firewall script and a couple of other commands used by fwbuilder policy installer. Run visudo on the firewall to edit file /etc/sudoers as follows:
Defaults:%fwbadmin !lecture , passwd_timeout=1 , timestamp_timeout=1
# User alias specification
%fwbadmin ALL = PASSWD: /etc/fw/.fw , /usr/bin/pkill , /sbin/shutdown
here is the name of the firewall. Installer will log in to the firewall as user fwadmin, copy firewall script to file /etc/fw/.fw and then use the following command to execute it:
ssh fwadmin@firewall sudo -S /etc/fw/.fw
Installer needs to be able to run pkill shutdown to kill shutdown command that may be running if you tried to install policy in testing mode before. In testing mode installer copies firewall script to temporary directory /tmp then runs command shutdown -r timeout to schedule reboot in a few minutes and finally runs firewall script. To cancel scheduled reboot you need to install policy again, with test mode checkbox turned off. In this case installer will copy firewall script to its permanent place and use pkill to kill running shutdown command to cancel reboot.
set up ssh access to the firewall. Make sure you can log in as user fwadmin using ssh from your management workstation:
ssh -l fwadmin
You may use either password or public key authentication; the installer will work either way. Use putty.exe or plink.exe to test ssh access if you are on Windows (see above for the explanation how to do this on Windows).
in the “installer” tab of the “firewall settings” dialog of the firewall object put user name you use to log in to the firewall (here it is “fwadmin”):
if you need to use alternative name or IP address to communicate with the firewall, put it in the corresponding field in the same dialog page
Make sure entry field “directory on the firewall where script should be installed” is set to /etc/fw. Firewall Builder is not going to create this directory, so you need to create it manually before you install firewall policy (see above).
Leave “Policy install script” and “Command line options” fields blank.

Configuring installer if you use root account to manage the firewall:

Create directory /etc/fw/ on the firewall, make it belong to root, make it writable
set up ssh access to the firewall. Make sure you can log in as root using ssh from your management workstation:
ssh -l root
You may use either password or public key authentication; the installer will work either way.
in the “installer” tab of the “firewall settings” dialog of the firewall object put “root” as the user name you use to log in to the firewall
Make sure entry field “directory on the firewall where script should be installed” is set to /etc/fw
Leave “Policy install script” and “Command line options” fields are blank

Configuring installer if you regularly switch between Unix and Windows workstations using the same .fwb file and want to manage the firewall from both

First of all, the .fwb file is portable and can be copied back and forth between Linux/BSD and windows machines. Even comments and object names entered in local language should be preserved since the GUI uses UTF-8 internally.

Built-in installer relies on path settings for ssh and scp in Edit/Preferences/SSH. Since preferences are stored outside of the .fwb file, the installer should work just fine when .fwb file is copied from Unix to Windows and back. Just configure path to ssh program in preferences on each system using default settings “ssh” on Linux and path to plink.exe on windows and give it a try.

Always permit SSH access from the management workstation to the firewall

One of the typical errors that even experienced administrators make sometimes is block ssh access to the firewall from the management workstation. You need your workstation to be able to communicate with the firewall in order to be able to make changes to the policy, so you always need to add a rule to permit this. Firewall Builder can simplify this and generate this rule automatically if you put an IP address of your workstation in the entry field on the first page of firewall settings dialog. Here is the screenshot that illustrates this setting for an iptables firewall; management station has an IP address 192.168.1.100

Using putty sessions on Windows

putty allows one to store destination host name or address, user name and bunch of other parameters in a session so that they all can be called up at once. If you wish to use sessions, do the following:

Configure putty as usual, create and test session for the firewall, test it using putty outside of the Firewall Builder. When you use session, firewall host name and user name are stored in the session file. Firewall Builder allows you to enter session name in the entry field in the firewall settings dialog where you would normally enter alternative address of the firewall. Comment next to the entry field reminds you about this. Just type session name in that field, leave user name field blank and save the settings.
Once you start the installer, do not enter user name in the “User name” field on the first page of installer wizard, however you need to enter the login and enable passwords. Configure the rest of installer options as usual, they do not change when you use putty sessions.

How to configure installer to use alternative ssh port number

If ssh daemon on your firewall is listening on an alternative port, then you need to configure built-installer so that it will run scp and ssh clients with command line parameters that would make them connect to this port. This is done in the “installer” tab of the firewall object “advanced” settings dialog as shown on the following screenshot (here we set the port to “2222″):

On Unix command line option that specifies port number is different for ssh and scp. It is lowercase -p for ssh and uppercase -P for scp. If you use putty tools plink.exe and pscp.exe on Windows, the option to specify alternative port number is -P (capital “P”) for both.

You can use the same input fields in this dialog to add any other command line parameters for ssh and scp, for example this is where you can confiugre parameters to make it use alternative identity file (private keys). This information is saved with a firewall object rather than globally because you may need to use different parameters for different firewall machines, such as different key files or ports.

How to configure installer to use ssh private keys from a special file

You can use the same entry fields in this dialog to provide other additional command line parameters for ssh and scp, for example to use keys from a different identity file. Here is how it looks like:

Here I configure ssh and scp to use alternative port and alternative identity file ~/.ssh/fwadmin_identity. The command line parameter for the port is different for ssh and scp, but parameter for the identity file is the same -i for both utilities.

On Windows, the simplest way (or may be the only way) to use alternative keys is to use putty sessions.

Troubleshooting ssh access to the firewall

Built-in policy installer will not work if ssh access to the firewall is not working. Test it using this command on Linux if use you user “fwadmin” to manage firewall:

ssh -l fwadmin firewall

If you use root account to manage the firewall, the command becomes

ssh -l root firewall

On Windows use putty.exe or plink.exe to do this:

C:Usersvadim>c:PuTTYplink.exe -l fwadmin firewall

C:Usersvadim>c:PuTTYplink.exe -l root firewall

If you can not log in using ssh at this point, verify that ssh daemon is working on the firewall, that existing firewall policy does not block ssh access and ssh daemon configuration in /etc/ssh/sshd_config permits login for root (if you plan to use root account to manage the policy).

Running built-in installer to copy generated firewall policy to the firewall machine and activate it there.

Now that all preparations are complete, we can move on and actually try to install newly generated firewall policy. Select firewall object in the object tree in Firewall Builder GUI, click right mouse button and use menu item “Install”. The program will recompile the policy and open installer dialog.

(This how installer options dialog looks like for iptables, pf, ipfilter and ipfw firewalls).

Here the program already entered user name fwadmin in the “User Name” field, but you can change it for one installation session if you wish. Next you need to enter the password for this user. This is the password of user fwadmin on the firewall machine. Address that will be used to comunicate with the firewall is also entered by the program automatically, it is taken from the firewall settings. You can change it for one installation session as well.

Other installer parameters do the following:

Quiet install: as the name implies, this checkbox suppresses all progress output of the installer
Verbose: this checkbox has the opposite action, it makes the installer print a lot of debugging information, including ssh client debug output.
Store a copy of fwb file on the firewall: if this checkbox is on, the installer will copy not only generated firewall configuration files to the directory on the firewall machine which is configured in the “installer” tab of the firewall object dialog, but also original .fwb data file as well. Use of this option is discouraged if you manage many firewalls from the same .fwb file because distributing file that contains security policy of multiple firewalls to all of them is a bad idea.
Test run: if this checkbox is on, policy installer will copy firewall configuration files to a temporary directory on the firewall and will run them from there. The intent is to test generated configuration without making it permanent. If firewall machine reboots, it will activate previous firewall policy. Installer uses subdirectory “tmp” inside installation directory on the firewall machine which is configured in the “installer” tab of the firewall object dialog. If installation directory configured there is /etc/fw (as in the screenshot earlier in this HOWTO), then installer will put files in the directory /etc/fw/tmp when test install option is in effect. You need to create this directory on the firewall before using this installation mode.
Schedule reboot in… : If this option is on, installer schedules firewall reboot after given time in minutes. This can be used as a measure of last resort to protect against lost of communication with the firewall which may happen if there is an error in the new firewall policy which makes it block ssh access from the management machine. Installer uses command shutdown -r +10min to schedule reboot in 10 min. If installation has been successfull and everything works right, you need to repeat installation with options “test install” and “Schedule reboot” turned off to cancel reboot and install new policy permanently.

After all parameters are set and the password entered, hit “OK” to start installation.

If this is the first time your management machine is logging in to the firewall via ssh, it will find out that ssh host key of the firewall is unknown to it and will present you with a dialog:

Here is says that it does not know host key of the firewall “crash”. This is nothing more than a copy of the warning message presented by the ssh client. You should verify the host key manually and if it matches, click “Yes”. If you click “No” in the dialog, installation process will be interrupted.

Installer only recognizes ssh client warning message about unknown public host keys. If you rebuld your firewall machine, which means its host key changes, ssh will print different warning message which fwbuilder installer does not recognise. In this case you will see this message in the installer progress window, but installation process will get stuck. You need to use ssh client (ssh on Unix or putty.exe on Windows) to update host key before you can use fwbuilder policy installer with this firewall again.

After this, installer copies files to the firewall and runs policy script there. You can monitor its progress in the dialog as shown on the screenshot:

This is an example of successfull installation session. Installer records the status in the left hand side panel of the dialog. If you use installer to update several firewall machines in one session, their names and corresponding status of the installation session for each will be shown in the panel on the left. You can save installer log to a file using “Sabe log to file” button, this can be useful for documentation or troubleshooting.

Running built-in installer to copy generated firewall policy to Cisco router or ASA (PIX)

From the user’s point of view the installer works the same when you manage Cisco router or ASA firewall, with only few minor differences. First of all, the first screen of the installer, where you enter the password, offers another input field for the enable password as well.

You should be able to use IPv6 address to communicate with the router.

Most of the options and parameters in this dialog are the same as those for Linux firewalls (see above). The following parameters work differently for Cisco devices:

Test run: if this checkbox is on, policy installer will copy new access lists configuration to the router or ASA appliance but will not issue write mem command in the end.
Schedule reboot in… : If this option is on, installer issues command reload in NNN after new configuration has been loaded. This schedules reboot in NNN minutes. In combination with “test run” option this can serve as a roll-back mechanism in case of complete loss of contact with the router or firewall because of an error in the policy. Since “test run” does not perform “write mem” in the end, the original access list stays in startup configuration of the router and will be loaded after reboot.
Cancel reboot if policy activation was successful: If this option is on, installer issues command reload cancel in the end of the policy activation process to cancel previously scheduled reboot.

Here is a screenshot of installation session to a Cisco router. Note the output at the very top of the log that shows how installer detected previously unknown RSA host key and accepted it after the user clicked “Yes” in the pop-up dialog (not shown on the screenshot). It then logged into the router; you can see the banner motd output from the router. After this, installer switched to enable mode, set terminal width and turned off terminal pagination using terminal length 0 command and finally switched to the configuration mode. It then started enterig generated configuration line by line.

The final part of the installation session looks like this:

This was a successful installation session, with no errors. Installer finished entering configuration lines and issued exit command to exit configuration mode, then wr mem command to save configuration to memory and finally exit again to log out.

Using Built-in Policy Importer in Firewall Builder

Vadim Kurland — Wed, 10 Jun 2009 15:23:36 +0000

This article demonstrates how you can import existing iptables or Cisco router configuration into Firewall Builder.

There are two ways to activate the feature: Main menu “File/Import Policy” or “Tools/Discovery Druid” and then choose option “Import configuration of a firewall or a router“. Only import of iptables and Cisco IOS access lists is possible in the current version.

Importing existing iptables configuration

iptables config that the program can import is in the format of iptables-save. Script “iptables-save” is part of the standard iptables install and should be present on all Linux distribution. Usually this script is installed in /sbin/ . When you run this script, it dumps current iptables configuration to stdout. It reads iptables rules directly form the kernel rather than from some file, so what it dumps is what is really working right now. To import this into fwbuilder run the script to save configuration to a file

iptables-save > iptables_config.conf

Then launch fwbuilder, activate “Import Policy” function and use “Browse” button in the dialog to find file iptables_config.conf. You also need to choose “iptables” in the drop-down menu “Platform“.

If you do not choose iptables in the “Platform“, the program will try to interpret the file using different parser and will fail. The program does not make any assumptions about the file name or extension and can not predict automatically what platform is the configuration being imported is for.

Importing iptables configuration created in FireStarter

The following example demonstrates import of iptables policy generated by Firestarter, another popular iptables configuration management program.

After the platform is selected and file name entered, click “Next” to start the process.

The program tries to interpret configuration file rule-by-rule and recreates its equivalent in fwbuilder. The progress window displays errors, if any, as well as some diagnostics that shows network and service objects created in the process. Note that user-defined iptables chains found in the configuration file will be re-created in fwbuilder as policy rule sets. The screenshot shows rulesets “LSI”, “LSO”, “OUTBOUND” being created. There were more but they did not fit in the output window. Address objects “h-10.3.14.10″, “h-10.3.14.255″ and few others have been created as well. Service objects “tcp fsra/s”, “udp 0-0:0-0″, “icmp -1/-1″ and few others have also been created.

Note that the new firewall object created in the process has generic name “New Firewall”. This is because iptables configuration file used for import does not have information about firewall machine name. It also does not have information about its interfaces, their names and addresses. The program can infer their names when it encounters “-i ” or “-o ” clause in the iptables configuration lines. It can not reliably detect their addresses though. You need to rename firewall object and add ip addresses to interfaces after the import manually.

Note also that only ipv4 part of the iptables configuration was imported. Currently, import of ipv6 iptables configuration is not supported.

Screenshot above demonstrates rule sets that the program created from the configuration it imported. Rule sets “INBOUND”, “LOG_FILTER”, “LSI”, “LSO”, “OUTBOUND”, “Policy” are all of the type “Policy” and contain filtering rules. There were no NAT rules in the original configuration so the rule set “NAT” is created but is empty. Names of all policy rule sets match names of the iptables chains in the original configuration.

screenshots above demonstrate address and service objects created by the program. It writes a comment in each object to remind that it was created automatically on import. Names of these objects are chosen automatically, you can rename objects to give them more meaningful names. Some of the objects created during import have the same properties as existing service and address objects from the Standard objects library. Currently the program does not cross-match them and just creates new objects, however in the future it may use standard objects instead.

Some rules in the original iptables config used “–tcp-flags” parameter to match only certain combinations of tcp flags. Here is an example:

-A INPUT -s 10.3.14.10 -p tcp -m tcp ! –tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT

In order to be able to reproduce this rule, fwbuilder created special TCP service object with given combination of tcp mask and flags:

The following screenshot demonstrates rules created in the main Policy rule set. These are the top iptables rules, some of them branch off to the other Policy rule sets. Some of the rules in the original policy did not match state (did not have clause “-m state –state NEW” or similar), these rules were created with the flag “stateless” turned on. In fwbuilder, this makes policy compiler generate iptables commands without “-m state –state NEW” clause which matches the original. These rules are marked with an icon that represents non-default rule options in the column “Options”.

Lets inspect one group of rules little closer. The original iptables file contained the following commands:

-A INPUT -i eth0 -j INBOUND

-A INBOUND -p tcp -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INBOUND -p udp -m state –state RELATED,ESTABLISHED -j ACCEPT
-A INBOUND -s 10.3.14.0/255.255.255.0 -j ACCEPT
-A INBOUND -s 10.3.14.0/255.255.255.0 -p tcp -m tcp –dport 22 -j ACCEPT
-A INBOUND -s 10.3.14.0/255.255.255.0 -p udp -m udp –dport 22 -j ACCEPT
-A INBOUND -j LSI

The first rule is in chain INPUT and was recreated as rule #11 in the Policy rule set (rule colored green). Since it was in INPUT, the destination object in the rule #11 is the firewall itself. The “-i eth0″ clause translated into interface object “eth0″ in the “Interface” rule element and direction “Inbound”. The action of the rule #11 is “Branch”, pointing to the rule set “INBOUND”. This is direct recreation of the original rule in itpables config.

This screenshot demonstrates rules created in the rule set “INBOUND”. Rule #0 matches CustomService object “custo-0-tcp” that was created to match combination of protocol “tcp” and state “RELATED,ESTABLISHED”. This object is shown in the following screenshot:

Fwbuilder automatically adds a rule on top of generated iptables script to match packets in states “ESTABLISHED, RELATED”. With that rule, it is not necessary to have a rule like #0 in INBOUND, but since original script had it, fwbuilder reproduced it.

rule #1 in INBOUND matches protocol udp and state “ESTABLISHED,RELATED”. Other rules in INBOUND reproduce original rules from the chain INBOUND and match packets coming from the local net heading for the firewall machine. It is easy to see that the original policy was redundant: rules #2-4 match the same source and destination addresses but different services, but rule #2 matches any service which means rules #3 and 4 will never match any packets. Fwbuilder will detect this problem automatically if you try to compile this policy (this is called “Rule shadowing”).

All packets not matched by any rule in INBOUND will match last rule in this rule set which branches to the rule set LSI. Rule set LSI logs various packets and drops them:

The first thing about rules in this rule set that catches the eye is why do we have all these rules with action “Continue”.

When a rule is marked as “logging” in fwbuilder, it gets an icon in the column “Options” that represents log, this icon appears either by itself or next to the icon that represents non-default rule options. However, iptables does not allow for an action “Accept” or “Deny” to be used in combination with logging, in iptables logging is separate target just like “ACCEPT” or “DROP”. Because of that, fwbuilder splits a rule that has action “Accept” or “Deny” or any other with logging turned on. One such rule becomes two or more iptables rules in the generated script. Unfortunately when iptables script is imported back, the program can not merge such rules and logging rules appear in the rule set as separate rules with logging icon in the “Options” column and action “Continue”. This is a valid configuration in fwbuilder, it just means that the rule generates log record but does not make any decision whether the packet should be accepted or denied and the firewall should continue its inspection.

Here is the fragment of the original iptables rules in the chain LSI:

-A LSI -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN
-m limit –limit 1/sec -j LOG –log-prefix “Inbound ” –log-level 6
-A LSI -p tcp -m tcp –tcp-flags FIN,SYN,RST,ACK SYN -j DROP

These rules become rules #1 and 2 in rule set LSI in fwbuilder. The first rule, the one that does logging, becomes a separate rule because this is how it is done in iptables. If this policy was created in fwbuilder, rules #1 and 2 would be just one rule in the GUI. Double-clicking in the column “Options” in rule #1 opens dialog where you can inspect and edit its options. Tab “Limit” of this dialog controls parameters iptables “limit” module which was used in the original rule. Screenshot below demonstrates how policy importer recognized these parameters and reproduced them in the rule options:

Limitations

iptables policy importer in fwbuilder has its limitations. Main limitation is that it can only parse certain set of iptables modules and targets. There are too many modules and associated targets out there and supporting all of them is next to impossible. However, it supports the core functionality and most popular modules. Even though importer tries to be as close to the original configuration as possible, you should always review rules and objects it creates and edit resultant rules. Most of the time rules can be simplified, such as with logging rules as was explained above. Often you can merge multiple rules by putting several objects in source or destination or service. Using object and service groups is another good way to simplify rules.

Importing Cisco IOS access lists configuration

Importing IOS access lists configuration is more straightforward because branching is not possible there. To import configuration, first you need to save it using “show run” command. IOS has literary hundreds of different commands and configuration clauses, but fwbuilder can only parse those related to the access lists configuration. Other commands will be ignored. There is no need to edit configuration prior to importing it into fwbuilder (except for the “banner” command, see below). Saved IOS configuration has information about router name and its interfaces, this information will be used to recreate objects in fwbuilder. Parser will not only create interface objects with proper names, it will also attach address objects to them to describe their ip addresses.

Just like with iptables, we start with main menu “File/Import Policy” and enter file name in the dialog. The “Platform” drop-down list should be set to “Cisco IOS“. Click “Next” to start import process.

The program recognized router name “c3620″ and its interfaces, created interface objects with their ip addresses and then created some address and service objects. My test router config contains the following lines (this is just a fragment, there are more interfaces and more ACLs):

interface FastEthernet0/0
ip address 192.168.100.100 255.255.255.0 secondary
ip address 10.3.14.201 255.255.255.0
ip access-group fe0_0_acl_in in
ip access-group fe0_0_acl_out out
no ip mroute-cache
duplex auto
speed auto
!
interface Ethernet1/0
description Test [test] {test} (and one more test) /weird:characters#$%^&*/
ip address 192.168.171.2 255.255.255.0
ip access-group e1_0_acl_in in
ip access-group e1_0_acl_out out
no ip mroute-cache
ip ospf cost 65000
half-duplex
crypto map real

!###################################################
ip access-list extended e1_0_acl_in
deny ip any any fragments
permit tcp host 10.3.14.40 host 192.168.171.2 eq 22 log
permit tcp host 10.3.14.40 host 10.3.14.201 eq 22 log
permit ip any 10.3.14.0 0.0.0.255 log
deny ip any any log
!###################################################
ip access-list extended e1_0_acl_out
permit ip 10.3.14.0 0.0.0.255 any log
deny ip any any log

Parser recognizes comments and skips them, but text from interface descriptions goes into comments in the Interface objects.

Firewall Builder recognizes both named and regular extended access lists. Each separate access list is recreated in fwbuilder in the same main Policy rule set. The program recognizes “ip access-group” commands and puts corresponding interface object in the “Interface” rule element of the rules it creates.

The original configuration used the same access list “133″ with two interfaces:

interface Ethernet1/1
ip address 10.10.10.10 255.255.255.0
no ip mroute-cache
!
! Note – the same access list applied both in and out
ip access-group 133 in
ip access-group 133 out
no shutdown
half-duplex
!
interface Ethernet1/2
ip address 10.10.20.20 255.255.255.0
no ip mroute-cache
!
! Note – the same access list applied both in and out
! the same list is applied to eth 1/1 and eth 1/2
ip access-group 133 in
ip access-group 133 out
no shutdown
half-duplex
!

The program recognizes this and creates object group “intf-acl_133″ with these two interfaces as members:

It then uses this group in the “Interface” element of rules #0, 1 and 2 to reproduce rules from the access list “133″.

Interface configuration commands visible in the config snippets above, such as “half-duplex”, “duplex auto”, “speed auto”, various protocol configuration commands and other commands supported by IOS inside “interface” block are ignored.

Limitations

One IOS configuration construct that fwbuilder can not import is “banner” command. This command is special in that it allows the user to set arbitrary terminator character and then it allows any text up to this character. This creates a problem for fwbuilder parser because the terminator character can be arbitrary. You need to edit and remove banner from the saved configuration file before importing it.

Getting Started with Firewall Builder

Vadim Kurland — Mon, 09 Mar 2009 16:36:20 +0000

This guide presents an introduction to Firewall Builder. Firewall Builder (also known as fwbuilder), is a GUI firewall configuration and management tool that supports iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) and Cisco routers extended access lists. Both professional network administrators and hobbyists managing firewalls with policies more complex that is allowed by simple web based UI can simplify management tasks with the application. The program runs on Linux, FreeBSD, OpenBSD, Windows and Mac OS X and can manage both local and remote firewalls.

Firewall Builder is packaged with most Linux distributions and is available under “System/Administration” menu.

Accessing Firewall Builder

If it is not there, then it probably needs to be installed on your system. You need to install the package that has supporting the API library libfwbuilder and the package for fwbuilder that contains the Firewall Builder GUI and policy compilers. Use apt-get or aptitude to find and install them:

# aptitude install libfwbuilder fwbuilder

On FreeBSD and OpenBSD Firewall Builder is part of ports, you can find it in /usr/ports/security/fwbuilder.

Packages shipping with Ubuntu are always one or two minor revisions behind. If you want to try the latest version, you can use the pre-built binary .deb packages offered on the project’s web site or build from source using our online installation instructions. Pre-built binary packages and source code tar.gz archives can be downloaded from this page.

If the system menu item is not there or you have built the program from source, you can always launch it from the command line by just typing “fwbuilder” on the shell prompt:

$ fwbuilder

The program starts and opens the main window and greeting dialog. The dialog provides links to the project web site where you can find more tutorials, FAQ, Firewall Builder CookBoook and other documentation, as well as a bug tracking system and links to user forums and the mailing list. Clicking on the link in the dialog opens corresponding web page in your web browser. This works the same on all supported OS: Linux, Windows and Mac OS X. You can always open this dialog later using an item in the main menu “Help”.

Firewall Builder startup greeting

Lets create our first firewall object. To do this, we’ll use the object creation menu that appears when you click on the icon in the small toolbar right above the object tree. Choose menu item “New Firewall” from the menu that appears.

Setup new firewall

The program presents a wizard-like dialog that will guide you through the process for creation of the new firewall object. In the first page of the wizard you can enter the name for the new firewall object (here it is “guardian”), its platform (“iptables”) and host OS (“Linux”).

There are two ways a new firewall can be created: you can use one of the preconfigured template firewall objects or create it from scratch. This tutorial demonstrates the first method (using template object). To do this, check checkbox “Use preconfigured template firewall objects”. The template can be taken from the library of template objects that comes with the Firewall Builder package or from a file provided by the user. The latter is useful when the administrator wants to distribute a library of predefined templates to other users in the enterprise. We are using one of the standard templates in this guide and therefore leave the standard template library path and name in the “Template file:” input field. Click “Next” to move on to the next page of the wizard.

Note that the template firewall object comes completely configured, including addresses and netmasks of its interfaces and some basic policy and NAT rules. This configuration is intended as a starting point only. You should reconfigure the addresses of interfaces to match those used on your network; and most likely will have to adjust rules to match your security policy.

Configure firewall template

This page of the wizard shows template objects and their configuration. Standard template objects represent firewalls with two or three interfaces, a host with one interface, web server or Cisco router. Choose firewall with three interfaces for this guide. Note that template comes with completely configured firewall objects, including a set of interfaces and their IP addresses – And some basic firewall policy. You will see how addresses can be changed later on in this guide. Click “Finish” to create a new firewall object using the chosen template.

Firewall objects

Here is our new firewall object. Its name is guardian, it appears in the object tree in the left hand side of the main window in the folder Firewalls. When an object is selected in the tree, a brief summary of its properties appears in the panel under the tree. Double-clicking on the object in the tree opens it in the editor panel at the bottom of the right hand side panel of the main window. The editor for the firewall object allows the user to change its name, platform and host OS and also provides buttons that open dialogs for “advanced” settings for the firewall platform and host OS. We will inspect these a little later in this tutorial.

You can always resize the main window to make all columns of the policy view more visible.

Guardian/Policy view

Now would be a good time to save the data to a disk file. This is done in a usual way using main menu File/Save As.

Lets take a little tour of the network and service objects that come standard with the program. You can use these preconfigured objects to build policy and NAT rules for your firewall.

Objects in the tree are orginized in libraries, you can switch between libraries using the interfaces’ drop-down menu above the tree. Firewall Builder comes with a collection of address, network, service and time interval objects in the library called “Standard”. Lets take a look at them. Notice that the background color of the panel that shows objects tree depends on the chosen object library. This makes it easier to keep track of the library currently opened in the program.

The libraries

Folder Objects/Hosts contains few host objects used in standard firewall templates. Folder Objects/Network contains network objects that represent various standard address ranges and blocks, such as multicast, net 127/8, networks defined in RFC1918 and so on.

Network objects

Firewall Builder also comes with extensive collection of TCP, UDP and ICMP service objects that describe commonly used protocols. This image shows some TCP objects (all of them do not fit in the screenshot).

TCP (protocol) objects

Here is an example of a simple TCP service. It defines source and destination port ranges (in this case source port range is not defined and there is only one destination port 80). TCP service object can also define any combination of TCP flags the firewall should inspect and also which ones of them should be set in order for a packet to match this object. In the case of the service “http” we do not need to define any flags.

TCP service

Now lets take a look at the objects created as part of the new firewall object guardian. In order to do this, switch to the library User where this object was created. To open an object in the editor panel to inspect or change it, double click on it in the tree. Also, if you click on an object in the policy rule to select it, it will automatically open in the tree on the left.

Object Guardian in user library

First, the firewall object itself.

Every object in fwbuilder has basic attributes such as its name and comment. Other attributes depend on the object type.

Attributes of the firewall object include platform (can be iptables, pf, ipfilter, etc.), version (platform-depended) and host OS. Buttons Host OS Settings and Firewall Settings open dialogs with many additional attributes that depend on the firewall platform and host OS. More on these later.

Object attributes

Here are the choices for the firewall platform, version (for iptables) and host OS.

Platform choices for the firewall

Interfaces of the firewall are represented by objects located below the Firewall object in the tree. We refer to them as “children” of the firewall object. This image demonstrates properties of the interface eth0. To open it in the editor double click on it in the tree. If editor panel is already open and shows some object, it is sufficient to select new object in the tree to reveal it in the editor panel (no need to double click).

IP and MAC addresses of interfaces are represented by child objects in the tree located below corresponding interface.

Firewall interfaces

Interface object has several attributes that define its function, such as “Management interface”, “external” etc.

Name: the name of the interface object in Firewall Builder must match exactly the name of the interface of the firewall machine it represents. This will be something like “eth0″, “eth1″, “en0″, “br0″ and so on.
Label: On most OS this ﬁeld is not used and serves the purpose of a descriptive label. Firewall Builder GUI uses a label, if it is not blank, to show interfaces in the tree. One of the suggested uses for this ﬁeld is to mark interfaces to reﬂect the network topology (’outside’, ’inside’) or the purpose (’web frontend’ or ’backup subnet’). The label is mandatory for Cisco PIX though, where it must reﬂect the network topology.
“Management interface”: Sometimes the host has several network interfaces in which case one of them can be marked as the ’manaagement interface’. The management interface is used for all communication between Firewall Builder and the host.
“External interface (insecure)”: marks an interface that connects to the Internet.
“Unprotected interface”: marks interface to which fwbuilder should not assign any access lists (used only with Cisco IOS platform)
“Regular Interface”: Use this option if the interface has an IP address assigned to it manually.
“Address is assigned dynamically”: Use this option if the interface has a dynamic address (obtained by means of DHCP or PPP or another protocol); in this case an address is unknown at the moment when Firewall Builder generates the ﬁrewall policy.
“Unnumbered interface”: Use this option if the interface can never have an IP address, such as the ethernet interface used to run PPPoE communication on some ADSL connections, tunnel endpoint interface, or an interface on a bridging ﬁrewall. See below Section 5.3.1 for more detailed discussion of these different types of interfaces.
“Bridge port”: this option is used for port of bridged firewall.
“Security level”: security level of this interface, used only with Cisco PIX (ASA)
“Network zone”: network zone of this interface, used only with Cisco PIX (ASA). Network zone drop-down list shows all network obejcts and groups of addresses and networks present in the tree. Choose one of them to tell the compiler which networks and blocks of addresses can be reached through this interface. Compiler uses this information to decide which interface each ACL rule should be associated with based on the addresses used in the destination of the rule.

View interface

Here is IP address of interface eth0, external interface of the firewall. The address and netmask are attributes of the child object of the type “IPv4 address”. Here the address is “192.0.2.1″ and netmask “255.255.255.0″. Button “DNS Lookup” can be used to determine IP address using DNS. The program runs DNS query for the “A” record for the name of the parent firewall object.

IP address of interface eth0

Lets look at the IP address of the internal interface of the firewall. The address used in the template is “192.168.1.1″ with netmask “255.255.255.0″. This is rather typical address used for small and home networks. Some commercial firewall appliances come preconfigured with this address.

IP addresses of internal interfaces

If address 192.168.1.0/24 matches address of your local network, you can skip this part of the guide and move to the page 4. Otherwise, you need to reconfigure the address of the internal interface of the firewall object that you just created in fwbuilder and also change address object used in the policy rules. Start with changing address attribute (and possibly netmask, if necessary) of the object guardian:eth1:ip as shown in the screenshot:

Change IP address

Now we need to change IP address used in the rules. To do this, we create new Network object with correct address and replace object net-192.168.1.0 in all rules with this new network object.

Use new object menu to create Network object.

Create new network object

New Network object is created with default name ‘New Network’ and IP address 0.0.0.0.

Default network created

Edit object name and address, then hit “Apply”.

Editing network object

Use menu Object / Find to activate search and replace dialog. The Find and Replace dialog opens at the bottom of the right hand side panel in the main window, below the policy rules view.

Searching for objects

Locate object object net-192.168.1.0 in any policy rule where it is used or in its location in the tree in library Standard and drag and drop it to the left object well in the search and replace dialog as shown on the screenshot:

Drag and drop object

Change the scope setting to “Policy of all firewalls”. If you have many firewalls in the tree, use scope “policy of the opened firewall” instead. Locate new Network object you just created in the tree and drag and drop it to the right object well in the search and replace dialog as shown on the screenshot:

Changing scope of all policies

Now hit “Replace all” button. Pop-up dialog should appear and report how many replacements the program had to make in all rules of the firewall. Note that the replacement is done not only in the policy rules, but in NAT rules as well.

Replace all button results

Now that you have created a new object and replaced old network object with new one in all rules, do not forget to save data to a file using menu File/Save

Lets inspect properties of the firewall object. Double click on the firewall “guardian” in the tree to open it in the editor panel, then click “Firewall Settings” button in the editor. This opens new dialog that looks like this. Notice button “Help” in this dialog, clicking this button opens help as shown on the image below.

IP tables advanced settings

Online help explains all attributes and paramaters located in each tab of the firewall settings dialog. I enourage you to explore it as many parameters are important and affect generated iptables script in different ways.

Next few screenshots show other tabs of the firewall settings dialog. You can find detailed explanations of all parameters in the online help.

Detailed explanation screen

This page defines various parameters for the built-in policy installer. Installer uses ssh client (pscp.exe and plink.exe on Windows) to transfer generated script to the firewall machine and activate it there.

Policy installer, script generator

User can define shell commands that will be included in the generated script at the beginning and in the end of it. These commands can do anything you want, such as configure some subsystems, set up routing etc.

Include shell command in script generator

Parameters for logging.

Logging parameter settings

More options for the script generation. Notice that fwbuilder can produce iptables script in two formats: 1) as a shell script that calls iptables utility to add each rule one by one, or 2) it can use iptables-restore script to activate the whole policy at once. Other parameters are explained in the online help.

Further script generation options

Starting with v3.0 Firewall Builder can generate both IPv4 and IPv6 policy. This tab controls the order in which they are added to the script if user defined rules for both address families in the Policy objects of the firewall.

IPv4 and IPv6 support

Lets take a look at the policy of the template firewall. These rules are intended to be an example, a starting point to help you create your own policy quicker. Most likely you will want to modify them to suite your requirements. Explanation of the rules given here is rather brief because the goal of this guide was only to demonstrate how to use Firewall Builder.

Rule 0: this is an anti-spoofing rule. It block incoming packets with source address that matches addresses of the firewall or internal or DMZ networks. The rule is associated with outside interface and has direction set to “Inbound”.
Rule 1: this rule permits any packets on loopback interface. This is necessary because many services on the firewall machine communicate back to the same machine via loopback.
Rule 2: permit ssh access from internal network to the firewall machine. Notice service object “ssh” in the column “Service”. This object can be found in the Standard objects library, folder Services/TCP.

Policy rules template

Policy rules belong to the object “Policy”, which is a child object of the firewall and can be found in the tree right below it. As any other object in Firewall Builder, Policy object has some attributes that you can edit if you double click on it in the tree.

Policy can be either IPv4, or IPv4 or combined IPv4 and IPv6. In the latter case you can use a mix of IPv4 and IPv6 addess objects in the same policy (in different rules) and Firewall Builder will automatically figure out which one is which and will sort them out.
Policy can translate to only mangle table, or a combination of filter and mangle tables. Again, in the latter case policy compiler decides which table to use based on the rule action and service object. Some actions, such as “Tag” (translates into iptables target MARK) go into mangle table.
“Top ruleset” means that compiler will place generated iptables rules into built-in chains INPUT/OUTPUT/FORWARD. If policy is not marked as “top ruleset”, generated rules will go into user-defined chain with the name the same as the name of the policy object.

Policy rules set

Here are preconfigured NAT rules.

Rule 0: tells the firewall that no address translation should be done for packets coming from network 192.168.2.0 going to 192.168.1.0 (because Translated Source, Translated Destination and Translated Service are left empty)
Rule 1: packets coming to the firewall from internal and DMZ networks should be translated so that source address will change and become that of the outside interface of the firewall.
Rule 2: packets coming from the Internet to the interface “outside” will be translated and forwarded to the internal server on DMZ represented by the host object “server on dmz”.

Preconfigured NAT rules

Now we should be ready to compile policy of the firewall guardian and generate iptables script. To do this, select firewall in the tree and click right mouse button. Choose item “Compile” in the pop-up menu. The dialog that appears lists all firewall objects defined in the objects tree and lets you select which ones should be compiled. The firewall guardian has just been created and has never been compiled and dialog shows that. Make sure checkbox next to the firewall object guardian is checked and click button “Next”.

Select firewalls for compilation

Firewall Builder calls policy compiler (which is by the way an external program which can be used on the command line). The next page of the dialog shows compiler progress and result.

Compiler progress

Compiler generates iptables script in the file with the name the same as the name of the firewall object, with extension “.fw”. The file is placed in the same directory where the data file .fwb is located.

$ ls -la test2.fwb guardian.fw -rwxr-xr-x 1 vadim vadim 11253 2009-02-16 16:41 guardian.fw -rw-r--r-- 1 vadim vadim 24696 2009-02-16 16:41 test2.fwb

Here is how generated script looks like. This is just a fragment from the middle to show some generated iptables commands.

# ================ IPv4

# ================ Table ‘filter’, automatic rules
$IPTABLES -P OUTPUT DROP
$IPTABLES -P INPUT DROP
$IPTABLES -P FORWARD DROP

cat /proc/net/ip_tables_names | while read table; do
$IPTABLES -t $table -L -n | while read c chain rest; do
if test “X$c” = “XChain” ; then
$IPTABLES -t $table -F $chain
fi
done
$IPTABLES -t $table -X
done

$IPTABLES -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

# ================ Table ‘nat’, rule set NAT
# NAT compiler errors and warnings:
#
#
# Rule 0 (NAT)
#
echo “Rule 0 (NAT)”
#
# no need to translate
# between DMZ and
# internal net
$IPTABLES -t nat -A POSTROUTING -s 192.168.2.0/24 -d 172.16.22.0/24 -j ACCEPT
$IPTABLES -t nat -A PREROUTING -s 192.168.2.0/24 -d 172.16.22.0/24 -j ACCEPT
#

Now you can transfer it to the firewall and execute it there to install iptables rules. However it is much more convenient to use built-in policy installer to do this. To use installer, click right mouse button on the firewall object in the tree and use menu item Install. Firewall Builder will compile the policy if necessary and then open dialog where you can configure parameters of the installer. Here you need to enter password to authenticate to the firewall. Once you click OK, installer will connect to the firewall using ssh client. First, it will copy generated script to the directory /etc on the firewall (or different one, if configured in the Installer tab of firewall settings dialog), then it will run this script and check for errors. Its progress will be visible in the panel of the installer wizard, just like the progress of policy compiler.

Install options for firewall 'guardian'

This guide walked you step by step through the process of creating of a firewall object, making some minor changes in its parameters and policy rules, compiling the policy and activating it on the firewall machine. This guide did not touch advanced topics such as built-in revision control system, working with multiple data files, working with multiple firewall objects, IPv6. You can find documentation and guides on these topics and more on our project web site at http://www.fwbuilder.org.