Firewall Builder

We support iptables (available in Linux kernels 2.4.x). As of version 0.9.3 we dropped support for ipchains as obsolete technology and because of lack of time. As of version 1.0.1 we support ipfilter (available for variety of OS, including FreeBSD, OpenBSD, Solaris and others) and added support for pf (OpenBSD 3.0)

Our main development OS is Linux, however we test-compile our code on Solaris and FreeBSD. Unfortunately we do not have resources to build binary packages for Solaris and FreeBSD regularly; we are currently looking for supporter for "port" for FreeBSD and OpenBSD.

We are trying to port the GUI and policy compilers to MS Windows. It will work on Windows 2000 and Windows XP. Windows 95 and Windows 98 are not going to be supported.

These are listed in the file "Requirements" in the docs directory. It is doc/fwbuilder/Requirements if you unpack source tarball, or can be found online: http://www.fwbuilder.org/pages/Documents/Requirements.html

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

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 and SuSe are also available in "Contrib" area.

As of version 0.9.7 Firewall Builder does not need GNOME anymore. All widgets which are part of libgnomeui library have been rewritten so Firewall Builder now uses only gtk+ and gtk-- libraries. This should simplify porting to other OS and should make it possibly to use Firewall Builder on Linux systems using KDE.

first of all, you need to obtain source. One way is to download source tarball from our download page. You need to grab two packages: libfwbuilder-N.N.N.tar.gz and fwbuilder-M.M.M.tar.gz , where N.N.N and M.M.M are respective versions of both packages/

Or, if you want to try the code we are currently working on, you can do anonymous CVS checkout from our site on Sourceforge. Just open this URL: http://sourceforge.net/cvs/?group_id=5314 and follow instructions. In this case make sure you get both libfwbuilder and fwbuilder modules.

In either case, once you got source and unpacked it on your machine, you need to check that all dependencies are satisfied and you have all the libraries fwbuilde ruses installed on your machine. You can check list of libraries here: http://www.fwbuilder.org/pages/Documents/Requirements.html

Now you can build. First go to the directory libfwbuilder and run script ./autogen.sh. This script checks dependencies and customises our code for your system. This script accepts the following parameters:

• --prefix - specify directory prefix where you want libfwbuilder installed

• --with-templatedir=DIR - specify directory for template files and DTD

• --with-glib-prefix=PREFIX - specify prefix directory where glib is installed

• --disable-glibtest - do not compile and run glib test program

