netfilter Operation: Part Fourteen (Firewall Builder, conclusion)

Firewall Builder

Adding inbound and outbound NAT rules in Firewall Builder.

As you can probably see, once you have completed the up-front work of defining your objects, adding or modifying rules is simple. Additionally, unlike the other free GUI solutions, Firewall Builder allows you to centrally and securely administer all of your (supported) firewalls from one location.

Notice that the default chains have rules matching the rule you configured in Firewall Builder, with a target of RULE_<RULE_NUMBER>. These additional chains are used to configure the logging. there s also a rule at the beginning of all chains to ACCEPT traffic related to an established session. This is generally desirable but is still configurable. To remote this automatically generated rule, select the firewall in the object tree and click on Firewall Settings in the dialog area. There is a checkbox that is selected by default called “Accept ESTABLISHED and RELATED packets before the first rule.” Although the Firewall Builder policies you’ve configured can handle any basic rules you might need, there are still a few more issues to cover. If you need to NAT with your Linux firewall, configuring it with Firewall Builder is easy. Follow these steps so that your firewall with NAT all the traffic from the internal network to the DHCP address used on the outside interface. This configuration is also known as source.nat because it is the source address that is being changed.

  1. In the Object Tree, select NAT.
  2. Move your mouse to the pane to the right of the Object Tree, right-click and select Insert Rule.
  3. Drag your INTERNAL network object from the object tree to the Original Src column in the new NAT policy.
  4. Drag the external interface on the firewall from the object tree to the “Translated Source” column in the NAT policy.


Now, save, compile and install the new policy. Now traffic originating from the internal network will be NAT-ed to the IP on the external interface. Although this source NAT configuration will allow all your internal users to reach the internet, you will need to use destination NAT if Internet users need to reach an internal server. Because the internal server is using a private IP address (which is not routable on the Internet), you need to translate this destination to an IP address that the external users can reach. To configure packets destined for the firewall’s single public IP address to an inside resource using destination NAT, follow these steps:

  1. In the Object Tree, select NAT.
  2. Right-click on rule number zero of the existing NAT ule and select Add rule at Bottom.
  3. Drag the firewall OUTSIDE interface into the Original Destination column of the new rule.
  4. Drag the appropriate services (HTTP and HTTPS) into the Original Service column of the new rule.
  5. Drag the internal server into the translated destination column of the new rule.

Firewall Builder: Creating a Time Policy

Firewall Builder

Creating a time policy with Firewall Builder.

Another nice feature is being able to create a time policy. In this example, we’ll alter the rules so the internal systems can only surf the web from noon to 1:00 PM:

  1. In the Object Tree, right-click Time, and select New Time Interval.
  2. In the “Name” field, we’ll call this rule LUNCH.
  3. In the two time fields provided, enter a time for the rule to START and a time for the rule to STOP. In this case we will enter 12:00 and 13;00 and leave the date field as zeros. You can check off every day of the week at the below the time fields, so the time interval applies to all days. When done, click Apply.
  4. Drag the LUNCH time interval from the Object Tree to te Time column of rule #1.

Now, rule #1 (which permits outbound web surfing) will only be active from noon to 1:00 PM. The ability to configure the rules to be active based on the time of day is a very powerful feature. If the organization is a strictly 8 AM to 5 PM type of place, you could configure the firewall to disable all access during non-business hours. Alternatively, certain non-business-related protocols could be enabled after the normal business day ends.


External Links:

The official Firewall Builder site

netfilter Operation: Part Thirteen (Firewall Builder, continued)

Firewall Builder

Adding inbound and outbound rules for the web server in Firewall Builder.

