This article is part of a series regarding firewalling and network security using the Firewall Builder tool on Ubuntu. This is user-contributed content. If you would like to contribute an article, please see the About page for contact information.

Using Built-in Policy Importer in Firewall Builder

Author: vadim@fwbuilder.org http://www.fwbuilder.org

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.

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 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 <interface>” or “-o <interface>” 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 follwoing 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.

Other Points of Interest

• May 4, 2008 — Why ufw Does Not Need A GUI (14)
• June 3, 2009 — Getting Started with Firewall Builder (4)
• February 28, 2009 — Standard Process for Restoring IPtables at Boot? (11)

Getting Started with Firewall Builder

Author: vadim@fwbuilder.org http://www.fwbuilder.org

This guide starts a series of articles about 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. The first article is an introduction to the program. We will follow up with series of articles focusing on more advanced aspects of it in the coming weeks.

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

If it is not there, then it probably needs to be installed on your system. You need to install package that has supporting API library libfwbuilder and package fwbuilder that contains 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 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 can be installed using our repositories of rpm and deb packages, see instructions on 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 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 bug tracking system and links to user forums and 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”.

Lets create our first firewall object. To do this, we’ll use 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.

The program presents wizard-like dialog that will guide you through the process of 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 new firewall can be created: you can use one of the preconfigured template firewall objects or create it from scratch. This tutotiral demonstrates the first method (using template object). To do this, check checkbox “Use pre configured template firewall objects”. Template can be taken from the library of template objects that comes with Firewall Builder package or from a file provided by the user. The latter is useful when 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 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 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 addresses of interfaces to match those used on your network and most likely will have to adjust rules to match your security policy.

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 object, including 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 chosen template.

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 little later in this tutorial.

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

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

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.

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

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.

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.

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.

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

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

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 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”: 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 firewall 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 firewall. 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.

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.

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.

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:

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.

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

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

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.

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:

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:

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.

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 next slide.

Online help explains all attributes and parameters located in each tab of the firewall settings dialog. I encourage 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.

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.

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.

Parameters for logging.

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.

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.

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

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

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

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

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.

Other Points of Interest

• June 12, 2009 — Firewall Builder: Using The Policy Importer (0)
• July 9, 2008 — Enable Timed or Automatic Login on Ubuntu 8.04 (10)
• June 29, 2008 — “What Would You Like To See?” Poll Expiring Tomorrow (10)
• June 18, 2008 — Tunnel Web and DNS Traffic Over SSH (5)
• May 4, 2008 — Why ufw Does Not Need A GUI (14)

The one missing link in most users transition to a new browser however is their reliability on extensions. I know I have a few extensions that I really don’t like to live without. I bet you do as well. Let me guess what your number one extension is? AdBlock Plus? So, if these new browsers don’t have an extension architecture (yet), how can I block ads? You can use your /etc/hosts file.

Let me tell you, quickly, about the /etc/hosts file for those that may not be familiar. The /etc/hosts file is the predecessor to the DNS system that we use now. It is a local mapping of IP address to hostname. At this point, as we now rely on DNS, the /etc/hosts file is generally pretty empty. You’ll likely just have entries that make sure your machine can find itself by localhost or hostname. Something along the lines of:

127.0.0.1    localhost  hostname

Now, you might be thinking “How am I going to block all the internets advertisements if my /etc/hosts file looks like that?” Well, you won’t, if it just looks like that. I have a solution for you though, and it requires very little work on your part.

In searching for a solution I have come across an /etc/hosts file that is (minus comments) 15,169 lines long. That’s right. Fifteen thousand one hundred sixty nine lines long. That is a lot of mapped IP addresses! What someone has done is collect every nasty thing he could find into the hosts file, and map it to 127.0.0.1.

What does that actually mean? It means that anytime your browser is told to display an ad it’ll need to look up the address. The /etc/hosts file is checked first before DNS, which then tells it to ask the local machine. The local machine, of course, does not have that information to display and therefore nothing is displayed. Bingo! No more ads.