• --without-openssl - compile libfwbuilder without encryption support (certain functions won't work, such as support for fwbd daemon)

• --with-openssl-prefix=PREFIX - specify prefix directory where openssl library is installed

• --without-ucd-snmp - compile libfwbuilder without support for SNMP (certain functions won't work, such as network discovery)

If system you are using for build has additional libraries installed in /usr/local/lib, then you either need to add this directory to your LD_LIBRARY_PATH environment variable, or supply path for each lbrary as a parameter for autogen.sh. Unfortunately at this time our script does not support specification of the installation path for all the libraries we use, so setting LD_LIBRARY_PATH is probably safier way.

If your system has all the libraries installed in the standard place, or has dynamic linker configured so that it can find libraries wherever they are installed, then you do not need to worry about LD_LIBRARY_PATH.

Once you are done with autogen.sh, run "make all" in libfwbuilder directory and see that it does not end with an error. If it does, then either autogen.sh could not find some library, or there is something peculiar about your system that we do not support yet. Please verify again that you have all the libraries needed (check with Requirements) and that autogen.sh worked fine. If nothing helps, report the problem to us.

After "make all" have worked to the end and did not produce any errors, you need to install the library. By default it installs in /usr/local/lib and libfwbuilder-config script installs in /usr/local/bin. You will need root priviliges to install there, so become root and run "make install" in the directory libfwbuilder. If you do not wish to install in /usr/local, you can use parameter --prefix=PREFIX when you run autogen.sh

Once libfwbuilder is installed, you can move on and compile fwbuilder. The procedure is the same: go to the directory fwbuilder, run "./autogen.sh", then "make all" and "make install".

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 separate source archive called libfwbuilder-0.10.0.tar.gz. Compile and install it as usual, using "./autogen.sh; make; make install" procedure.

Just type "fwbuilder" on the command line prompt (in xterm or gnome-terminal)

If you get this error:

	      fwbuilder: error while loading shared
	      libriaries: libfwbuilder.so.0: cannot load shared object
	      file: no such file or directory.
	    

Then the GUI binary (fwbuilder) can not find API library libfwbuilder. If you are using our pre-built binary packages, then make sure you download and install package called libfwbuilder. If you compiled from sources, then perhaps you installed libfwbuilder with default prefix /usr/local/, therefore library went to /usr/local/lib. Dynamic linker ldd can not find it there.

You have the following options:

• create environment variable LD_LIBRARY_PATH with value /usr/local/lib and run fwbuilder from this environment.

• add /usr/local/lib to the file /etc/ld.so.conf and run ldconfig so it will rescan dynamic libraries and add them to its cache.

• recompile libfwbuilder and fwbuilder with prefix /usr/, this will install libfwbuilder.so.0 in /usr/lib. ldd will find it there without any changes to environment variables or /etc/ld.so.conf file. To change prefix you need to run autogen.sh with command line parameter "--prefix=/usr". Do this both for libfwbuilder and fwbuilder.

If you get this error:

	      fwbuilder: error while loading shared
	      libraries: fwbuilder: undefined symbol: co
	      nnect__Q23Gtk9ProxyNodePQ23Gtk6ObjectPCcPFv_vPQ24SigC8S
	      lotDatab
	    

Then usually this error happens when old version of libgtkmm or libsigc++ library is used. Check if you need to upgrade those, you can use our Requirements document to find out what versions you need and where can you get them from.

sometimes this error happens even if new rpms have been installed. In this case you need to check which library gets picked up by fwbuilder when it starts. Sometimes old version gets stuck somewhere on a disk after upgrade and then ldd loads it instead of newer one. Try to download script called "check_libs.sh" from "Contribs" area on Sourceforge site of Firewall Builder and then run it like this:

	    check_libs.sh /usr/bin/fwbuilder
	  

it will list all dynamic libraries used by fwbuilder binary and what RPM they are part of. Look for libraries which are not part of any installed rpm, those cause the problem.

If you get this error:

	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxslt.so.1)
	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxsltbreakpoint.so.1)
	      fwbuilder: /lib/libc.so.6: version `GCC_3.0' not found (required by /usr/lib/libxml2.so.2)
	    

Most likely you are using libxml2 and libxslt packages from RedHat's distribution RawHide on your RedHat 7.1 system. It turns out these packages require new version of glibc, compiled with gcc 3.0. This library is not available for RedHat 7.1, therefore you should not be using libxml2 and libxslt from RawHide on RedHat 7.1.

Just follow instructions in our Requirements document and download libxml2 and libxslt from ftp.xmlsoft.org, these work on RedHat 7.1 and 7.2 just fine.

Please file a bug on Sourceforge. Provide information we might need to fix the problem:

• what version of fwbuilder do you run, did you install prebuilt binary packages or compiled it yourself ?

• Provide the output of the following commands:

                  cat /etc/issue
  
                  rpm -qa | grep gtk
                  rpm -qa | grep libxml
                  rpm -qa | grep libxslt
                  rpm -qa | grep libsigc++
  
                  ldd /usr/bin/fwbuilder
                  ldd /usr/bin/fwb_ipf
                  ldd /usr/bin/fwb_iptables
                

• Download script "check_libs.sh" from Contrib area on our Sourceforge page and run it as follows:

                  check_libs.sh fwbuilder
                

  include its output in your bug report.

Also send us core file and .xml file with your objects.

You need to install corresponding policy compiler. Our prebuilt compilers come in a separate RPMs named like this: fwbuilder-iptables-1.0.1-1rh7.i386.rpm

Did you install package with corresponding compiler ? Our prebuilt compilers come in a separate RPMs named like this: fwbuilder-iptables-1.0.1-1rh7.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_iptables  -f path_to_objects.xml   firewall_object_name
	  

All policy compilers have the same command line format.

We can not guarantee that Firewall Builder would work flawlessly on Debian 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

As of version 1.0.4, code and GUI dialogs supporting target firewall platform and host OS are not included in the GUI but rather come within additional packages. If your firewall is iptables, you need to install package fwbuilder-ipt. If it is ipfilter, then you need package fwbuilder-ipf. For OpenBSD PF you would need fwbuilder-pf.

Firewall Builder uses "stateful inspection" feature of underlying firewall platform. In case of iptables it loads module ip_conntrack which is tracking connections opened through the firewall and by the firewall itself. Since this module "remembers" each connection, there is no need in additional rule for "ACK" or "reply" packets. In fact, this module does lot more than keeping track of opened TCP sessions as it does similar thing to other protocols as well, where possible. Firewall Builder also loads some other modules to keep track of complex protocols, e.g. it loads module ip_nat_ftp to support FTP.

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.

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

• 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.

This question is outlined in Firewall Builder Tutorial in great details, what follows is just a brief explanation. You can find Tutorial online: http://www.fwbuilder.org/pages/Documents/Tutorial/index.html

There are two possibilities here, depending on what IP address you want to use to access your server - that of your firewall or virtual 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 virtual ip addresses for access to different internal servers.

• Using IP address of the firewall to access your server inside.

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

  Table 3.

  Orig.Src	Orig.Dst	Orig.Srv	Transl.Src	Transl.Dst	Transl.Srv
  Any	Firewall	Any	Original	Server	Original

  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.

• Using virtual IP address for translation

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

  Table 4.

  Orig.Src	Orig.Dst	Orig.Srv	Transl.Src	Transl.Dst	Transl.Srv
  Any	Server-NAT	Any	Original	Server	Original

  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

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.

First of all, download and install package fwbuilder-ipt-1.0.2. This package installs compiler's binary /usr/bin/fwb_ipt and man page fwb_ipt(1). New compiler can be used either from command line prompt or with fwbuilder GUI. In the latter case type "fwb_ipt" in the entry field called "Compiler (if different from default)" in the tab "Compile/Install" in firewall dialog, apply and then save changes to the file. The GUI calls compiler with predefined command line parameters which should be sufficient; adding "-v" makes it print more messages in the pop-up window indicating different stages of its operation.

Man page fwb_ipt(1) describes command line options.

Please see Release Notes for v1.0.2 and Roadmap on our web site for more details regarding new policy compiler for iptables.

"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.

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.

Iptables can either be compiled into the kernel or as a modules, it does not really matter. If some of the modules are missing, then respective feature won't work and you will get an error trying to load generates script. For example, if you compile everything into the kernel and leave ipt_LOG module out, then logging will stop working and you will get errors trying to load rules with logging turned on. Look into iptables HOWTO and Tutorial for more details as this problem is not really specific to Firewall Builder.

Here is (incomplete) list of modules taken from my firewall :

• ipt_limit

• ipt_REJECT

• ipt_multiport

• ipt_MASQUERADE

• ipt_REDIRECT

• ipt_state

• ipt_LOG

• iptable_drop

• iptable_filter

• iptable_nat

• ip_conntrack

• ip_nat_ftp

• ip_tables

• ip_conntrack_ftp

RedHat Linux comes with all iptables code compiled as modules.

You can turn debugging on (look for a checkbox in the tab "Firewall" in firewall dialog). This simple generates firewall script with shell option "-x" so it will print all commands while executing. This way you can see which command causes the error and trace it back to the policy rule.

This tool is part of the package 'iproute'; we use it to manage virtual IP addresses needed for some NAT rules.

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

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!

Another, more elaborate version of the same script is logwatcher2.pl. It is also available in Contrib area.

You can use our script connwatcher.pl available in Contrib area. It prints the contents of the connections table every second, sort of like top shows processes active in the system.

You can use rule options dialog and add unique log prefix for this rule. Open rule options dialog by right mouse clicking on rule element in the "Options" column. This way you can make rules generate special lines in the log, which you can later process with automated script, ot simply use while troubleshooting your policy.

Open Options dialog (under menu "Edit"), chose in the tree "GUI"->"Behavior" and check checkbox "Automatically save data in dialogs while switching between objects".