Ubuntu Tutorials : Dapper - Hardy - Intrepid - Jaunty

Using Built-In Revision Control in Firewall Builder

Christer Edwards — Thu, 09 Jul 2009 18:18:48 +0000

Using Built-In Revision Control in Firewall Builder

Revision 1.0

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 one of the more advanced features of Firewall Builder – built-in Revision Control System (RCS).

Firewall Builder GUI has built-in revision control system that can be used to keep track of changes in the objects and policy rules. If data file has been added to the revision control system, every time it is saved, the system asks the user to enter a comment that describes changes done in the file in this session and stores it along with the data. The program also assigns new revision number to the data file using standard software versioning system with major and minor version numbers separated by a dot. When you open this data file next time, the program presents a list of revisions alongside with dates and comments, letting you choose which revision you want to use. You can open the latest revision and continue working with the file from the point where you left off last time, or open one of the older revisions to inspect how the configuration looked like in the past and possibly create a branch in the revision control system. Here we take a closer look at the built-in revision control system.

We start with a regular data file which we open in the Firewall Builder GUI as usual. Note that the name of the file appears in the titlebar of the main window, here it is [test2.fwb]:

You can always see additional information about the file using main menu File/Properties. There is not much the program can report about this file that we do not know already. It shows full path where it is located on the file system and the date and time of last modification, but otherwise since it has not been added to the revision control system, there is no additional information it can report.

To start tracking revisions of this data file, use menu File/Add File to RCS, the program creates all necessary files and reports result in a pop-up dialog. If for some reason adding file to the revision control has failed, the program reports error in the same pop-up dialog. Firewall Builder FAQ “Using RCS” has a list of typical problems that may occur at this point.

Few things have changed in the GUI after the file has been added to the revision control system. First, besides its name the titlebar now shows its revision. Inital revision number after the file has just been added to the revision control is 1.1.

The File/Properties dialog shows that the file is now being tracked by revision control system and its current revision is 1.1. There is only one revision in the history and the comment is “Initial revision” which is added automatically by the program.

Let’s see how revision control system keeps track of the changes done in the data file. To demonstrate this, I am going to make a change in one of the objects, save the data file and check it (this creates new revision), then I’ll close it and open it again, first the latest revision where the change is present, and then previous revision where the change is absent.

Here is the rule set of this firewall I have started with, it is very simple and consists of just 5 rules:

Now I added one more rule (to permit HTTP to the firewall). This is rule #3, it is colored yellow:

Now I save ths file using menu File/Save and exit the program. Before I can do that, however, the program tries to check the file in to the RCS and presents a dialog where I can add a comment to document the change I made. I enter the comment and press Check file in button to complete operation. The file is now checked in and the program exits.

Now I restart the program and try to open the same file using File/Open. Since the file is now in RCS, the program presents the dialog with the list of its revisions. Each revision has a comment associated with it, shown at the bottom of the dialog. Note also that each revision also shows the user name of the user who checked it in which is very useful in a multi-user environment.

If I choose revision 1.2 (the latest) and open the file using button Open, I get my rules including rule that permits HTTP to the firewall:

If I choose revision 1.1 and open the file, I get the policy that looks like this (note revision number in the main window titlebar, it is 1.1):

The rule to permit HTTP to the firewall is not there because I opened old revision of the data file. Essentially, I rolled back the change I made in rev 1.2. If I only wanted to look how rules looked like in rev 1.1, then I can now just close the file and open its latest revision to continue working with it. I can not only just look at the rules in the old revision, I can compile them and install on the firewall if that is what I need to do. Note that this can break things if some protocols were added to the firewall rules later, but this can be useful if you need to test things as they were few days ago.

However if I want to roll back the change and continue without it, all I need to do is make the change in this revision (1.1) and then save and check it in. This will create a branch in RCS and I will be able to continue working with it later. The previous change, checked in as rev 1.2 will always be there though and I will always be able to revert to it if I want. The program does not merge branches, merging changes in XML files is a complex task and is not
implemented at this time.

To illustrate creation of a branch, I am making a change to the revision 1.1 of the data file as shown on the next screenshot:

I then save and check this file in with appropriate comment. To check it in I use menu File/Commit. I then close the file using File/Close and reopen it again using File/Open. This acomplishes the same operation as in the example above in this document, except I do not close the program. When I try to open it, the program shows the branch and new revision 1.1.1.1 that I just created. Note that the time of the revision 1.1.1.1 is later than the time of revision 1.2:

Now if I open rev 1.1.1.1 and continue working with and check new changes in, the program will create revision 1.1.1.2 and so on.

This document demonstrates how built-in revision control system (RCS) in Firewall Builder GUI can be used to document changes in the file. It can also be used to roll back changes to previous revision both temporary or permanently. Using RCS helps establish accountability if several administrators can make changes to the policy of firewalls because RCS keeps track of the user name of user who checked changes in. RCS in Firewall Builder works on all supported OS, that is Linux, FreeBSD, OpenBSD, Windows and Mac OS X. On Linux, *BSD and Mac OS X it relies on system-wide installed rcs package, while on Windows rcs tools are installed as part of the Firewall Builder package. In general, I recommend always using RCS even in simple cases when only one administrator uses the tool. Ability to document changes and roll back if necessary are great advantages that help a lot to improve the process of security policy management.

Other Points of Interest

No Related Post

C# and CLI Now Under Community Promise

Christer Edwards — Tue, 07 Jul 2009 04:26:59 +0000

I just read here and here regarding a move by Microsoft to put the ECMA 334 and 335 specs under the Community Promise. From the Port25 blog:

ECMA 334 specifies the form and establishes the interpretation of programs written in the C# programming language, while the ECMA 335 standard defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments.

This means that the core C# programming language and the Common Language Infrastructure are now legally free to use, without fear of being sued. For those interested, the full terms of the Community Promise are found here.

One major point that you’ll notice in the Community Promise agreement is this:

Q: Is this Community Promise legally binding on Microsoft and will it be available in the future to me and to others?

A: Yes, the CP is legally binding upon Microsoft. The CP is a unilateral promise from Microsoft and in these circumstances unilateral promises may be enforced against the party making such a promise. Because the CP states that the promise is irrevocable, it may not be withdrawn by Microsoft. The CP is, and will be, available to everyone now and in the future for the specifications to which it applies. As stated in the CP, the only time Microsoft can withdraw its promise against a specific person or company for a specific Covered Specification is if that person or company brings (or voluntarily participates in) a patent infringement lawsuit against Microsoft regarding Microsoft’s implementation of the same Covered Specification. This type of “suspension” clause is common industry practice.

I find this to be a big step forward for the pro-mono camp in that they now have a document to show that the implementation of and distribution of mono applications is not and will not be a legal issue. This gives them reassurance as individual developers, and distribution maintainers that their work will not be called into question by the patent holders in the future. While this should mean that the mono wars should finally stop, I have no faith that they actually will. I know full well that the people on the anti-mono side of the fence will grasp for something else instead. It is the same infighting the community has been doing since the beginning, and if it isn’t mono it’ll be something else. As a group I don’t think we are capable of simply getting to work without bickering about something.

To the folks in the mono camp I say congratulations. Keep up your hard work! For those that are still determined to fight against it, please try to find something productive to do with your time.

Other Points of Interest

No Related Post

Disable Boot Splash: Ubuntu 9.04

Christer Edwards — Mon, 06 Jul 2009 19:07:46 +0000

Previous to the final release of Ubuntu 9.04 there was a ton of buzz surrounding the new Boot Splash. Personally I don’t see what the big deal is. I am one of those weird people that likes to see the boot output, and have missed it since it was removed. It looks pretty, and I guess that is what they were going for. In any event, I haven’t bothered messing with it until it started conflicting with one of my boot-time applications. At that point I decided it needed to go.

As many of you may know I developed a management tool for Folding@Home clients called Origami. It simplifies the installation of Folding@Home clients and aims to be a set-and-forget kind of tool. The problem is that with the inception of the new Boot Splash the boot-time script for Origami fails. I don’t have any idea how the two of those would be related (if anyone can comment I am very curious), but I can confirm that disabling the splash “fixes” the boot-time issue with Origami. Here I’d like to quickly share now to disable the boot splash for anyone else interested.

Disable Boot Splash

First, for safely, you’ll want to make a backup of your original GRUB menu:

sudo cp /boot/grub/menu.lst /boot/grub/menu.lst.orig