In the last article, we discussed the process of setting up a firewall object in Firewall Builder and adding a network to it, as well as adding a web server to the network. This seems like a lot of additional effort; however, the real advantage of an object-oriented approach is seen when it comes time to configure the rules. With all of the appropriate objects in place, let’s define the rules to permit the inbound HTTP traffic.

  1. Create a new rule by either navigating to Rules -> Insert New Rule from the menu at the top of the window, or click on the large plus (+) beneath the top menu.
  2. Allow inbound HTTP to WEB1. Click on WEB1 in the object tree and drag it to the destination cell for rule 0.
  3. Now drag the HTTP and HTTPS service from the object pane to the Service cell in rule 0.
  4. Right-click the big red dot in the Action column and select Accept. This allows the inbound Web traffic to access WEB1.
  5. To allow outbound Internet access. create another rule by either navigating to Rules -> Insert New Rule or by clicking on the big plus (+) beneath the menu.
  6. Drag and drop HTTP and HTTPS from the object tree into the Service column of rule one.
  7. Drag the Network object INTERNAL from the object tree to the Source column of the new rule.
  8. Right-click on the Action column for rule 1 and change the action to ACCEPT.
  9. Although our rules seem simple at the moment, let’s apply them to see show things work. First, save your work by navigating to File -> Save or File -> Save As.
  10. Next, right-click the OFFICE01 Firewall and select Compile.
  11. When the “Select Firewalls for compilation” window comes up, OFFICE01 should be checked. When satisfied with your selection, click Next. When the compilation is complete you should see “Success” in the “Progress” column. After verifying that the compilation was successful, click Finish.


Compiling and Uploading the Firewall Rules

Firewall Builder

Compiling the firewall rules.

The next step is to tell Firewall Builder where to find the SSH executables, because this is how Firewall Builder uploads the configuration to the firewalls. You need to have SSH working on both the firewall and the Firewall Builder console, assuming they are on different systems.

  1. Select Edit -> Preferences from the menu.
  2. Select the Installer tab and click the Browse button.
  3. Navigate to the location of your desired SSH utility and click Open. Note that if you are using Windows for the Firewall Builder host, you cannot select PUTTY.EXE; you must use the command-line PuTTY program PLINK.EXE. In Linux, you can leave the default setting (ssh).
  4. After selecting the SSH executable, click OK.
  5. Right-click the OFFICE01 firewall in the object tree, and select Install.
  6. Select the firewalls you wish to install, and click Next.
  7. Enter the username and password for the SSH connection.
  8. All other fields are optional; however, it is recommended that you check “Store a copy of the fwb on the firewall.” When satisfied with your choices, click Ok.

After the upload completes, you will get a status of “Success”. Checking your firewall (iptables -L) shows you the new rules that are listed.

One point that should be made is that you have to be careful when configuring the rules. It is always a good idea to creat the rules to permit administrative access before any others. This is because as soon as you configure the default policies to DROP, your SSH connection will no longer be permitted unless you have it added to the access list. And if you forget to do this, you could find that you no longer have remote access to your firewall after applying the policy. If that happens, you won’t even be able to remotely connect to update the policy and change the ACLs.


External Links:

The official Firewall Builder site

netfilter Operation: Part Twelve (Firewall Builder continued)

Firewall Builder

Firewall Builder on startup.

NOTE: After I posted this article, I found out it’s possible to add objects/networks/hosts/etc. by right-clicking items on the object tree under the Linux version of Firewall Builder. This article has been amended accordingly.

In the previous article, I introduced Firewall Builder, including some notes on installation under Windows and Linux. In this article, I will step through the process of adding a firewall object and configuring it.

Firewall Builder: Creating a Firewall Object

In this example, I installed Firewall Builder under Linux Mint. Initially, there are three main options in the main dialog area: “Create New Firewall“, “Import Existing Configuration“, and “Watch ‘Getting Started’ Tutorial“. click on “Create New Firewall“, which will open the New Firewall dialog box.

Firewall Builder

The New Firewall dialog box.

In the New Firewall dialog box, enter the name for the new firewall (in this case OFFICE01). For the firewall software, select iptables from the dropdown box. For the OS, choose Linux 2.4/2.6 and click Next. The next window allows you to configure the interfaces on the firewall. You can do it manually, or if the firewall is running SNMP, you can discover them via SNMP. Here, we select Configure interfaces manually and click Next. This will bring up the manual configuration window. Enter the relevant information for each network interface. The name must correspond to the actual interface name (which is the same as if you had entered ifconfig on the Linux host), such as eth0. The Label is a human friendly name for easy reference such as OUTSIDE. When you are done entering the information for a given interface click Add. When you have entered the information for all interfaces (typically at least an INSIDE and OUTSIDE), click Finish. You must designate one of the interfaces on the firewall as the management interface, typically the INSIDE interface. Do this by navigating to the firewall in the object tree. As you select each interface in the object tree, there is a “Management interface” checkbox in the dialog area. Check this box for the interface you want to use. This will be the interface that Firewall Builder uses to connect and upload the firewall rules to.


