Creating A Linux Firewall Using the TIS Firewall Toolkit

 in
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 (pauck@wmd.de) 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: .internal.net will represent your internal network. ftp.server.internal.net will represent a ftp server internal to your network. www.server.internal.net will represent a www server internal to your network. compute.server.internal.net is a compute server internal to your network. trusted.external.net is an external network that you trust. bastion.host.internal.network 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 trusted.external.network. 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.

______________________

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState