# Firewall Builder Release Notes

## Version 2.1.7

Released 10/31/2006
GUI and compilers v2.1.7 require API library libfwbuilder version 2.1.7

## Summary

For those who wish to build from source, instructions are outlined in the document "Install and Build instructions" on our web site here

## Installation

Packages of Firewall Builder 2.1 are built in a such way that you should be able to install them on the same machine with Firewall Builder 2.0.X. All binaries have names that end with "21", e.g. "fwbuilder21" or "fwb_ipt21". On Windows the binary name is the same but the package installs in directory c:\FWBuilder21 which is different from the default directory for Firewall Builder 2.0; all registry entries are also located in different subtrees. All this is done to ensure the user can run Firewall Builder 2.1 while still using stable version 2.0.12 on the same machine.

## Improvements and changes in the GUI

- The GUI works much faster with very large object trees. Tested using a data file with over 3000 objects)

- "Where used" menu item has been added to quickly find and show all groups and firewall rules that reference given object. Confirmation dialog that is shown when user tries to delete an object also shows all groups and rules that use it.

- By popular request, built-in installer can now save a copy of .fwb file to the firewall.

- Compile/install dialog is now an independent window instead of a modal dialog, this means the user can look at the policy and objects while compilation and/or installation is going on. This is especially convenient as it allows one to inspect the rules after failed compilation while still having compiler error on screen.

- Network discovery driud is back, ported from fwbuilder 1.0. As before, it supports reading object definitions from a file in /etc/hosts format, can read DNS zone and also can crawl the network using SNMP queries.

- Startup wizard ("Welcome to Firewall Builder") has been removed. The GUI now starts either into an empty database or opens data file specified on the command line.

- Keeping track of dependencies between objects. This is useful when many firewalls in the tree use the same set of objects. Each firewall object keeps track of objects it depends on, so if any object is modified, all firewalls that use it in their rules are marked with bold font to indicate that they need to be recompiled. Object dependencies are tracked not only when objects are directly used in rules, but also when they apepar there indirectly, as members of groups

- Added bulk compile and install operations. This is useful when there are many firewalls in the tree that need to be compiled and installed in one go. Bulk install operation is only possible if all firewalls use the same user name and password for authentication. If this is not the case, built-in installer can be instructed to ask for the authentication information before it touches each firewall.

- All object dialogs have been converted into built-in panels that appear in the right hand part of the main window. This simplifies navigation ( pop-up dialogs used to obscure parts of the main window). Objects open in the editor on a single mouse click in the tree and rules.

- Improvements in "Find" function: administrator can now drag an object into a well in the find dialog panel to make it search for this particular object. This is useful if the name of the obejct is not unique. Search by object's name or a value of its attribute is also possible.

- In addition to the "Find" function, the "Find and replace" operation has been implemented. Objects can be found and replaced in groups and firewall rules

## New object types, new rule types and rule elements, new actions and other new features

- AddressTable This object resolves to a set of IP addresses defined in an external file. The object can be configured to read the file at compile time or at run time. For each compile-time AddressTable object defined in the object tree compiler tries to find and read the file specified in the object configuration. Compiler aborts processing if the file can not be found or can not be read. If the file is in place and can be read, such AddressTable object behaves as if it was a group of IP address objects, that is, all addresses are explicitly copied into generated configuration, although compiler may use target firewall syntax that helps to group such sets of addresses into tables. Compilers for iptables, ipfw, ipf and PIX generate bunch of rules matching each address read from the file. Compiler for PF creates a table and also lists all IP addresses it reads from the file; it uses the name of the AddressTable object for the name of the table it creates.

  Run-time AddressTable objects are only supported by compilers for iptables and PF. Compiler for iptables generates shell code to read the contents of the file when firewall configuration is activated. Compiler for PF uses native "table <name> persist file <file_name>" syntax. Here also the name of the table is the same as the name of the AddressTable object it was created for.