Firewall Builder: Adding a Network

Firewall Builder

The button for adding new networks/hosts/services/etc is in the upper left, adjacent to the back arrow button.

Now that you have the basic firewall defined, you need to define something for it to talk to. In this case, we will assume that 192.168.1.0/24 is you internal network, and you want to allow outbound Web browsing and access to an internal Web server (WEB1). For starters, you need to create an object to represent the internal network. Follow these steps to create the network object:

  1. Navigate to Objects -> Networks in the object tree ((in order to make the object tree visible, you may have to go to the View menu and unselect Editor Panel).
  2. Right-click Networks and select New Network.
  3. Enter INTERNAL for the name of the network, and use 192.168.1.0 for the Address field. Enter 255.255.255.0 for the Netmask.
  4. Next, we’ll create an internal Web server at 192.168.1.2.  Right-click Objects -> Hosts in the object tree and select New Host.
  5. Enter WEB1 for the name of the object. Click the Use preconfigured template host objects check box and click Next.
  6. Select PC with one interface and click Finish.
  7. Expand the object tree to User -> Objects -> Hosts -> WEB1 -> eth0 -> WEB1. Edit the IP address to be 192.168.1.2 and click Apply.
  8. Next, define the appropriate services to allow Web-browsing. Navigate in the object tree to Services -> TCP, right-click on it, and select New Service.
  9. Enter HTTP for the name. Leave the source port ranges at zero, but change the destination port range to start and end at 80.
  10. Repeat the previous two steps for HTTPS on port 443 for secure Web pages.

Now that we have created the network object, in the next article, we will cover defining the firewall rules to allow inbound web traffic and uploading the rules to the firewall.


External Links:

The official Firewall Builder web site

Using Firewall Builder on Linux to Create Firewalls from Scratch on linux.com

Firewall Builder Tutorial: The Basics on YouTube

netfilter Operation: Part Eleven (Easy Firewall Generator and Firewall Builder)

Easy Firewall Generator

Easy Firewall Generator in action.

Easy Firewall Generator

Easy Firewall Generator is not a GUI per se, but it does help simplify your netfilter configuration and avoid the need to be familiar with the iptables syntax. By using the Web page at http://easyfwgen.morizot.net/gen/index.php, you can enter the relevant information and click the Generate Firewall button. As you select options, if additional information is needed click the Generate Firewall button and the page will refresh and provide the additional input fields. When all of the required information has been entered, the page will change to a text page that can be copied and pasted for iptables to read as a saved configuration. In Fedora, the iptables configuration is stored in /etc/sysconfig/iptables. Although this method requires you to replace the default iptables configuration file used by your distribution, it is fairly painless, and supportes all of the same basic functionality as Firestarter.


Firewall Builder

Firewall Builder is the most complete GUI offering for managing netfilter firewalls with features and capabilities comparable to some commercial firewall products. As is almost always the case, this functionality and capability come at a price: as far as netfilter GUIs are concerned, Firewall Builder is not the easiest to configure and use. If you want or need its superior management capabilities, however, the extra effort is well worth it. (Download firewall builder from www.fwbuilder.org). Firewall Builder manages netfilter firewall as well as ipfilter, OpenBSD PF, and Cisco PIX firewalls. Firewall builder runs on many popular operating systems including Red Hat, Mandrake, Suse, FreeBSD, Mac OS X, and Windows XP/Vista/7/8.

Firewall Builder

Firewall Builder 5.1 on startup under Windows.

Firewall Builder operates differently than all of the GUIs covered so far. It uses an object-based approach. Essentially, you must define an object to represent any entity that you want to use in the firewall rules. In most cases this means a source, a destination, and a service port at a minimum. Both the configuration and the GUI bear a strong resemblance so that of the Checkpoint Firewall GUI. Once the objects are defined, you can drag or drop them into the rules in order to permit or deny communications between the two.

As of this writing, the current version of Firewall Builder is 5.1. Under Windows, navigating to Start -> Programs -> Firewall Builder 5.1 -> FWBuilder, which opens the main Firewall Builder window. Firewall Builder can also easily be installed under Linux. Under Linux Mint, I was able to install Firewall Builder using the apt-get command, like so:

sudo apt-get install fwbuilder

Once fwbuilder is installed, it can be accessed by clicking on the start menu, then navigating to Internet -> Firewall Builder, which will bring up the main Firewall Builder window.

In the next article, we will cover how to configure firewall rules in Firewall Builder.]


