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.

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.

Preparing Your Bastion Host

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.

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.

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.