- DNSName: This object resolves a host name to the IP address using DNS. Object can be confgiured to do so at compile time or run time. Resolution is done using system call gethostbyaddr() to read DNS A records for the name. System resolver should take care of recursion and CNAME records, if any. If the name resolves to several IP addresses, all addresses are used in the generated firewall configuration. Run-time DNSName objects rely on the target firewall software to be able to convert symbolic names used in rules into actual IP addresses at a time when policy is activated. Not all platforms provide means to support run-time DNSName objects.

- TagService: This object matches tags set by action Tag. It is translated into --mark <mark_code> for iptables and tag option for PF. This service object is only supported by compilers for iptables and PF.

- Interface objects can now have an attribute to mark them as bridge ports, used for bridging firewalls.

- Support for routing rules has been implemented using patch provided by Tidei Maurizio <fwbuilder-routing at compal.de> Support for routing rules is only implemented in compiler for iptables. See file README.routing included in fwbuilder2 package.

  > NOTE: I can only provide very limited support for this feature, please direct your questions and bugreports to the author

- Global policy and interface policies have been merged. Each policy rule now has rule element "Interface". Administrator can drag and drop interface object of the firewall into this rule element field. Policy compilers support multiple interfaces and negation in "Interface" rule element. Rule element "direction" that previously was only part of the interface policy rules is now part of all policy rules.

- Policy rules can have the following new actions:

  - Queue: This action passes the packet to user space process for inspection, it is translated into QUEUE for iptables and divert for ipfw. This action is only supported by compilers for iptables and ipfw..

  - Custom: This action allows administrator to define arbitrary piece of code to be used in place of an action. Supported by compilers for iptables, ipf and ipfw

  - Branch: This action is used to create a branch in the rule set. It works on target platforms that provide suitable syntax and allow control to return to the higher level rule set if the branch can not make final decision about the packet. For iptables this action is translated into user-defined chain. The name of the chain is the name of the branch choosen by administrator. For PF this action is translated into an anchor with the name the same as the name of the branch defined by the administrator. This action is only supported by compilers for iptables and PF.

    Fig.1 Rule #0 of the global policy creates a branch with the name rule0_branch

  - Tag: This action associates internal tag with the packet. Tag can later be inspected using service object TagService. This action is translated into MARK target with corresponding --set-mark parameter and optionally additional rule with CONNMARK --save-mark target for iptables. If option that activates CONNMARK target is used, compiler also adds a rule at the very top of the policy to restore the mark. Rules are placed in INPUT,OUTPUT and FORWARD chain of the "mangle" table, this ensures that DNAT happens before rules placed in the mangle table see the packet. PREROUTING chain in mangle table is executed before PREROUTING chain in the nat table, so placing tagging rules in the PREROUTING chain would make them fire before DNAT. POSTROUTING chain of the mangle table, as well as its FORWARD and OUTPUT chains, work before corresponding chains of the nat table. In all cases the goal is to make sure DNAT rules process the packet before, and SNAT rules process it after filtering and tagging rules.

    For PF this action is translated into tag. Supported only by compilers for iptables and PF.

    Fig.2 Example of a rule utilizing action Tag. To illustrate policy branches, this rule belongs to the branch with the name rule0_branch

  - Classify: This action allows the firewall to define QoS class for the packet that matches the rule. It is translated into CLASSIFY for iptables, with parameter --set-class. For PF it is translated into queue; compiler for ipfw can use pipe, queue or divert depending on how the action is configured by the administrator in the GUI. This action is only supported by compilers for iptables, PF and ipfw.

  - Route: This action makes the firewall to route the packet that matches the rule through an interface or a gateway specified in the parameters of the action. This action is translated into ROUTE target for iptables and route option for PF and ipfilter. Compilers for PF and ipfilter support fastroute, route-to, reply-to and dup-to options.

    Fig.3 Rules #0 and #1 tag packets entering the firewall through interfaces eth0 and eth2; rules #3 and #4 help route reply packets back through the same interfaces

  The GUI uses different names for the new actions depending on the target firewall platform to simplify adoption. For example, new action that created branch in rule set is called Chain for iptables firewalls and Anchor for PF fierwalls.