External Links:

The official Firewall Builder website

Getting Started With Firewall Builder at howtoforge.com

netfilter Operation: Part Ten (Firestarter)

Firestarter

The Firestarter GUI in action.

Firestarter is a GUI front end for netfilter and iptables, and its goal is to make it simple for the average user to configure their firewall and protect themselves. Firestarter runs on many Linux distributions and the installation is supported by many automated package management systems (such as yum, apt-get and portage). Firestarter is an excellent choice if your needs are relatively simple for your firewall configuration. To install it manually, download it from www.fs-security.com/download.php. Once it is installed, the first time you start the GUI interface you will need to perform some initial configuration. Follow these steps to configure Firestarter:

  1. Start the Firestarter GUI. In Fedora, this is done by navigating to Applications -> System Tools -> Firestarter. This will start the Firewall wizard. Click Forward on the Welcome to Firestarter screen.
  2. On the next screen, select your Internet-connected network device from the “Detected device(s):” dropdown box, and place a checkbox in the “IP address is assigned via DHCP” box. When you are done, click Forward.
  3. The next screen is the “Internet connection sharing setup” screen, which is basically where you enable NAT. If you want to NAT all of the outbound packets to the external IP address, place a check in the “enable internet connection sharing” checkbox. When this checkbox is enabled, you can select the local area network device. If you only have two interfaces, it should be selected by default. When finished, press Forward.
  4. On the final screen, leave the “Start firewall now” box checked and click Save. This will install a service to start Firestarter each time the system boots up. Firestarter will also change the default action for the chains to DENY; therefore, you must explicitly configure any ports you want to permit through the firewall.

The Firestarter GUI is fairly straightforward. The Status tab gives you high-level information such as sent and received data counters per interface and a list of active connections. By clicking the Stop Firewall button, all of the iptables chains are flushed and the default action is changed to ACCEPT. This can be useful for troubleshooting issues to see if they are related to your firewall configuration.

The “Events” tab lists recent blocked connection attempts. The “Policy” tab is where you configure certain rules to permit desired traffic.


For example, if there was a Web server running on the Linux host, you could use the “Policy” tab to permit inbound connection to TCP port 80. The “Editing” dropdown box allows you to choose between inbound and outbound rules to edit. For the Web server example, we selected “Inbound traffic policy“. The policy group you select when you click “Add Rule” determines where the policy is placed. Here are the functions of the various policy groups:

  1. Allow Connections From Host: This is used to configure a given IP address, hostname, or network. When you enter the IP information and create a rule in this policy group, all traffic from the configured source is permitted.
  2. Allow Service: The allow service policy group is used to permit individual services. You can configure the source to be anyone including a specific IP, or network, or all local area network (LAN) clients. The LAN clients option permits the service through the firewall with a source address that is on the same subnet as the inside network adapter.
  3. Forward Service: This option is used only when you are NATing. This allows the firewall to forward a specific port or range of ports, so that a service hosted on an internal NAT-ed device can receive inbound connections from the external network.

The “Outbound traffic policy” window shows a different set of policy groups. There are also the additional radio buttons to select “Permissive by default“, “blacklist traffic“, or “Restrictive by default“, “whitelist traffic“. If you select the restrictive configuration, the default target for the table is DENY, and any rules you create will be PERMIT rules.

