Firewall Builder Frequently Asked Questions

Firewall Builder Frequently Asked Questions

Table of Contents

1. System requirements, using pre-built packages, compiling from source

2. Problems, troubleshooting and reporting bugs

3. Building firewall policy

4. Installing policy on a firewall

5. Logging

1. System requirements, using pre-built packages, compiling from source

1.1. What are the system requirements for Firewall Builder ?

These are listed in the file "Requirements" in the docs directory. It is

/usr/share/doc/fwbuilder/Requirements.

1.2. Where do I get GTK-- packages for RedHat 7.0 and 7.1 ?

See gtk-- home page at https://gtkmm.sourceforge.net/ and follow link "Download" or directly in https://www.hvrlab.org/pub/gtkmm/

1.3. I want to use pre-built binary package. What do I need to download and install?

We distribute pre-built binary packages for some Linux distributions. You would need to download and install the following (actual names of the packages vary depending on the naming convention for given distribution):

The API: libfwbuilder

GUI: fwbuilder

Policy compiler for iptables: fwbuilder-iptables

As policy compilers for other firewall platforms become available, they will appear in the download area.

You may also want to check what is available under "Contrib" in the download area. There are useful install, boot-time startup and other scripts contributed by users and beta-testers. Pre-built binary packages for Debian, Mandrake, SuSe are also available in "Contrib" area.

1.4. I am trying to compile Firewall Builder v0.9.6 from source, but configure complains "libfwbuilder not installed"

As of version 0.9.6 the code has been split into three major parts: API, GUI and policy compilers. You need to download, compile and install API for the rest to compile. The API comes in a sep 21221r1719v arate source archive called libfwbuilder-0.10.0.tar.gz. Compile and install it as usual, using "./configure; make; make install" procedure.

1.5 What firewall platforms are supported ?

As of version 0.9.3 we support iptables and are working on ipfilter policy compiler. We dropped support for ipchains as obsolete technology and because lack of time

2. Problems, troubleshooting and reporting bugs

2.1. fwbuilder or one of policy compilers crashes. What do I do ?

Please file a bug on Sourceforge. Provide information we might need to fix the problem (in the form of the output of the following commands):

cat /etc/issue

rpm -qa | grep gnome

rpm -qa | grep gtk

rpm -qa | grep libxml

rpm -qa | grep libsigc++

ls -la /usr/share/fwbuilder

ls -la /usr/share/pixmaps/fwbuilder

ldd /usr/bin/fwbuilder

ldd /usr/bin/fwb_ipfilter

ldd /usr/bin/fwb_iptables

Also send us core file and .xml file with your objects. If program crashes but does not generate core file (it shows "crash" dialog instead), run it as follows:

fwbuilder --disable-crash-dialog

It will dump core then.

2.2. I get "I/O Error" while compiling policy. There is no other indication of error though.

Did you install package with corresponding compiler ? We ship compilers in a separate RPMs named like this:

fwbuilder-ipchains-0.8.7-2-rh7.i386.rpm

Check if compiler dumped core. If you can't find it, you may try to run compiler manually, providing the following command line parameters:

$ fwb_ipchains -f path_to_objects.xml_file firewall_object_name

All policy compilers have the same command line format.

2.3. fwbuilder crashes on my Debian or Mandrake or SuSe system. What do I do ?

We can not guarantee that Firewall Builder would work flawlessly on Debian or Mandrake or SuSe since we do not have access to these distributions for testing.

Sometimes we recieve packages built for these distributions by volunteers. In this case we post these packages in "Contribs" area on the project's page on Sourceforge. We do not verify or even try these packages and completely rely on people who submit them. We usually post information about authors, so if you have questions you can contact them directly.

We welcome help from anyone who can test Firewall Builder on these distributions and provide feedback

3. Building firewall policy

3.1. Druid seems to multiply rules in the policy

This is how it works now. Interactive Druid does not check for rules in existing policy and simply adds new ones. If you run Druid twice and ask it to generate the same set of rules, you'll get the same rules many times in your policy. This will be improved in subsequent releases.

3.2. I use iptables (or other) to protect local host. How do I use Firewall Builder to build policy?

Your host may or may not have its IP address assigned via PPPoE or DHCP.

Here is what you do if address is static:

create firewall object, enter its IP address

create interface for it in "Interfaces" tab, mark it as "external"

add loopback interface named "lo", address 127.0.0.1/255.0.0.0

call Druid, chose "Firewall protects local host" and then pick rules you want.

See what Druid have created for you. You can edit and add rules now.

If address is dynamic:

create firewall object, mark its address as "dynamic"

create interface for it in "Interfaces" tab, mark it as "external" and "dynamic"

add loopback interface named "lo", address 127.0.0.1/255.0.0.0

call Druid, chose "Firewall protects local host" and then pick rules you want.

3.3. How can I configure NAT to provide access from the Internet to my server behind the firewall ?

( The following recomendations assume you are using iptables )

There are two possibilities here, depending on what IP address you want to use to access your server - that of your firewall or separate one. If you use the same address your firewall has, you can arrange access to your internal server from outside, and provide your internal users with access to the Internet using only one address. This scheme may become a limitation though if you have multiple servers inside your network which need to be accessed from outside. In the latter case you may want to use different port numbers or different addresses for access to different internal servers.

You want to use IP address of the firewall to access your server inside.

This is easy. Just add rule to the "NAT":

where "firewall" is the object for your firewall and "Server" is the object for your server behind the firewall.

