Using Firewall Builder Settings to Manage Firewalls

Last week we looked at managing rules in Firewall Builder. In the last installment of our series on Firewall Builder, I'll take a look at managing firewall settings with the Firewall Builder.

We've covered quite a bit already about Firewall Builder This week, I want to open up the Firewall Settings window to illustrate how much further a Firewall can be flexed, stretched, and configured — all from a single, user-friendly window.

As should be expected, getting to the settings window is simple — so long as it's not overlooked. What I'm talking about is not the Firewall Builder Preferences. The settings I am referring to actually apply to individual firewalls. So, in order to reach the settings window, a firewall must be open within Firewall Builder. Once the firewall is open (double click on the firewall to edit it),

When the Firewall Settings button is clicked, it will open the settings window only for the currently open firewall.

The Firewall Settings button is located near the center of the window. Click that button to get to the settings in question. Let's examine this window, tab by tab.

The compiler tab (see Figure 2), as the name implies, deals with the compiling settings for the firewall. There are a few options, in particular, that I want to point out. The first option is 'Assume firewall is part of "any"'. If this option is checked, rules that are configured with "Any" in the Source or Destination fields will also generate rules for traffic destined to or from the firewall. In iptables this will result in a rule being added to either the OUTPUT or INPUT rule chain.

The configuration options here will be automatically compiled into the firewall in question.

Another important option is 'Always permit ssh access from the management workstation with this address'. This helps prevent situations where a user cuts off their access to the firewall because there isn't a rule allowing SSH access to the firewall itself. If this option is enabled, enter either a single IP address or a network using CIDR notation (e.g. 192.168.1.0/24). When the firewall is compiled, Firewall Builder will automatically add a rule permitting SSH access to the firewall from this IP address or network at the top of the generated rules.

The Installer Tab has three settings that you should pay close attention to. The first is the option "Directory on the firewall where script should be installed". This should match a directory that exists on the firewall where the firewall script should be run. Typically for iptables firewalls the directory is either /etc/ or /etc/fw (if this directory has been created on the firewall).

The second setting to pay attention to is the username. This is the username that will be used when Firewall Builder connects to the firewall to install the generated firewall script. If the username configured in the installer tab does not have administrative rights, the installation will fail. So in this section, enter a username that does have admin rights and can actually install firewall rules (if the user can use the iptables command, that user most likely has rights enough.) If the username setting is left blank the user will be prompted to enter the username when they run the install wizard.

Finally, in the installation tab, there is the additional command line parameters for both ssh and scp options. This is an incredibly helpful should ssh and/or scp use alternative ports. Should that be the case, simply add something like -p 2222 to instruct ssh to use non-standard port 2222 (instead of standard port 22).

The next tab that should be of use is the Prolog/Epilog. This tab allows for the addition of script commands in bash format to be added either to the beginning or to the end of a firewall script. For example, the amount of traffic being served up by an HTTP server can be controlled by using the Traffic Control command (tc). The commands would need to be added to the epilog (end) of the firewall as shown in Figure 3.

 

Prolog scripts can be added in three different locations, whereas Epilog scripts can only be added to the end. Make sure that the commands entered can be run as a bash shell script without any errors.

Finally, the Script Tab offers a number of setting options, of which there are four settings to pay close attention to. It is important to note that this tab directly effects the script generated for the firewall being configured and not the machine that Firewall Builder is running on. The first is "Configure Interfaces of the firewall machine." If this option is not checked the script generated will not include shell code necessary to manage IP Addresses. By default this is on.

The next option in the Script tab is for VLAN interfaces. If the checkbox for "Configure VLAN interfaces" is checked the script generated by Firewall Builder can create and remove VLAN interfaces for the firewall. If left unchecked, this feature will not be available. In other words, if VLAN interfaces are necessary, make sure this check box is checked. This same option is available for bridged interfaces. If the firewall to be installed needs to configure any bridge interfaces, the check box for "Configure bridged interfaces" must be checked, otherwise bridged interfaces will not be available to the firewall machine.

Finally, "Use iptables-restore to activate policy" is the last option I will deal with. There are two ways in which generated scripts can be loaded:

Using iptables command: This command will load the rules of a firewall one at a time.Using iptables-restore: This command will activate the rules of the firewall all at once.

The biggest difference between the two methods, with regard to Firewall Builder, is that the iptables-restore is a much faster process. This can make a significant difference when the firewall becomes longer and more complicated. If, on the other hand, a firewall is short and basic, the standard method of running iptables commands line-by-line will work just fine.

I have only scratched the surface of the Firewall Builder Firewall's Settings window. Although I have touched on many of the more important options, it would behoove you to comb through all of the tabs to make sure there aren't options available that would make a difference in a particular firewall. But the settings options illustrated here are those that most users will want to at least examine for their firewall rules, before they are compiled and installed.