The function of the different policy groups toggle between “allow” and “deny” based on whether you select restrictive or permissive mode. The policy groups are outlined here:

  1. Allow/Deny Connections to Host: This policy group is used to globally permit or deny outbound access to a given host, IP address, or network range. This policy uses the destination to match the rule. You can use this policy group in permissive mode to list certain Web sites you do not want anyone to have access to.
  2. Allow/Deny Connection from LAN Host: This policy group is used to permit or deny all access from a particular host, IP address or network range. This policy uses the source to match the rule.
  3. Allow/Deny Service: This policy group permits or denies traffic based on its destination port and source. When you are using permissive mode, this policy group can be used to block all access to the bittorrent ports. The traffic source can be anyone: the firewall itself, LAN clients, or an arbitrary IP, hostname or network range.

Configuring the policies will satisfy the bulk of what you need to accomplish, but there are some additional configuration options available by navigating to Edit -> Preferences. Selecting Interface -> Events allows you to configure some useful options. The “Skip redundant entries’ checkbox only makes one event entry for sequential event entries. This helps prevent the event windows from being flooded by repetitive alerts. You also have the option of entering certain hosts or ports as being exempt from triggering the vent log. After making your selections, click Accept.

Another preferences setting of note is under Firewall -> Network Settings. This allows you to enable Internet connection sharing (the same as during the initial wizard), and enable the firewall host as a Dynamic Host Configuration Protocol (DHCP) server. This allows you to configure the Linux host similarly to a home firewall, which generally acts as a DHCP server in addition to performing NAT and acting as a firewall. The ICMP filtering window also allows you to filter ICMP packets. By default, the permit and deny rules configured by Firestarter apply to TCP and UDP, but not ICMP. This screen allows you to permit the desired types of ICMP traffic. Generally speaking, it is better not to allow any ICMP from the Internet to your firewall or internal network unless absolutely necessary.

One final setting you want to configure is under Firewall -> Advanced Options. In the broadcast traffic section, check both options under Broadcast traffic. In general, you should not permit broadcast traffic to go through your firewall, as doing so poses a security risk. You also want to check the option to “Block traffic from reserved addresses on public interfaces,” which is a common filtering tactic. Because the “private” addresses outlined in RFC 1918 should not be routed through the Internet, there is never a reason to receive traffic sourced from any of those addresses on your outside interface. If you do, it is almost always a hacker attempting to bypass a poorly configured firewall.

Short of any advanced packet mangling, there isn’t much you cannot accomplish using Firestarter as your configuration tool. If you need to implement a more advanced configuration, you could use an alternate tool, or generate the configuration using Firestarter and use those chains as a starting point to add your own more advanced options.


External Links:

The official Firestarter web site

Configuring firewalls with Firestarter at Tech Republic

Firestarter – A High-Level Graphical Interface Iptables Firewall for Linux Systems at tecmint.com

Install the Firestarter Firewall on Ubuntu Linux at howtogeek.com

netfilter Operation: Part Nine (Lokkit)

Lokkit

Lokkit in action under Ubuntu.

Using Lokkit

Lokkit is an ncurses-based menu for configuring your netfilter firewall that is part of the GNOME desktop. Lokkit is available for most major distributions and can be installed by default on some (such as Fedora). It asks a small number of simple questions and writes a firewall rule set for you. To start Lokkit, type lokkit in a terminal window. [If you don’t have lokkit, you can install it from the repos using the apt-get command: sudo apt-get install lokkit]. If you want to review the firewall settings without running the firewall, type:

sudo lokkit -n

To see what services/ports can be managed/opened using lokkit, type:

sudo lokkit –list-services

You can navigate the menus using the Tab key and the space bar to toggle the equivalent of radio buttons, such as the Enable and Disabled options shown here. If you select Enabled on this screen, the default ruleset is applied. To edit any custom settings, press Tab until the Customize button is highlighted and then press Enter.