But wait, there’s more! This not only applies to blocking ads, but also banners, 3rd party cookies, 3rd party page counters, web bugs, and even most hijackers. You’re not only blocking advertisements, you’re outright blocking thousands of known problematic and malicious websites. And all this without requiring a single Firefox extension. It works in ANY browser.

So, I hope you’re wondering where you can get a copy of this magical file that solves all of the worlds woes. Well you can get it here of course!

disclaimer: I am not the original author of this file, but it has been published under a CC-BY-SA license and under that license I am redistributing it. Attribution is contained within the file itself.

sudo mv /etc/hosts /etc/hosts.orig

sudo wget -c http://zelut.org/projects/misc/hosts -O /etc/hosts

These commands will move your original file as a backup and then pull the file from the web, putting it directly where it needs to go. You should be ready-set-protected after completion of the second command. Pull up a browser (hopefully you’ll try something other than Firefox), and give it a try.

If you have anything to add or subtract from the hosts file, you may edit it directly with a text editor. If you’d like to share your changes with the rest of us you may email me your update in the form of a patch. Please make sure your patch is created against the latest version.

I hope this solution works for many of you towards trying out and helping improve alternate browsers. Again, I highly suggest Midori or Arora as GTK or Qt (respectively) WebKit based browsers.

Other Points of Interest

• June 18, 2008 — Tunnel Web and DNS Traffic Over SSH (5)
• April 4, 2009 — Help Needed: Auto-Configure Proxy Settings via DHCP (13)
• February 24, 2009 — DNS Hiccup (0)
• February 22, 2009 — Server Migration Complete (5)
• November 12, 2008 — Wiki Editing With Your Favorite Editor (5)
• October 25, 2008 — Ubuntu Tutorials Search Plugin (1)
• July 15, 2008 — Create Smart Keyword Search for Ubuntu Tutorials (7)
• July 8, 2008 — Improve Application Startup Times With Preload (5)
• June 25, 2008 — Install Adobe Acrobat Plugins For Firefox (5)
• June 22, 2008 — Firefox Shortcut Keys (21)

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys <key id>

You can gather the <key id> in the output of:

sudo apt-get update

You should see the warnings, along with the key id at the bottom of the output.

For each GPG key that you get a warning on, run the command above, and you’ll stop seeing the warnings. You will have imported that team/project’s GPG key into your keyring, considering them trusted.

Other Points of Interest

• July 21, 2008 — A supported PGP passphrase agent is not running (1)
• June 11, 2008 — Like Gnome-Do? Check Out The 0.5 Release! (9)

Inside the sshd_config file (/etc/ssh/sshd_config) there is a setting for ClientAliveInterval and ClientAliveCountMax.  Edit these two lines to look something like:

ClientAliveInterval 300
ClientAliveCountMax 0


Once these settings are changed you’ll need to restart your SSH server for them to take effect.

sudo /etc/init.d/ssh restart

Now, if an SSH session is connected with no activity for five minutes, it’ll be automatically logged out. Hopefully reducing the chance of an open connection becoming vulnerable at an idle workstation.

Other Points of Interest

• March 6, 2009 — SSH Pop Quiz (14)
• June 18, 2008 — Tunnel Web and DNS Traffic Over SSH (5)
• June 12, 2008 — Use VNC? Encrypt It Via SSH (9)

I know that Red Hat and its variants use the /etc/sysconfig/iptables file as a save and restore point, and there is an init script, iptables, that starts at boot prior to the network script, but is there a similar standard on Debian/Ubuntu?

The solution I’ve come up with (and I’m very curious to hear what others have done) is the following:

First, I manually enter my base iptables rules…

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -s 17.88.115.150/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 111.70.51.51/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -s 16.10.111.177/32 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable
...etc, etc.


*(ip addresses have been scrambled to protect their identity)

I then run:

iptables-save > /etc/default/iptables


From this point forward I manually update my ruleset by editing the file directly with a text editor.