View the original article here

Using Firewall Builder Objects for Linux Firewalls

Firewall Builder is one of the most powerful and user-friendly firewall creation utilities available for Linux. One of the many reasons Firewall Builder is both powerful and easy to use is its objects feature. Objects are reusable elements that can be added and removed from firewall rules by dragging and dropping the object into firewall rules. Firewall Builder comes with plenty of pre-defined objects that can be used right away, and also makes for easy creation of new objects.

Objects are so crucial to the ease of use and understanding of Firewall Builder, I want to dedicate this entire article to the creation, editing, and use of objects. With a sound understanding of objects under the belt, any one should be able to create secure and flexible firewalls to fit nearly any need.

Firewall Builder stores objects in what are known as Libraries. By default Firewall Builder includes two Libraries.

Standard: The predefined objects that can be dragged and dropped into firewalls. These objects can not be edited.User: An empty pre-categorized library where users can add their own objects and then drag and drop them into firewalls.

To select a library, click on the Library drop-down (see Figure 1) and select either the Standard Library or the User Library. Let's say, for example, the firewall being created will be used to secure an HTTP server. Why bother creating TCP/UDP service objects when they already exist in the Standard Library? Simply open up the Standard Library (click the Library drop-down and click Standard), expand the Services entry, Expand the TCP entry, and the HTTP and HTTPS entries will be available. Drag and drop all of the related entries necessary for the new firewall into the desired rules for the firewall.

Another way to find the object is to use the convenient filter feature, located just below the Library drop down, that lets you quickly filter the objects in the tree to find what you are looking for.

 

It is also possible to create a Custom Library by clicking the drop-down to the left of the Libraries drop-down and selecting New Library.

In my previous article I discussed how to create objects specific to firewall used for SSH connections into a host. The methods discussed in that article describe the creation of objects for the User Library. One of the nice features of Firewall Builder is that those objects can be then reused in other firewalls. So even if the objects were initially created for the SSH firewall, they can then be re-purposed for a firewall focused on a Web server. That doesn't just apply to services; any of the objects created in a previous firewall can be re-used over and over.

Don't think objects are limited to services or addresses. In fact quite a few object types can be created and used, and here is a listing of the types:

Address Ranges: A range of addresses can be configured into a single object.Address Tables: This is an address-based object that can be created when a range of addresses is needed but the actual addresses are not known when the firewall or policy is being written. The Address Tables object has an added feature which allows for the object to be loaded at either compile time (during firewall compilation) or during run time (when Firewall Builder runs the firewall script). More on this in a moment.Addresses: A single address that can be used for an interface, source, or destination (such as a host).DNS Names: This object represents a DNS "A" or "AAAA" name and resolves to an IP address during either compile or run time. What this highlights is the intelligence of the compiler and its ability to resolve addresses to names during compilation.Groups: A group is a container that holds references to multiple objects of the same or similar type (Addresses, Address Ranges, Network Objects).Hosts: A host object represents hosts on a network: Desktops, Workstations, and any other network node that has a network address.Networks: This object describes an IP network or an entire subnet.

A group is a container that holds references to multiple objects of the same or similar type (Addresses, Address Ranges, Network Objects). When a new group is created (see Figure 2) the member objects can either be created from within the configuration of the group itself (click the "Create new object and add to this group" drop-down) or objects can be dragged and dropped into the group from one of the Libraries. During compile time the Firewall Builder compiler will determine if a group should be expanded and multiple chains needed or if a single chain can take care of the group.

 

Make sure the name given to the group adequately describes the purpose of the group so that group can be re-used without having to examine its contents.

Address Tables are incredibly handy. Essentially this object allows you to define a list of addresses and/or networks into a rule, even if the actual addresses are unknown at the time the rule is created. What must be done, however, is (when the addresses are known) a file is created that will house the addresses. That file name and location is configured into the Address Tables setup (see Figure 3).

To configure the file the addresses will be read from click the Choose File button and then navigate to file.

When you have configured the Address Table to be aware of the file containing the addresses, it is also possible to directly edit the file from within Firewall Builder. To do this click the Edit File button and the Firewall Builder Script Editor will open (see Figure 4).

Figure 4
fwbuilder_script_editor.png

You can create a file using the script editor, just enter the full path to the file and click Edit. The file will be created when you click Save.

The services objects are all fairly self-explanatory (Custom, Groups, ICMP, IP, TCP, UDP, Users). The only Service that may need explanation is the TagServices. The TagServices object allows packets to be tagged by one rule and then acted on by another rule. Packet tagging is fairly complex. Essentially a TagServices object is created and configured with either a tag number or string. To match a tag in a rule just drag and drop the service object to the Service column of the rule. To create a rule that sets the tag, set the Action to Tag and drag and drop the TagService to the bottom of the screen where it says "Drop object here."