Lokkit does provide a little more flexibility than the Security Level configuration GUI discussed previously; however, it is still limited. By selecting an interface in Trusted Devices, all traffic from that interface will be permitted. This would typically be used to select the inside interface and designate it as trusted. You do have the option of enabling MASQUERADE. The interface you select is the one that will NAT outbound traffic; therefore, you would generally select your external interface. Some pre-defined services are available, and you can enter your own service information in the “Other ports” section. Once you are satisfied with your choices, press OK and then Enter. This will take you back to the main screen, where you press OK and then Enter to apply the changes.

If you attempt to configure an interface for MASQUERADE, it must also be marked as trusted or Lokkit will generate an error, Bear in mind that although MASQUERADE is limited, it has enough flexibility to configure a firewall similar to a typical home firewall/router device. This makes Lokkit a handy little utility to have in your repertoire should you need to configure a simple firewall quickly. The value of this utility is also increased, because it is available for a wide number of Linux distributions.


External Links:

Lock it down quickly with Lokkit at techrepublc.com

Linux Firewall – The Second Line of Defense at Linuxtopia

netfilter Operation: Part Six

netfilter operationIn the previous article, we began the process of simulating a home router with netfilter. We will continue that process in this article.

We began with the these iptables commands:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
 iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

The INPUT chain allows port 80 to go to the firewall itself from the internal network. Many of the home routers have a Web interface for configuring them, and while your configuration may not need this port open to the firewall, it is included here to help emphasize how the different chains are used. It is important to specify the input interface (using -i) so that the source IP cannot be spoofed by an external attacker. In this way, you ensure that even if a packet was generated with the proper source IP, if it came in on the outside interface (eth1) it would not match the rule and would thus not be permitted. The FORWARD rule allows any outbound traffic from the internal network to the external network. This configuration is simple to implement; however, the 192.168.1.0 IP range is a private IP range and is not routable on the Internet. Thus, this range would not allow traffic from the internal network to the Internet quite yet. To make this Linux firewall a useful replacement for a home network router, you need to enable NAT, which allows all of the systems on your internal network to appear as a single IP address when communicating on the Internet.

Enabling NAT

In principle NAT is simple, but in a complex environment it can get confusing. Basically, NAT means that the NAT device (in this case the Linux netfilter firewall) will change the IP address in apacket and retransmit that packet. Depending on your needs, you can alter the source IP address (source NAT, or SNAT), the destination IP address (destination NAT, DNAT), or both (double NAT). With a home router, the objective behind the NAT capability is to allow all of the internal hosts to communicate on the Internet using the single public IP provided by your Internet Service Provider (ISP). (In this case, SNAT is being used). As each of the hosts on your private network make a connection to an Internet server, the firewall is altering the source address to look like the public IP from your ISP. By doing this, the return traffic can find its way back to the firewall and be retranslated and sent to the originating host.


In this example, assume that the internal host has a private IP address of 192.168.1.11. The public address of the firewall is 5.5.5.5, which is provided by the ISP. If a host on the private network wants to make a connection to pfsensesetup.com. The firewall alters the source address to its own public IP address of 5.5.5.5 and sends the packet on its way. When the server replies to destination 5.5.5.5, the firewall again edits the packet, this time inserting a new destination of 192.168.1.11. All of this takes place and is transparent to the 192.168.1.11 host and the pfsensesetup.com server. When multiple hosts are using SNAT, the firewall tracks which connections belong to which private hosts using the port numbers. While the destination port of the Web server remains static (typically port 80 for the Web), the source port is usually a random port above 1024. By tracking the source port, the firewall knows which address belongs to which session. In the event that two hosts attempt to use the same source port, the NAT device edits the source port of one of the connections and replaces it with another random source port. When the return traffic is received, it translates the source port back, just like it did for the IP address. because this method of NAT relies heavily on using the source port number, it is sometimes referred to as port NAT (PNAT).

To add the SNAT functionality to the example firewall, use the following command:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 5.5.5.5

The -r option is used to specify the table we want to modify, and -A option specifies that we are going to append this rule to the POSTROUTING chain. By specifying the outbound interface, we are ensuring that the SNAT only occurs as traffic leaves the private network, meaning only in the proper direction.

The jump target SNAT is self explanatory. The –to-source option specifies what IP address we want to use as the new source address. SNAT assumes we have a static IP address to SNAT the outgoing packets to. While this is likely the case in a corporate environment, a more appropriate solution to more closely mimic the configuration of a home router would be to use the MASQUERADE command:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

The masquerade command does not require an IP specification, and will use the IP address of the firewall interface. You might be wondering why you would not use the masquerade target all of the time instead of the SNAT target. Because the source IP is static, the SNAT target will cause the NAT calculations to be performed once for a given session. Subsequent packets belonging to that session are handled the same way as the first. With the masquerade target, each packet is checked for the source IP to use, which requires more overhead than with SNAT. This is why SNAT is preferable if you have a static source IP address, and masquerade is your only option if you do not have a static source IP address to use.


External Links:

Linux 2.4 NAT HOWTO at www.netfilter.org

netfilter Operation: Part Five

netfilter operationSimulating the Windows Firewall

Now it’s time to configure the firewall. The built-in firewall on Windows XP/Vista/7/8 is enabled by default (on XP Service Pack 2 or better). The standard configuration is to allow outbound connections from the host system and deny inbound connections unless they are explicitly configured. The Windows firewall also allows any traffic that is a reply to traffic that the host originally generated. After you execute the iptables -F command to flush out all the previously configured rules, the following commands would configure the Linux host similarly:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

The –state extensions track the current status of the connections. By specifying ESTABLISHED or RELATED, the firewall allows packets that are starting a new session, but where the session is related to an existing session (such as an FTP data session). If you were hosting a service on this system, such as a Web server, you would need to configure the INPUT chain appropriately. This configuration would afford any Linux system a minimum level of firewall security with virtually no impact to its overall functionality.


Simulating a Consumer-Grade Home Router

With the basics of iptables configuration out of the way, let’s consider a more practical example. For a typical firewall, there is very little traffic destined to or from the firewall itself. In general, the only traffic that would fit this profile would be administrative sessions to configure the firewall itself. The vast majority of a firewall’s traffic is passing through the firewall, and will thus be checked against the FORWARD chain. The following examples would configure the Linux firewall with the same access controls as a typical home network router such as a Linksys or Netgear router/firewall. This example assumes that 192.168.1.0/24 is the internal network on interface eth0 and the external interface is eth1.

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -0 eth1 -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

One important element is to always remember that if you have configured the default policy for a chain to DROP (for example, iptables -P FORWARD DROP) that you will need to include an explicit rule to permit the return traffic. This can be done by using the following command:

iptables -A -m state –state ESTABLISHED,RELATED -j ACCEPT

So if you wanted to permit the return traffic for a FORWARD chain, you would enter:

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

Many hours of troubleshooting Linux firewalls have been spent by overlooking a rule that permits the return traffic.

We will continue our look at netfilter firewall configuration in the next article.


External Links:

Simulating windows firewall with iptables at ittopix.wordpress.com

netfilter Operation: Part Four

netfilter operationPermitting Firewall Traffic

In the previous article, we set up netfilter with a default policy of DENY. Now that we have done that, we want to make sure that management traffic is permitted to the firewall itself. This is done first, because once you have enabled the firewall with a default policy of DENY, you will not be able to manage the firewall remotely until you have configured the firewall rules to permit the management traffic. This traffic is processed against the INPUT chain, because the destination is the netfilter host itself. To allow secure shell (SSH) connections to the firewall, use the following command:

iptables -A INPUT -p tcp -s 192.168.1.0/24 –dport 22 -j ACCEPT

In this example, you are appending (-A) a rule to the INPUT chain to allow traffic from the 192.168.1.0/24 network to a destination port of TCP 22. With no other configurations, all other traffic through or to the firewall would be dropped. This will show up in the rule listing as follows:

iptables -L INPUT
Chain INPUT (policy DROP)

Target prot opt source destination
ACCEPT tcp — 192.168.1.0/24 anywhere tcp dpt:ssh

Although the aforementioned rules will permit the inbound SSH session, there is currently no rule to permit the reply traffic for the SSH session. If you were to change the default policy for the OUTPUT chain to ACCEPT, this would permit the reply packet, but we will instead address this more securely in the next few examples.