Second, Edit the /boot/grub/menu.lst and remove any mention of ’splash’ found in the file. You should find one for each configured kernel as well as one slightly above that in the comments. The latter entry defines the default new-entry behavior, and if it is left in place it will re-add the splash to new entries.

Once this is removed you should see the boot output one you restart your machine again. Also, for those running Origami, this should fix any start-time problems until the real core of the issue can be resolved.

Startup Manager

If you’d like to really get in and tweak your boot-time parameters there is a nice GUI tool called Startup Manager. This tool allows you to do what we did above, just via mouse-clicks and a whole lot more. If you’re uncomfortable with the command line, or want to see what else you can do with your boot configuration, check out Startup Manager.

sudo aptitude install startupmanager

Other Points of Interest

March 14, 2009 — New Features In The Upcoming Ubuntu 9.04 “Jaunty” (10)
March 9, 2009 — New GDM Login Theme in Ubuntu 9.04 “Jaunty” (51)
November 18, 2008 — Hacking Perl (1)
November 12, 2008 — Origami 0.6.9 Released (0)
April 20, 2008 — Origami (previously folding.sh): Now In PPA! (8)
March 27, 2008 — Quick Poll Regarding folding.sh (0)

Many Thanks

Christer Edwards — Mon, 06 Jul 2009 16:02:23 +0000

I just wanted to thank everyone who commented or otherwise sent congratulations for the new baby. She really is a joy and I’m glad to see so many people from so many parts of the world sending notes. Thank you.

I am back into work this week so I may finally have some time to start doing some real blogging again. Fingers crossed ehh?

Other Points of Interest

No Related Post

Baby Announcement

Christer Edwards — Sun, 28 Jun 2009 02:46:36 +0000

We are very happy to announce the arrival of our second daughter, Elizabeth, today. She was born early this morning. 9lbs. 7oz (big baby!), 22″ long. She and mother are doing fine and resting.

Other Points of Interest

No Related Post

Create Anonymous Squid Proxy For Iranian Election Protestors

Christer Edwards — Thu, 18 Jun 2009 22:25:18 +0000

As I’m sure is the case with the rest of you (particularly if you use Twitter), I’ve been hearing more and more about the Iranian Election and the difficulties the people there are having in getting connectivity outside of the country. Without getting too detailed, it sounds like the incumbent president has cut off internet access to most major social networking sites. Sites that the protestors were trying to use to organize peaceful rallies and request recounts on the polls.

If you are interested in helping them fight to have their voices heard you can setup a Squid Proxy which will allow them to anonymously access Facebook, Twitter, YouTube and other such sites in order to organize and move forward. I have already personally setup and volunteered two proxies. The more that are available the better chance these people will have to continue to communicate with the outside world. If you would like to help out, please keep reading for instructions on how to setup a proxy and securely communicate the details to supporters inside Iran.

Note: please only configure and volunteer proxies for servers and internet connections that you own. Please do not run these on corporate or educational internet connections unless you have express permission.

Installing Squid

By following these instructions you should be able to have a Squid proxy available for use within just a few minutes. Even if you have setup Squid in the past, please make note of these customized instructions. The include access control restrictions to disallow Iranian government offices, and have logging disabled for anonymity.

To install squid use the command (or click on the link):

sudo aptitude install squid

Finding Your Public IP Address

You will need to document your public IP address for the configuration and for use by the protestors. You can find your public IP address by visiting the site: http://whatismyip.com. Make note of the address as you will need it for the configuration below.

Configuring Squid

We’ll now customize three things within the squid configuration.

Select a random port other than the default of 3128
Define access control list to allow Iranian subnets
Disable logging for anonymity of Iranian users

Open your squid configuration file, which is found in /etc/squid/squid.conf and search for the line “http_port 3128″. Change the port number to a different, random port. Do not use the following port numbers: 81/8080/8181/9090/3218. These are globally blocked within the country.

Next we’ll define the access control restrictions. What this will do is allow proxy access to the Iranian residential address ranges but not include the government offices. It will also block all other use of your proxy.

Search for the line beginning with “# INSERT YOUR OWN RULE(S)” and add the following on the next blank line:

acl TRUSTED src 62.60.128.0/17 62.193.0.0/19 62.220.96.0/19 77.36.128.0/17 77.77.64.0/18 77.104.64.0/18 77.237.64.0/19 77.237.160.0/19 77.245.224.0/20 78.38.0.0/15 78.109.192.0/20 78.110.112.0/20 78.111.0.0/20 78.154.32.0/19 78.157.32.0/19 78.158.160.0/19 79.127.0.0/17 79.132.192.0/19 79.170.144.0/21 79.175.128.0/18 80.66.176.0/20 80.69.240.0/20 80.71.112.0/20 80.75.0.0/20 80.191.0.0/16 80.242.0.0/20 80.253.128.0/20 80.253.144.0/20 81.12.0.0/17 81.28.32.0/20 81.28.48.0/20 81.31.160.0/20 81.31.176.0/20 81.90.144.0/20 81.91.128.0/20 81.91.144.0/20 82.99.192.0/18 82.115.0.0/19 83.147.192.0/18 84.47.192.0/18 84.241.0.0/18 85.9.64.0/18 85.15.0.0/18 85.133.128.0/17 85.185.0.0/16 85.198.0.0/18 86.109.32.0/19 87.107.0.0/16 87.247.160.0/19 87.248.128.0/19 89.144.128.0/18 89.165.0.0/17 89.221.80.0/20 89.235.64.0/18 91.98.0.0/15 91.184.64.0/19 91.186.192.0/19 91.206.122.0/23 91.208.165.0/24 91.209.242.0/24 91.212.16.0/24 91.212.19.0/24 91.212.252.0/24 92.42.48.0/21 92.50.0.0/18 92.61.176.0/20 92.62.176.0/20 92.242.192.0/19 93.110.0.0/16 93.190.24.0/21 94.74.128.0/18 94.101.128.0/20 94.101.176.0/20 94.101.240.0/20 94.139.160.0/19 94.182.0.0/15 94.184.0.0/17 94.232.168.0/21 94.241.128.0/18 95.38.0.0/16 95.80.128.0/18 95.81.64.0/18 95.82.0.0/18 95.82.64.0/18 95.130.56.0/21 95.130.240.0/21 188.34.0.0/16 188.93.64.0/21 188.121.96.0/19 188.121.128.0/19 188.136.128.0/17 188.158.0.0/15 193.189.122.0/23 194.225.0.0/16 195.146.32.0/19 212.16.64.0/19 212.33.192.0/19 212.50.224.0/19 212.80.0.0/19 212.95.128.0/19 212.120.192.0/19 213.176.0.0/19 213.176.32.0/19 213.176.64.0/18 213.195.0.0/18 213.207.192.0/18 213.217.32.0/19 213.233.160.0/19 217.11.16.0/20 217.24.144.0/20 217.25.48.0/20 217.64.144.0/20 217.66.192.0/20 217.66.208.0/20 217.146.208.0/20 217.172.96.0/19 217.174.16.0/20 217.218.0.0/15

http_access allow TRUSTED
http_access deny all

access_log none
cache_store_log none

visible_hostname

Once you have saved these changes run the following two commands to activate things:

sudo squid -z
sudo /etc/init.d/squid start

If you don’t see any errors you should be ready to go. You can now submit your public IP address and random port to the following email addresses for secure propagation within Iran.

me@austinheap.com and smallworldnews@gmail.com

I hope you are able to volunteer toward this cause. The stories that I have read and the videos and images I have seen show a real injustice is going on in that country. There are many young people who are trying to vote in a real Democratic election, yet their votes are being ignored and their voices are being silenced. If you believe that Freedom is something we all deserve, get involved.

You can find more information and inside updates here here and here.

Other Points of Interest

April 4, 2009 — Help Needed: Auto-Configure Proxy Settings via DHCP (13)

How To Share Your Internet Connection

Christer Edwards — Sat, 13 Jun 2009 23:32:38 +0000

Recently I asked for some user-contributed content for the site, and while I didn’t get the amount of feedback that I’d like, I did get one good suggestion that I knew I needed to pass on. How to share your internet connection. This tutorial outlines, in a very simple way, how to share your wired connection by creating an ad-hoc wireless broadcast. I imagine this would be great for LUG meetings and small gatherings where wireless is lacking but there is limited wired connectivity. Thanks to Aaron for the suggestion.

Requirements

In order to share your wired connection and create an ad-hoc wireless network you will need the following:

An active wired network connection
Functional wireless network device
Network Manager 0.7 or later
dnsmasq-base package installed