To reload these rules at boot-time I have added a line to my /etc/network/interfaces configuration as follows:

auto eth0
iface eth0 inet static
address foo
netmask bar
gateway baz
dns-search domain.tld
dns-nameservers foo
pre-up iptables-restore < /etc/default/iptables

That last line tells the machine that, before you activate these network settings, run iptables-restore and read from the file /etc/default/iptables.  This seems to work well enough so far, but I’m still curious what others have done.  Do you simply write an init script on your own and maintain the ruleset within that file?  Do you use a file similar to what I’ve done, but source it via an init script?  I’m curious, as there does not seem to be a standard that I’m aware of.

Other Points of Interest

• June 12, 2009 — Firewall Builder: Using The Policy Importer (0)
• April 23, 2009 — Ubuntu 9.04 “Jaunty” Released: Torrents Available Here (14)
• April 1, 2009 — Four Years and Counting.. (0)
• March 3, 2009 — Thinking About Covering More Than Just Ubuntu… (25)
• October 24, 2008 — Install Xubuntu Desktop alongside Ubuntu (12)
• June 27, 2008 — Presenting at OSCON 2008 : July 21-25, 2008 (1)
• June 19, 2008 — Extend Your Battery Life With Powertop (9)
• June 7, 2008 — How To Install VMware Tools on Ubuntu 8.04 Guests (28)
• May 4, 2008 — Why ufw Does Not Need A GUI (14)

The issue that I have been running into is that no supported PGP passphrase agents were running.  In other words I was not able to unlock my PGP keys for email signing and encryption.  You will have noticed this problem if you use email signing and encryption with tools such as Enigmail, etc.

The solution that I found, which is also outlined within the bug, is to remove a file that is apparently being loaded when the X session starts.  For some reason this file conflicts with the seahorse key caching system, and neither work.

To fix the issue simply move the conflicting file elsewhere:

sudo mv /etc/X11/Xsession.d/90gpg-agent ~/90gpg-agent.bak

Once this file is moved you should be able to restart X and have your key-caching functionality again.  If anyone else has a better fix or other suggestions please comment.

Other Points of Interest

• May 14, 2009 — Add PPA Key To Your Apt Keyring (3)

Step 1: Creating the Tunnel

Creating this private connection you’ll need a remote SSH server to connect to. Mine runs at home in my garage on an old Pentium III 500MHz box (yeah, the kind most people threw away long, long ago!). I connect to this tunnel using:

ssh -D 8080 -fN user@server

This creates a SOCKS compatible proxy, which is a requirement of the DNS forwarding. Other methods on the interwebs suggest using ssh -L or similar, which are not SOCKS compatible proxies.

Step 2: Forwarding DNS

If you’d like to also forward your DNS requests (ie; the site addresses you type into your browser), you’ll need to change a setting in Firefox. This can be done by accessing the address about:config, and entering this string into the configuration:

network.proxy.socks_remote_dns

Change this value to “true”.

Step 3: Using the Tunnel

The last step is to configure your browser to use these new settings. In Firefox 3 (I hope you’ve upgraded by now), you can activate/toggle these settings via:

Edit > Preferences > Advanced > Network > Settings

Select “Manual Proxy Configuration” and add localhost to the “SOCKS Host:” field, followed by port 8080 (assuming you’ve used the port in the example above).

This will then forward your web traffic through the SSH tunnel and DNS requests will also be forwarded.

You may want to check out the FoxyProxy plugin for a simpler way of toggling this on & off.

To deactivate the tunneling and use the local DNS again simply revert Step 3 back to “Direct Connection to the Internet”.

Other Points of Interest

• May 15, 2009 — Block Advertisements in ANY Browser via /etc/hosts (19)
• June 12, 2008 — Use VNC? Encrypt It Via SSH (9)
• June 3, 2009 — Getting Started with Firewall Builder (4)
• April 4, 2009 — Help Needed: Auto-Configure Proxy Settings via DHCP (13)
• March 6, 2009 — SSH Pop Quiz (14)
• March 2, 2009 — Automatically Logout SSH Sessions After Period of Inactivity (2)
• February 24, 2009 — DNS Hiccup (0)
• February 22, 2009 — Server Migration Complete (5)
• November 12, 2008 — Wiki Editing With Your Favorite Editor (5)
• October 25, 2008 — Ubuntu Tutorials Search Plugin (1)

If you use VNC regularly to connect to other Linux machines you may want to consider adding a level of encryption with SSH. Here is a quick run-down on how that is done:

If you look at the man page for vncviewer (man vncviewer) you’ll notice there is a small section for -via. The -via option, as outlined in the man page will do:

Makes the connection go through SSH to a gateway host. The gateway should be the target host for best connection secrecy.

Basically this is saying that you can tunnel VNC over SSH within your connection command. Let’s give it a try.

vncviewer -via user@host localhost:0

This, of course, will require that you have both ssh and vnc access to a remote machine.

This is a much simpler method than many other tutorials I’ve found which generally suggest creating a tunnel with ssh -L and then using that tunnel.

Other Points of Interest

• June 18, 2008 — Tunnel Web and DNS Traffic Over SSH (5)
• March 6, 2009 — SSH Pop Quiz (14)
• March 2, 2009 — Automatically Logout SSH Sessions After Period of Inactivity (2)

If you’ve never installed openssh-server, used openssh-clients or generated an X.509 certificate you should be safe.  If you have done any of the above keep reading for a validation and fix instructions.  It can’t hurt to run the validation script in either case, just to be safe.

Security patches have been deployed to the Ubuntu archives so the first step is to, of course, apply any security patches available.

Am I Affected?

The first item at hand is verifying whether or not you have been affected by the vulnerability.  As mentioned above there are some common tasks that would qualify, but lets test your machine to make sure.

Download the script linked below and run it using the example syntax below:

dowkd.pl.gz (Download this file and unzip)

dowkd.pl PGP signature (Optionally verify the signature of the script)

Cut-n-Paste command-line example of downloading and running the test:

wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
gunzip dowkd.pl.gz
chmod u+x dowkd.pl
./dowkd.pl user
./dowkd.pl host <hostname>

If you see output similar to:

/home/username/.ssh/id_dsa.pub:1: weak key

…then you have been affected by the vulnerability.  If you do not see “weak key” reported then you are OK.

How Do I Fix My Machine?

To update your machine and patch the vulnerability the first thing you want to do is check for and apply any system updates available.  The main Ubuntu archives have been updated with the fixes.  If you are using an alternate mirror the fix may not have propagated yet, so you may not see it available for another few hours.

Apply any updates:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

You should see an update for openssl and openssh packages (along with anything else available).

After these new packages have been applied you’ll want to regenerate any keys that you’ve generated (ie; openssh keys, CA cert, etc).

UPDATE: The latest package release will automagically re-create any server-side ssh keys for you and notify you of the reason. Also, there is a new utility built into the latest release that will check keys for you. After your updates are applied try the tool:

ssh-vulnkey

To generate a new openssh key for your user: (This only required if ‘./dowkd.pl user‘ reports weak)

ssh-keygen -t dsa -b 1024

To generate a new openssh key for your server: (This only required if ./dowkd.pl host <hostname> reports weak)

sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
sudo dpkg-reconfigure -plow openssh-server

You should now run the validation script again and make sure it does not report any errors.  If you still see reported warnings such as:

/home/username/.ssh/authorized_hosts:1: weak key

…this means that you have authorized_host keys saved that are still affected.  Open the .ssh/authorized_hosts file with a text editor and delete the affected line (:1: means line 1, etc).

Continue to run the ./dowkd.pl script until no weaknesses are reported.

These steps should be run on any system that you manage to ensure they are sufficiently patched.

Other Points of Interest

• July 6, 2008 — Install the 1.15.2 “no CD” Patch for StarCraft on Ubuntu 8.04 (6)