If you wanted to allow 192.168.1.99 access to the firewall with a destination of TCP port 80, you could use the same syntax with -A to append the rule, which would put the new rule for port 80 after the rule for port 22. You could also use -I for insert, as in the iptables -I INPUT 1 -p tcp -s 192.168.1.99 -dport 80 -j ACCEPT command. This would insert the new rule in the INPUT chain as rule #1, meaning the rule for port 80 would come before the rule for port 22. Remember, this is still permitting only half the conversation; you still need to permit the outbound reply packets. It is sometimes useful to list the chains with rule numbers using the iptables -L (or –line-numbers) command.

For outbound traffic (i.e. traffic generated by the firewall), you need to create rules in the OUTPUT chain. To enable syslog traffic from the firewall to a remote syslog server (192.168.1.99), you would enter the following:

iptables -A OUTPUT -p udb -d 192.168.1.99 –dport 514

This assumes you are using the default UDP syslog port of 514. Because syslog over UDP is a one-way conversation, you will not need to permit any inbound replies for permitted traffic that you allowed inbound in the preceding examples. You could create rules to permit SSH and HTTP specifically, but there is also a way to permit all traffic that is a reply to a permitted session. You can enter:

iptables -A OUTPUT -m state –state RELATED, ESTABLISHED -j ACCEPT

This will instruct netfilter to permit any outbound traffic that is part of an established session (ESTABLISHED). The RELATED keyword is similar, but is for traffic that is part of a different session, but where the session is related to an established session. Some protocols will open additional ports (such as FTP) as part of their normal behavior. For those that netfilter understands, it can see the request for the additional port and permit that new session.


External Links:

Simple Firewall Configuration Using NetFilter/iptables at www.novell.com

netfilter Operation: Part Three

The firewall GUI in Fedora.

The firewall GUI in Fedora.

The next step is to demonstrate how to configure the netfilter firewall. This is a critical step and the firewall should only be installed and configured after the underlying OS has been installed, updated, and hardened. We assume here that you are working with an otherwise secure system and now need to configure the firewall’s functionality.

To make sure the firewall is enabled, you can run chkconfig –list, which lists all of the services and the run levels they are configured to start in. For example, you may get the following output:

chkconfig –list | grep iptables

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

This output tells you that iptables will start in run levels 2-5. You can set it to run in run levels 2-5 by using the chkconfig -level 2345 iptables on command. If you are using a GUI window manager, you probably have another graphical application to see this information. For example, in Fedora, you can navigate to System -> Administration -> Security Level and Firewall.

You can enable or disable the firewall by going to the Firewall Options tab and selecting Enabled or Disabled. The interface in Fedora allows you to perform limited configurations of the firewall rules (e.g., by checking the Trusted Service SSH, a rule would be added to allow inbound connections on TCP port 22). Because any graphical interface provided will likely vary from one distribution to another, we use the command line to configure the firewall.


netfilter Operation: Deleting Rules and Chains

With many Linux distributions, the netfilter firewall will become enabled, but with an empty ruleset. In others, it might come with the firewall enabled and a very liberal ruleset in place. We can start configuring a Linux firewall by deleting any default rules that are present. You can use iptables -L (or –list) to list the current rules. An empty default ruleset should look like this:

iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination

Chain FORWARD (policy ACCEPT)
Target prot opt source destination

Chain OUTPUT (policy ACCEPT)
Target prot opt source destination

If there are any default rules present, they can be deleted using the iptables -F command. The -F option means to flush, which is equivalent to using -flush. This will clear all rules out of any existing chains. If distribution has any additional chains created beyond the default, you can delete a custom chain by using the iptables -N customchain command. In addition to the individual rules within a chain, the built-in chains have a default policy associated with them. This policy tells netfilter what to do if a packet reaches the end of the chain without finding a match. While the default policy is to ACCEPT, it is better to change this to DROP by using the -P option, which sets the default policy for that chain, as follows:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

We will continue our look at netfilter configuration in the next article.


External Links:

Basic Fedora Linux Firewall Configuration at www.techtopia.com

© 2013 David Zientara. All rights reserved. Privacy Policy