It is also important to know that TCP and UDP Services can have definitions for both source and destination ports configured and that if a configuration of 0 is used all ports will be matched. Say, for example, it is necessary to create a service for HTTP using port 8080 as the destination, but a specific source port is not necessary. To do this enter 8080 as the destination port and leave the source port as is (set at 0).

A handy trick to know is how to locate where a service is being used within a firewall. With a firewall open, navigate to a service (either from the Standard or User Library) and right-click the service. When the context menu opens select Where Used. A pane will open in the lower half of the Firewall Builder window (see Figure 5) that will, upon clicking the Find button, display where the service is used within the firewall. This is especially handy when trying to troubleshoot a particular firewall.

 

If any child services were created from the original, make sure to search for those as well.

The creation and manipulation of objects serves as the foundation and building blocks which all firewalls are created within Firewall Builder. Because objects make the creation of firewalls more efficient and user friendly, it is important to understand how they can be best utilized. When used correctly, Firewall Builder objects help to make the administration of firewalls a far easier task.

View the original article here

Importing iptables Configurations Into Firewall Builder

Firewall Builder is a firewall configuration and management GUI that supports configuring a wide range of firewalls from a single application. Supported firewalls include Linux iptables, BSD pf, Cisco ASA/PIX, Cisco router access lists and many more. The complete list of supported platforms along with downloadable binary packages and soure code can be found at http://www.fwbuilder.org.

Import of existing iptables configurations was greatly improved in the recently released Firewall Builder V4.2. Features like object de-duplication and expanded rules recognition make it even easier to get started using Firewall Builder to manage your iptables configurations.

For this tutorial we are going to import a very basic iptables configuration from a firewall that matches the diagram shown below.

 Firewall Builder imports iptables configs 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 the 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 Firewall Builder, run the script to save the configuration to a file:

iptables-save > linux-1.conf

As you can see in the output below, the example linux-1.conf iptables configuration is very simple with only a few filter rules and one nat rule.

# Completed on Mon Apr 11 21:23:33 2011
# Generated by iptables-save v1.4.4 on Mon Apr 11 21:23:33 2011
*filter
:INPUT DROP [145:17050]
:FORWARD DROP [0:0]
:OUTPUT DROP [1724:72408]
:LOGDROP - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth1 -s 10.10.10.0/24 -d 10.10.10.1/32 -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -s 10.10.10.0/24 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A FORWARD -o eth0 -s 10.10.10.0/24 -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A FORWARD -j LOGDROP
-A LOGDROP -j LOG
-A LOGDROP -j DROP
COMMIT
# Completed on Mon Apr 11 21:23:33 2011
# Generated by iptables-save v1.4.4 on Mon Apr 11 21:23:33 2011
*nat
:PREROUTING ACCEPT [165114:22904965]
:OUTPUT ACCEPT [20:1160]
:POSTROUTING ACCEPT [20:1160]
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Apr 11 21:23:33 2011

If you are running Firewall Builder on a different system than the one that is running iptables copy the file linux-1.conf from the firewall to the system where Firewall Builder is running.

Launch the Import wizard by selecting the File -> Import Firewall menu item.

Click Browse to find the file named linux-1.conf.

Click the Continue button to move to the next step of the import process.

The next window shows a preview of the configuration file that will be imported and the type of firewall that Firewall Builder has detected it to be.

Next you need to enter a name for the firewall. This is the name that will be used in Firewall Builder to refer to the firewall after it is imported. When you click the Commit button the configuration data will be read.

By default, Firewall Builder attempts to detect if there are items, like IP addresses, used in the rules that match existing items in the object tree. If there is a match the existing item is used, if there is no match a new object is created. This feature can be disabled by unchecking the box next to "Find and use existing objects" which will result in objects being created for evry item used in the imported rules regardless of whether it already exists in the object tree or not.

After the import is complete, Firewall Builder displays a log showing all the actions that were taken during the import. Warning messages are displayed in blue font and error messages are displayed in red.

The program tries to interpret the configuration file rule by rule and recreates the equivalent rule in Firewall Builder. Note that rules imported into Firewall Builder may not always be optimized since features like defining multiple source and/or destinations are supported by Firewall Builder, but not by iptables.

The progress window displays warning and error messages, if any, as well as some diagnostics that shows network and service objects created in the process.

As you can see from the import process log, Firewall Builder detected that there are rules in the iptables configuration that allow RELATED and ESTABLISHED traffic through the firewall. This behavior can be controlled by a setting in Firewall Builder, so a warning message is shown.

Click the Done button to complete the firewall import. Next we will go through some common post-import actions.

Importing iptables Configurations Into Firewall Builder - Page 2

View the original article here