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 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 for the Address field. Enter for the Netmask.
  4. Next, we’ll create an internal Web server at  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 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

Firewall Builder Tutorial: The Basics on YouTube

netfilter Operation: Part Nine (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

Linux Firewall – The Second Line of Defense at Linuxtopia

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 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 is the internal network on interface eth0 and the external interface is eth1.

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

iptables -A FORWARD -s -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

Port Blocking in Linux

port blockingIn the previous article, I covered the network security benefit of disabling unused services. In this article, I will cover the concept of port blocking, and how it can be done under Linux.

TCP/IP networks assign a port to each service: e.g. HTTP, Simple Mail Transfer Protocol (SMTP), Telnet, FTP, and Post Office Protocol version 3 (POP3). This port is given a number, called a port number, used to link incoming data to the correct service. For example, if a client browser is requesting to view a server’s web page, the request will be directed to port 80 on the server. If the client starts an FTP session, the request will be directed to port 21. The web service receive the request and sends the web page to the client. Each service is assigned a port number, and each port number has a TCP and UDP port. For example, port 137 is used for the NetBIOS name service and has a TCP and a UDP port, with NetBIOS over TCP usually using UDP port 137 (TCP port 137 can be used, but rarely is).

There are two types of ports used for TCP/IP networks: well-known ports and registered ports. The well-known ports are the network services that have been assigned a specific port number (as defined by /etc/services). For example, SSH is assigned port 22, and HTTP is assigned port 80. Servers listen on the network for the requests of well-known ports. Registered ports are temporary ports, usually used by clients, and that will vary each time a service is used. You can also call registered ports ephemeral ports, because they only last for a brief time.

Port Blocking: Determining Which Ports to Block

When determining which ports to block on your server, you must first determine which services you need. In most cases, you can block all ports that are not exclusively required by those services. This is a bit tricky, because in implementing port blocking, you can easily block yourself from services you need, especially services that use ephemeral ports, as explained earlier.

For example, if your server is an exclusive FTP server, you can block all TCP ports except ports 20 and 21, respectively. If your server is an exclusive HTTP server, you can block all ports except TCP port 80. In the case of the FTP server, you can block all UDP ports except port 20, since FTP requires UDP port 20 to be open. If you use the system as an HTTP server, in setting up port blocking you can block all UDP ports, since HTTP uses TCP services exclusively.

However, if you want to use your server as an HTTP client, or as an e-mail client or an e-mail client to a remote mail server, you will restrict the system by doing this. Clients require registered UDP ports for DNS, as well as registered TCP ports for establishing connections with web servers.

If you, for example, try to download an operating system update, and you have only opened UDP port 20, DNS requests will be blocked because DNS queries use port 53. Even if you open port 53, a different registered port may be assigned each time for the answer. In this situation, the best policy may be to open all TCP/UDP registered ports, or set up port blocking to block all of them, and download operating system updates from another computer.

Port Blocking in Red Hat and Other Linux Distros

To utilize port blocking for TCP/UDP services in Linux, you must disable the service that uses the specific port. You may use the GUI interfaces of firewall services offered by most of the Linux distros. In Red Hat Enterprise Linux (RHEL) 5, this is achieved by navigating to System -> Administration -> Security Level and Firewall, which opens up the firewall configuration utility. To allow a service to run, just check and enable the service and to block, uncheck the service. If you want to add any non-standard port or a custom port to be allowed by the firewall, then click on Other ports and add the protocol type (TCP or UDP) and add the port number.

If you don’t use RHEL, don’t despair. Regardless of which version of Linux you use, iptables is the Linux kernel firewall, and rules can be added or deleted at the command line. For example, to set the default chain policy to block, type this:

iptables -P INPUT DROP

Once you do this, you can complete your port blocking setup by selectively enable ports. For example, to allow all incoming SSH connections on eth0, type:

iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

You may, however, opt to use a frontend to iptables to implement port blocking. Shorewall is one such frontend, and its creators call it “iptables made easy”. If you use Ubuntu, the default firewall configuration tool is ufw (Uncomplicated Firewall), and it simplifies the process of using iptables. To enable ufw, type:

sudo ufw enable

The default parameter allows us to set the default policy. Let’s assume we want set the default policy to block all incoming traffic. We would type:

sudo ufw default deny in

Here, “deny” is the policy (the choices are allow, deny, or reject), and “in” indicates the direction in which traffic is blocked (choices are in or out). Since “in” is the direction the rule applies to by default, we could have just typed:

sudo ufw default deny

If we wanted to allow incoming traffic on port 80, we would type:

sudo ufw allow in to any port 80

There’s much more to ufw than what I present here, so I advise reading the documentation (especially the man page) for more information on port blocking. However, one important parameter for ufw that should be mentioned is –dry-run. When this command is invoked, ufw won’t modify anything, but will just show the changes.

External Links:

iptables at Wikipedia

Shorewall homepage

ufw manpage

Firewall at

25 Most Frequently Used Linux IPTables Rules Examples

Packet Filter: The Engine of pfSense

Packet FilterpfSense is, as most users know, a specialized version of FreeBSD. It can be configured an upgraded through a web-based interface and often runs on embedded systems; it requires no knowledge of the underlying FreeBSD system. Those curious enough to find out, however, will be interested to know that pfSense is based on OpenBSD’s powerful pf (Packet Filter) software, which was released in late 2001 and has since been ported to many other operating systems including FreeBSD, NetBSD, DragonFly BSD, Debian GNU/Free BSD, and Mac OS X 10.7 “Lion” and later.

OpenBSD and the other BSD variants are direct descendants of BSD Unix. BSD, sometimes called Berkeley Unix, is a Unix operating system derivative developed and distributed by the Computer Systems Research Group (CSRG) of the University of California, Berkeley, from 1977 to 1995. The final release from Berkely was 1995’s 4.4BSD-Lite Release 2, after which the CSRG was dissolved and development of BSD at Berkeley ceased. In the meantime, as CSRG was winding down, small groups of enthusiasts around the world began working on further development of the code. Several different variants of BSD Unix came into existence. The OpenBSD group became known as the most security-oriented of the BSDs. For its packet filtering needs, it used a program called IPFilter, written by Darren Reed.

The packet filter’s main function is to filter network packets by matching the properties of individual packets and the network connections build from those packets agains the filtering criteria defined in its configuration files. The packet filter is responsible for deciding what to do with those packets, which could mean passing them through or rejecting them, or triggering events that other parts of the operating system or external applications are set up to handle.

The IPFilter subsystem performed this function within OpenBSD, but in May 2001, IPFilter was removed from the OpenBSD source tree due to licensing issues. The OpenBSD version of IPFilter contained several changes and customizations that, as it turned out, were not allowed under the licensing agreement. For a few weeks, the development version of OpenBSD did not include any firewalling software.

Enter Packet Filter

However, Daniel Hartmeier had already begun work on his own packet filtering software, called PF, and after a few months of development, it was ready to be added to OpenBSD. PF was added as a default part of the OpenBSD 3.0 base system in December 2001. Migrating from IPFilter to PF sense did not pose major problems, as their configuration languages were similar. Moreover, PF has done well in performance tests, performing equally well or better under stress on OpenBSD 3.1 than either IPFilter on OpenBSD 3.1 (or iptables on Linux). PF’s overhead is relatively low, and is capable of running effectively on rather modest hardware.

Future installments of this series of articles will go into greater depth on how to configure and run PF. For now, it should be mentioned that in order to run PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. OpenBSD is the BSD variant of choice for many, as this is where PF was first introduced and where essentially all PF development happens. Moreover, the newest and most-up-to-date PF code is always to be found on OpenBSD. If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation about which version of PF is included.

External Links:

PF documentation in the OpenBSD FAQ

© 2013 David Zientara. All rights reserved. Privacy Policy