this is it, Firewall Builder will generate iptables code for DNAT translation using firewall's IP address.

You want to use separate IP address for translation

Create a rule in "NAT" in a similar way:

where "Server-NAT" is special object with address of the translation you want to create, and "Server" is an object for your server behind the firewall.

In addition to the firewall rule, you need to set up static ARP entry and add routing. Asuming external translated address of the server is NN.NN.NN.NN, external firewall's interface is eth1 and its internal interface is eth0, the following commands would do the trick:

# arp -Ds NN.NN.NN.NN eth1 pub

# route add NN.NN.NN.NN dev eth0

The first command adds static "published" ARP entry, while the second command routes it through internal interface

As of version 0.9.3 iptables compiler can add these two commands to the generated firewall script if checkbox "Create ARP entries for DNAT translations" is checked in "iptables" tab in firewall object's dialog

3.4. I see the firewall objects has multiple policies associated with it. How do these policies relate to each other and in what order does policy compiler scan them to generate firewall code?

Global Policy rules apply to packets crossing the firewall, regardless of the interface they ingress and egress through. In case of iptables this is equivalent to the FORWARD chain, although there may be no such direct correspondence in other firewall platforms. Even when such correspondence does exist, high level Firewall Bulder policy rule may need to be converted into multiple rules going into different groups or chains in the target platform code beause of number of reasons. To explain this, let's consider a situation when Firewall Builder has to generate code for iptables firewall and the rule has "Any" as source. Obviously, if source is "any", then it should cover any object, including the firewall itself. Therefore policy compiler which generates code for iptables places rule into both FORWARD and OUTPUT chains. However, both final iptables rules won't have interface specified in them since original fwbuilder rule was part of the Global Policy which is not associated with any interface.

Interface Policy rules are associated with certain network interface of the firewall. Unlike Global Policy rules, direction can be specified for Interface Policy rules. This provides a mechanism for dealing with situations where knowing both interface and direction is neccessary, for example setting up anti-spoofing rules. Since situations like this are rare, we recommend placing most of the firewall rules in the Global Policy and only those rules which can not be implemented in any other way into Interface Policy.

At the same time there are target platforms which require that all rules are always associated with interfaces. In this case using Global Policy rules may not be practical because writing policy compiler capable of guessing correct interface may be too complex. One example of such platform is Cisco routers, where access lists (ACL) are always associated with interfaces.

When policy compiler generates code for the target platform, it first scans NAT rules, then Interface Policies, then Global Policy. This determines the order in which lines of the target code are generated.

4. Installing policy on the firewall

4.1. The XML file I save, is it transformed into iptables script and sent to the firewall automatically when I click on "Compile"? Or do I have to restart something to see the changes applied?

"Compile" only calls compiler, which produces a file called after the name of the firewall object, with ".fw" extension. This file contains iptables sript which needs to be activated. There are two ways to activate it: 1) you can simply run it by hand. 2) you can use custom shell script to copy this file to where it should be and then run it. If you put this script in the "Policy Install Script" field in "Compile/Install" tab of the firewall's object dialog, then menu item "Rules/Install" will be activated. We have examples of the install script in the "Contrib" area on Sourceforge. We do not ship this script with the product because the installation and activation procedure is too different on different installations. We might standardise on one or another version in the future, but for now it is add-on feature and we rely on contributors to send us examples of their install scripts. You do not need to reboot your firewall to activate the new policy. Iptables script generated by Firewall Builder has a code to do a "clean up" job by removing all previous iptables settings, before it loads new ones.

4.2. I have ipchains installed on my RedHat 7.1 system. How do I switch to iptables and start using firewall script generated by Firewall Builder?

You do not need to uninstall ipchains, but you need to deactivate it.

As root, run the following command:

# chkconfig --level 2345 ipchains off

if you do not want to reboot at this point, run the following to stop and remove ipchains from the memory:

# /etc/rc.d/init.d/ipchains stop

# rmmod ipchains

Now simply run iptables script created by fwbuilder to activate your firewall.

RedHat's standard iptables setup depends on their scripts iptables-save and iptables-restore. If you wish to stick with RedHat's standard scripts, simply run these commands:

# /etc/rc.d/init.d/iptables save

# chkconfig --level 2345 iptables on

This will save your configuration to RedHat's standard file /etc/sysconfig/iptables in iptables-save format (which is different!) and then will restart it every time you reboot your firewall.

If you do not want to use their scripts, you can use script "firewall-install" available in our Contrib area on SourceForge. This script comes with a README file which describes its usage.

5. Logging

5.1. I do not see log records in /var/log/messages, what's wrong?

RedHat Linux comes with syslog preconfigured to write all log messages with level "info" and higher to /var/log/messages, while iptables script generated by Firewall Builder by default logs everything as "debug". You need either to edit /etc/syslog.conf to make all "debug" messages to be logged, or change log level to "info" in iptables tab in firewall dialog

5.2. I've got logging working, but I think it sends too much information to the log so I can not really find what I am interested in. Is there a way to make it more readable?

You can use our script logwatcher.pl available in Contrib area. It reads log file /var/log/messages and shows only the following fields from each log line:

Date and time

rule number (assuming you use default setting for the rule prefix which looks like this: "RULE %N -- %A")

rule action (Deny/Reject/Accept)

interface

protocol

source address and source port

destination address and destination port

ICMP type and code for ICMP packets

Note though that this script drops some data logged by iptables to improve readability. You may miss some important information because of this, so in case of real problem always look in the original log!