Creating A Linux Firewall Using the TIS Firewall Toolkit

If you have a valuable or fragile network to protect, you may want to protect it with a very strong, well-proven firewall. In this article, Benjamin Ewy explains very thoroughly how to build your own 'bastion host' firewall with Linux.
Compiling the Firewall Toolkit

Obtain the toolkit, Linux patches, and, if desired, the S/Key package, as detailed in Obtaining Firewall Resources. Bellcore's S/Key provides one-time password support for network authentication if built into the toolkit. A number of commercial one-time password systems are also supported by the fwtk, but their use is not detailed in this article.

Put the fwtk archive in /usr/src/, and run tar xfz fwtk-v1.3.tar.Z to unpack it. If you prefer to build in a different place, modify the Makefile.config as appropriate. The Linux patches that we will be applying assume /usr/src/fwtk is the source code directory.

These patches are based on the work of Marco Pauck ( and the firewall-users mailing list. In addition, there are some modifications and additions done by the author to allow the x-gw proxy to work and to support the S/Key authentication mechanism. Most of the patches work around Linux's select() function. Put the fwtkpatches.tgz file into /usr/src/fwtk. Then run tar xfz fwtkpatches.tgz which will create a patches directory. Go into the patches directory and run the INSTALL script or apply the patches by hand. If you do not want S/Key support, run the INSTALL.noskey script instead.

Assuming you want S/Key, put the S/Key archive in /usr/src and run tar xfz skey-2.2.tar.gz to un-archive it. It is necessary to compile S/Key first so that its libraries can be linked into the authentication service when we compile the fwtk. This S/Key is already ported to Linux, so all that is necessary to build it is to run make inside the /usr/src/skey-2.2 directory.

When the patches have been installed and S/Key has been compiled, you can modify the Makefile.config if you want to change any of the defaults, but the rest of this article will assume you have left the Makefile.config as patched. Go to /usr/src/fwtk/ and run make and make install. The firewall components will be installed in /usr/local/etc/ by default.

Configuring the Network Access Control Lists

The firewall toolkit is made up of three main components: netacl, authsrv, and the various service proxies. Netacl is similar to the tcp wrapper, tcpd, that is common on many Linux systems. Netacl is used to check rules on a per-service basis and take the defined action. You edit your /etc/inetd.conf file to call netacl, passing the normal service to netacl as its first parameter. An example entry for the finger service might look like Listing 1. inetd will invoke netacl when a connection is made on the finger port.

Netacl looks in the common configuration file to see what action to take. The common configuration file is called the netperm-table and is found in /usr/local/etc/netperm-table. A default netperm-table that has many examples, in addition to the ones presented in this article, is installed automatically. Netacl looks in the netperm-table and reads entries that start with netacl. Netacl understands the permit-hosts and deny-hosts options for defining access lists and requires -exec to be defined for each line as well, as shown in Listing 2.

A given service can have multiple lines of both the permit and deny varieties. Address can be a list of hosts addresses, and wildcards such as *.my.domain or 129.17.* are supported. The keyword unknown matches hosts that cannot be resolved using DNS. The first rule that matches is the one performed. Lines may not be broken.

In the examples given in this article, the following conventions will be used: will represent your internal network. will represent a ftp server internal to your network. will represent a www server internal to your network. is a compute server internal to your network. is an external network that you trust. will represent your bastion host's IP address.

An important point is that these rules are not associated with a network interface. If you write rules for a service to allow your internal private network to have special access rights, you must ensure that those IP addresses could only have been received from your internal network. IP spooling can be used to pretend to be a host on your internal network and take advantage of your rules. This can be prevented by using screening routers to block packets claiming to be from the internal network when they arrive on the external network connection. Often your Internet provider can implement this type of rule in the router that feeds your site.

The first line of Listing 3 will exec in.fingerd if the requesting host is a member of The second line will match all others and cat a message of your choice. This might be a “fake” finger output to mislead attackers or a simple explanation that the service is unavailable. Netacl is often used for permissions on services that you are not proxying but can also be used to switch among the proxy or the real service based on the origin of the connection. This feature will be discussed in more detail later.

The netperm-table also contains configuration information for all of the proxies, as shown in Listing 4. The format is similar to the netacl format, and each rule can contain multiple lines. These options will be discussed in more detail for each proxy later.


One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix