NAME

Linux Firewall Builder - XML to IPtables Converter

SYNOPSIS

Converts firewall definitions written in XML to an iptables based shell script suitable for Linux based firewall boxes.

Description

Linux firewalls with large numbers of chains can quickly become unwieldly to maintain, especially if there are multiple firewalls containing common rulesets, which can lead to errors being introduced into the firewall's configuration.By writing the firewall definitions in XML these rules become much simpler to maintain and hopefully eliminate dangerous configuration errors.

This program reads an XML firewall definition file, parses it and then creates a Bourne shell script which is suitable for use as an init.d script, suitable for loading the filewall at system boot time.

Installation

The program MakeFW.pl requires XML::Parser, it also uses these Perl modules:

Firewall.pm
contains the Firewall object class for internal representation of the rulesets

IPtables.pm
contains the IPtables specific code and boiler plate code for generating the shell scripts. In theory this module could be replaced to generate rules for other types of firewalls e.g. IPchains or IPFW.

These modules need to be accessible to MakeFW.pl so it usually enough to drop them in the same directory as the main program.

Creating the XML

Refer to the DTD for details on the XML structure.

The firewall definition starts with a firewall element this has two attributes host and file. The host attribute should be set to the name of the machine on which the firewall is to be run. This ensures that the wrong firewall file can not be loaded on to the wrong machine. The file attribute defines the filename in which to store the generated firewall.

The include element can be used anywhere to include additional XML files, for example, allowing common host and service definitions to be used in several firewalls. Eg. <include file="hosts.xml">

The remainder of the file is made up of four sections:

Host Definitions
The hostgrp element allows IP addresses, hostnames and network/netmask pairs to be grouped together for ease of use. Eg. 
 <hostgrp name="myhosts">
 myhost.mydomain.com
 10.0.1.1
 10.0.2.0/24
 </hostgrp>

Interface Definitions
Interface definitions allow network devices to be associated with tags which are then used in the rule chain definitions. The interface element has the following attributes: 
 name:          defines a human friendly name for the interface. The
                name is also used in the generated rule chain names
 in/out:        defines whether rules on this interface are
                associated with incoming or outgoing packets
 tag:           defines a name that can be used in the rule chain
                definitions. Multiple interfaces can use the same tag
                allowing the same rulesets to be applied quickly to
                multiple interfaces.
 broadcasts:    setting this attribute to "deny" drops broadcast
                packets immediately without passing them through the
                rule chains. Setting this to "allow" permits broadcast
                packets to enter the rule chains, for example in the
                case of a DHCP server.
 For example,
 <interface name="dirty" in="eth0" tag="dirty" broadcasts="deny">

Service/Group Definitions
Service definitions allow a combination of protocols, ports, source addresses and destination addresses to be associated with a service name to be used in the chain definitions. Protocol can be any of 'tcp', 'udp', 'icmp', 'gre' or 'all'.

Port is a comma separated list of ports numbers or service names. A port range is defined as lowport:highport where either lowport or highport may be omitted to use the default lowest or highest ports.

For example,

 <service name="web" port="http,https" proto="tcp">
 <dst>wwwServers</dst>
 </service>

Group definitions are a flexible way to define complex service definitions, and can consist of a mixture of service definitions (without the name attribute), source and destination address definitions.

For example,

 <group name="bootp">
   <service proto="tcp" port="bootp"/>
   <service proto="udp" port="bootp"/>
 </group>

Chain Definitions
There are two chain definition elements input and forward. These take one attribute which is the tag of the interface to which the rules should be applied. These elements should contain a services element which lists the service or group names that are to be included in the chain.

For example,

 <forward interface="public">
  <services>
    web
    smtp
    imap
  </services>
 </forward>

Additional XML options

blacklist
The blacklist element can be used to define address/networks to be dropped before any other rules are checked. This can be used if a host is performing a denial of service type attack.

enable
By default the src-addr-check chain drops traffic the firewall doesn't expect to see appearing on its interfaces, eg. loopback traffic. It also drops: 
        Class A (10.0.0.0/8)
        Class B (172.16.0.0/12)
        Class C (192.168.0.0/16)
        Class D Multicast (224.0.0.0/4)
        Class E Reserved (240.0.0.0/5)
        Link Local (169.254.0.0/16)

However, if sites use these addresses for internal servers the enable element can be used to prevent the specified address class being loaded into the src-addr-check chain. For example, to prevent class_a addresses being dropped use:

  <enable>class_a</enable>

fastdrop
The fastdrop attribute can be added to a firewall, service or group element. When set to true this attribute causes packets to bypass the firewall logging rule. This is achieved by dropping packets in the rule chain rather than letting them fall through to the default policy.

ipforward
If a firewall XML definition contains more than one interface definition the generated Bourne shell script will assume the firewall is to run on a machine acting as router and automatically turn on IP forwarding. In certain instances this may not be the desired action. The ipforward attribute can be added to a firewall element to disable IP forwarding. For example: 
 <firewall host="mymachine" file="example.fw" ipforward="disable">
 ...
 </firewall>

order
By default packets are checked against rules by protcol and port, followed by destination address and finally by source address. In some instances it may be more optimal to check either the source or destination first.

The order attribute can be added to service definitions to optimise a rules. For example:

  <service name="example" proto="tcp" port="http" order="dst,src,svc">
   <dst>host1</dst>
   <src>host2</src>
  </service>

physdev
Two attributes physdev-in and physdev-out can be added to service definitions to allow the use physical device matching. This is useful if the firewall is to be used in conjunction with bridging where you need to know where a packet came from.

For example:

  <service name="example" proto="udp" port="67" physdev-in="eth0"/>

policy
The default policy for blocked packets is drop, however, in some cases it may be desirable to reject packets instead. The policy attribute can be added to service definitions to specify the required policy options are ACCEPT, DROP or REJECT.

sport
The sport attribute can be added to a service definition to add a single source port to a rule.

Usage

  MakeFW.pl [-n][-d] <file.xml>
        -n : Resolves hostnames and port names to their numeric values.
        -d : Dumps the internal data structure once file.xml has been 
             parsed without creating a shell script.

Rule Installation

First time rule installation requires the script to be copied into the init.d directory and activating via chkconfig as outlined below:

  1.  cp firewall.fw /etc/rc.d/init.d/firewall
  2.  /sbin/chkconfig --add firewall
  3.  /etc/rc.d/init.d/firewall start

Subsequent rule installations only require the modified script to be copied into place an reloaded as outlines below:

  1.  cp firewall.fw /etc/rc.d/init.d/firewall
  2.  /etc/rc.d/init.d/firewall restart

Troubleshooting

The generated Bourne shell script has a number of Enablefeature definitions which can be used during troubleshooting. These can be used to prevent various features of the firewall being loaded at runtime.

The SilentDrop feature drops a number of packets before they get to the log section. This was designed to prevent the firewall log being filled up with broadcast traffic from NetBios, bootp/DHCP etc. This can be turned off by EnableSilentDrop=0

AUTHOR

        Stephen Pillinger <S.M.Pillinger@cs.bham.ac.uk>
        School of Computer Science,
        The University of Birmingham, UK.
        http://www.cs.bham.ac.uk/~smp

Notes

I've modulised the package so in theory the iptables module could be replaced with an ipfilter or ipfw module if necessary. Although I've not had (nor am I likely to get) the time to test this. I'm probably not going to get time to fix any major bugs or add any extra features.