- Firewall object now has an attribute "inactive". Firewall marked as inactive will not be picked by the GUI for the bulk compile and install operations even if the timestamps indicate that this firewall object needs to be recompiled

## Compiler for iptables

- Support for address tables loaded from external files at compile or run time

- Support user defined chains with predefined names (using special action )

- Support for CLASSIFY, MARK, CONNMARK, QUEUE, ROUTE targets

- Support for physdev module for bridging firewalls

- additional optimization of rules i INPUT and OUTPUT chain: now removing firewall object from src or dst to simplify rule if it uses OUTPUT or INPUT chain. Doing this only if original rule did not have negation and we do not add any virtual addresses for NAT. After removal the rule collapses to a simple command like this:

      	iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

  this works fine except if we have added virtual addresses for NAT. It is assumed that firewall object in rules represents combination of addresses configured in its interfaces in the GUI. Virtual addresses added for NAT are considered to be a side effect and connections should not be implicitly permitted to them by a rule with fw object in destination. The same applies to fw object in source. See bug #685947 for discussion. To avoid inadvertently opening holes in the firewall by a rule like that, we remove fw object only when it is safe to do so.

- support for modules connlimit and hashlimit. There is an option to generate commands for the latter module using name dstlimit because older versions of iptables included this module under this (now obsolete) name.

## Compiler for PF

- Support for load balancing rules
- Support for tag and route options
- Support for address ranges and networ objects in TSrc in NAT rules
- Support for pool types in NAT rules ('bitmask', 'random', 'source-hash', 'round-robin'), as well as 'static-port' option.
- Supprot for anchors (by way of a special action)
- Support for tables with predefined names (using AddressTable object)
- Support for packet 'tagging' (by way of a special action and service object TagService)

## Compiler for ipfilter

- Support for PPTP and IRC proxies
- Support for route option

## API

- internal object ID is augumented with process ID of the program that creates an object. This allows fwbedit to quickly create objects and still ensure their IDs are unique

## fwbedit

Fwbedit can now create objects and repair broken object database. This tool can now be used to populate object database using shell scripts or other automation. For example, to create an address object in object library 'Test' one could run it like this:

> fwbedit -f filename.fwb -t IPv4 -n newAddress -L Test -o 192.0.2.1

           Firewall Builder:  general purpose object tree editing tool
           Version 2.1.5-b
           Usage: fwbedit21 -f filename.fwb -u [-a obj,grp] [-r obj,grp] [-d obj] [-s] [-l path] [(-p parent|-L library) -t objtype -n objname [-o object attributes]]

           -t objtype : create an object of this type
           -L library : specify library when creating a new object
           -p obj     : specify parent object when creating a new object
           -n name    : specify a name of the new object
           -o attribute1[,attribute2...]  :  specify attributes when creating a new object
           -a obj,grp :  create reference to object 'obj' in the group 'grp'
           -r obj,grp :  remove reference to object 'obj' from the group 'grp'
           -d obj     :  delete object 'obj' and remove references to it from
           all rules and groups
           -l path    :  print list of objects for 'path'
           -s         :  test and repair object tree structure
           -u         : autoupgrade of file

           An object and a group can be defined by their ID or
           by the full path and name in the XML tree

           Object creation syntax:

           -t Firewall -n obj_name -L User -o platform, host OS
           -t IPv4 -n obj_name -L User -o IP address
           -t DNSName -n obj_name -L User -o DNS record,run time
           -t AddressRange -n obj_name -L User -o start address, end address
           -t ObjectGroup
           -t Network -n obj_name -L User -o address,netmask
           -t Interval -n obj_name -L User -o start time,start date,start day,end time, end date, end day
           -t Interface -n obj_name -L User -o security level,address type (dynamic or unnumbered),management
           -t Host
           -t TCPService -n obj_name -L User -o source port range start,end,Destination port range start,end,UAPRSF,UAPRSF
           -t UDPService -n obj_name -L User -o source port range start,end,Destination port range start,end
           -t ICMPService -n obj_name -L User -o ICMP type,ICMP code
           -t IPService -n obj_name -L User -o protocol number,lsrr/ssrr/rr/ts/fragm/short_fragm