Installation and Configuration

The requirements above are pretty easy to come by. Network Manager 0.7 or later should be installed by default on any Ubuntu version past 8.10 (Intrepid, Jaunty and later). The dnsmasq-base package can be installed using the command (or clicking the link):

sudo aptitude install dnsmasq-base

At this point you should have all of your requirements met and we can move on to creating the ad-hoc wireless network.

Click on the Network Manager icon and select “Create New Wireless Network”.

You’ll be prompted to define a Network Name and optional Wireless Security Level. Once you define these values and activate you should be able to see a new SSID listed and begin sharing your connection. Enjoy!

Other Points of Interest

November 15, 2008 — How Many People Does It Take To Remove A Wireless Network From Windows Vista? (22)
June 19, 2008 — Extend Your Battery Life With Powertop (9)

Install Rockbox On Your Sansa Fuze

Christer Edwards — Fri, 12 Jun 2009 21:04:45 +0000

I came across a short how-to on the Ubuntu Forums today that I wanted to pass along. I don’t take credit for coming up with these steps. The credit belongs to user dragos240 of the Ubuntu Forums. I figure there have got to be a few of you that are interested in trying this out, or passing it along as well, so here it is.

Step 1: Disclaimer

Before you start following these steps be aware of the potential consequences. As outlined in the Ubuntu Forums tutorial:

DOING THIS WILL VOID YOUR WARRANTY AND HAS A POSSIBILITY TO PERMENENTLY BRICKING YOUR SANSA FUZE.

It may also be prudent to read through the entire thread at the Ubuntu Forums before you get started. This way you can avoid any surprises.

Step 2: Download

The author has put together a single archive with everything needed to update your Sansa Fuze to run Rockbox. This archive is available for download here. There is not a published MD5 on the Ubuntu Forums post, but this is what I got:

MD5 (Rockbox.tar) = 6a4fc70b13c00e5f35926125a64effe9

Step 3: Connect Sansa Fuze

The next step is to connect your Sansa Fuze via USB and make sure the mode is set to “MSC”.

Step 4: Copy the Archive

At this point you should be ready to copy the contents of the previously downloaded archive onto the root of your device. Make sure you get everything copied. You can press ctrl-h within Nautilus to view any hidden files, just to make sure.

Step 5: Unplug, Shut Off

Once everything is copied and you safely eject the device (right-click, eject), unplug it from the USB connection and turn it off. Give it a few seconds and then turn it back on again. This is the point where you cross your fingers, offer up any sacrifices and otherwise pray to whatever gods you believe in that everything worked.

Step 6: Enjoy Rockbox

If all went according to plan (and the Gods smiled upon you!) you should have Rockbox up and running when you turn the device back on. You’ll end up with a lot more features than you find in the default Sansa Fuze interface and, the best part, its good ‘ol Free Software.

I surely hope you don’t run into any problems, but if you do I would advise you to stop by the Ubuntu Forums and ask for help in the thread. It is only three days old at the time of this writing so it should still be pretty active. If you have anything to add or, more importantly, clear pictures of the finished product please share them here!

Other Points of Interest

No Related Post

Ubuntu 9.10 “Karmic Koala” Alpha 2 Released

Christer Edwards — Fri, 12 Jun 2009 15:52:03 +0000

For those of you that enjoy the bleeding edge and want to help test the next release of Ubuntu, the second Alpha release of 9.10 is now available. You should be warned that this release is not meant for the faint of heart or production machines. It will very likely break before it is done, leaving you with all kinds of interesting problems. On the other hand though, a little bleeding edge never killed anyone (plus, you learn a lot when things break).

Some of the upcoming features in Ubuntu 9.10 are:

GNOME 2.27.1
Linux Kernel 2.6.30
New Intel Video Architecture (testing)
New default compiler (GCC-4.4 vs GCC-4.3)
EXT4 filesystem by default (I’m excited about this one!)
Grub2 by default

If you’d like to help test this release you can find more information regarding known issues, download locations and how to report bugs here. Let the testing begin!

Other Points of Interest

April 18, 2008 — Updating Ubuntu Images With Jigdo (5)

Firewall Builder: Using The Policy Importer

Christer Edwards — Fri, 12 Jun 2009 10:01:15 +0000

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 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 ” or “-o ” 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)