Creating A Linux Firewall Using the TIS Firewall Toolkit

As more and more companies try to develop a presence on the Internet, establishing a secure network perimeter is becoming a very important topic. There are many varieties of what are loosely referred to as firewalls. The general principle behind a firewall is that it serves as a choke point between an internal network and the outside world. The choke point only allows traffic through that is deemed safe.

IP-based filters are one common form of firewall that rely on the source and destination addresses to decide which kind of traffic to pass through. They have the advantage of flexibility in that they can easily be adapted to different types of traffic as needed. The primary disadvantage of IP-based filters is that they rely on IP addresses as the principle form of authentication, and they also lack the ability to look higher into the protocol layer to determine exactly what kind of traffic is being sent.

Application-level gateways are another form of firewall that often consist of a computer called a bastion host. The bastion host runs a set of firewall software which implements the policy “that which is not expressly permitted is prohibited”. This policy is implemented at the application level, which allows the bastion host to more completely control the traffic that passes through it.

Implementing the interface between the internal and external networks at the application level allows much more control over the authentication for particular services and, in particular, allows for many forms of strong authentication. The main disadvantage of application-level Firewalls is that they require interfaces for every specific application that is to pass through the gateway. If a new application interface is desired, either custom software must be written or the service cannot be provided. The Trusted Information Systems Firewall Toolkit (fwtk) is a very useful kit for creating bastion hosts.

The fwtk supports the functions of a bastion host by providing several small programs that can be pieced together as the site operator desires while simplifying management with a common configuration file. For each service the security policy allows to pass through the firewall, a specific application level proxy is required. The fwtk comes with proxies for telnet, rlogin, SMTP mail, ftp, http, X window, and a generic TCP plug-board server that works as a transparent pass-through proxy for many other services.

Additionally, the fwtk comes with a tool called netacl, which implements network level access control, and authsrv, which implements a network authentication service. This article focuses on preparing a generic Linux host to be a bastion host, obtaining and compiling the fwtk, and configuring its services to support a secure network environment.

The first step is to prepare the Linux host to be a functional and secure bastion host. There are several principles that firewall builders should adhere to. The ideal bastion host should only provide proxy services and should not be a general purpose machine. Only administrative accounts should be allowed, and if possible, logins to the bastion host should be restricted to the console, although allowing strongly authenticated remote access for remote maintenance will be discussed. The bastion host should not rely on any network services such as NIS or any form of remote file access, such as NFS. Allowing either of these opens up numerous holes that can compromise your bastion host.

Next, it is necessary to verify that the required functionality is available with the Linux host. Every bastion host has at least two network interfaces, one connected to the internal network and the other connected to the external network access point. These interfaces should be configured and tested prior to any further modifications, and you should verify the accessibility of your bastion host from both the internal and external networks. Refer to the Linux NET2 HOWTO and the Linux Multiple Ethernet mini-HOWTO as necessary.

The kernel should be rebuilt, ensuring that IP forwarding (CONFIG_IP_FORWARD) is disabled when you do makei config. If IP forwarding were enabled, the kernel would automatically forward packets from one interface to the other interface if a route has been established. Controlling this forwarding is what building a bastion host is all about. Finally, if you want to provide a secure mechanism for SMTP mail service, it is necessary to first configure and test sendmail. Refer to the Linux Kernel HOWTO and the Linux Electronic Mail HOWTO, as appropriate.

The next task is to secure the bastion host so that only the proxy services are available. Begin by removing all unneeded services from the inetd configuration file, /etc/inetd.conf. Simply put a # in front of each unneeded service line, and when done editing the file, issue a kill -HUP to the process id of inetd (perhaps with killall -HUP inetd). Remove ftp, telnet, SMTP, nntp, shell, login, talk, stalk, pop, uucp, ftp, bootp, finger, systat, netstat and every other service you are not expressly sure you want to provide. We will be defining our proxy services in this file later.

Finally, prevent the startup of any stand-alone daemons by cleaning out the boot files in /etc/rc.d, removing unneeded programs. In particular, check the rc.inet2 file and comment out rpc.portmap, rwhod, rpc.mountd, rpc.nfsd, rpc.ugidd, and ypbind. After you are done removing services, reboot your bastion host and carefully examine the output from a ps aux and check that you didn't miss any unnecessary programs. It is also a good idea to run rpcinfo -p and the port scanner that comes with the fwtk in the tools directory to verify that all unnecessary services are dead.