"A commercial, and in some respects a social, doubt has been started within the last year or two, whether or not it is right to discuss so openly the security or insecurity of locks. Many well-meaning persons suppose that the discussion respecting the means for baffling the supposed safety of locks offers a premium for dishonesty, by showing others how to be dishonest. This is a fallacy. Rogues are very keen in their profession, and already know much more than we can teach them respecting their several kinds of roguery. Rogues knew a good deal about lockpicking long before locksmiths discussed it among themselves, as they have lately done. If a lock—let it have been made in whatever country, or by whatever maker—is not so inviolable as it has hitherto been deemed to be, surely it is in the interest of honest persons to know this fact because the dishonest are tolerably certain to be the first to apply the knowledge practically; and the spread of knowledge is necessary to give fair play to those who might suffer by ignorance. It cannot be too earnestly urged, that an acquaintance with real facts will, in the end, be better for all parties."

—Charles Tomlinson's "Rudimentary Treatise on the Construction of Locks," published around 1850

UNIX/Linux Systems

It has been said that the wonderful thing about standards is there are so many to choose from. The same choice is available in the UNIX arena. There are two basic flavors, BSD-derived and AT&T System V-derived. BSD-derived UNIX systems include OpenBSD, FreeBSD, NetBSD, BSDi, MacOS X, and SunOS 4. System V-derived UNIX systems include HP-UX and Solaris (SunOS 5). Other UNIX systems, such as AIX, provide commands that will act BSD-ish or System V-ish, depending on how they were invoked. Linux is not derived from any UNIX, but depending on the distribution, borrows from both BSD and System V semantics. Actually, Linux itself is just the operating system kernel and supporting drivers. Most Linux distributions use the GNU system (http://www.gnu.org), thus they are called GNU/Linux distributions. There are hundreds of available GNU/Linux distributions, but even the "top 5" are different in their default commands, startup scripts, filesystem layout, included utilities, and packaging systems.

What does this mean to you? Unlike Windows NT, including Windows 2000, it is a far more complex process to describe how to harden a UNIX/Linux server. This next section provides some common procedures that can be applied across UNIX versions and GNU/Linux distributions. Following that are some pointers to living documents on the Internet, which track available data and releases, and go into a more detailed account of how to harden a server for a particular task.

Common Steps for Hardening UNIX/Linux Servers

The process of building a UNIX or GNU/Linux server for use as a firewall or DMZ server begins with installation. Eliminating points of attack, such as filling the filesystem, or removing unnecessary libraries and services, is equivalent to removing possible entry points for intruders.

Some common guidelines for configuring UNIX servers with a more secure default stance are available from CERT's Web site at ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines.

Partition for Protection

Besides having separate partitions for the obvious, such as SWAP and /tmp, you should protect against out-of-disk-space denial-of-service attacks. Intruders might try to create excessive generation of logging data or fill your file system with large files through FTP or mail spool. The best way to protect against this is to segment the filesystem hierarchy into separate physical partitions.

The root partition / can be small because it generally contains just the kernel—the necessary files, libraries, and configuration for booting in /bin, /sbin, /etc, and /lib. Access to the attached devices is provided through the /dev and /devices directories. Many GNU/Linux distributions store kernels and symbol data in the /boot directory, whereas kernel libraries are stored under /lib.

The /usr partition is normally where user-accessible applications are stored. Normally, /usr does not contain data or configuration files that change; therefore, an added security measure can be mounted as read-only.

The /var partition stores system logs and data services such as mail, Web, databases, printing, running services, package management, and so on. On a mail server, you might want to make /var/spool/mail, or /var/mail in Solaris, a separate partition, or—even better—a separate disk array. If you only create one separate partition from /, /var is the one you should separate.

The /usr/local directory structure, and in Solaris the /opt directory, often contains locally installed optional software, configuration files, and data. /usr/local is normally not affected by operating system upgrades. Depending on how you use those directories, they too can be mounted as read-only.

These are suggestions and guidelines only, and are different from recommended settings for a system that contains user accounts, usually in /home.

Disable Extraneous inetd Services

inetd is the UNIX "Internet Super Server." It is a daemon process that is invoked at boot time and reads in a flat file configuration database normally found at /etc/inetd.conf. inetd listens for incoming connections on the defined IP ports. When a connection is initiated on a defined port, it invokes the configured program to service the request. After the connection is finished, the process invoked to service that request terminates. This was originally designed to lighten the load and resources required for systems.

There are a number of services enabled through inetd, and almost all of them should be disabled for building firewalls and DMZ servers. Besides normally disabling FTP, TFTP, Telnet, and the Berkeley r* commands, disable the following:

• in.named—BIND name services daemon. Except for your DNS servers, you should not be running DNS on your firewall or DMZ servers.

• in.fingerd—Finger daemon that can be used to show user information and lists of users who are logged in. There is no reason to advertise that information to would-be intruders.

• daytime—Connections to this service display the date and time on the system in a string format. Getting the date and time of a system is useful for an intruder trying to implement replay attacks.

• time—Connections to this service return the time as a 32-bit value representing the number of seconds since midnight 1-Jan-1900. Do not provide intruders with your exact system time.

• echo—This is a diagnostic service that echoes incoming data back to the connecting machine.

• discard—This is a diagnostic service that does not echo (thus discarding) the incoming data stream back to the connecting machine.

• chargen—This is a diagnostic service that automatically generates a stream of characters sent to the connecting machine.

• systat—Connections to this service provide a list of all processes and their status.

• netstat—Connections to this service provide a list of current network connections and their status.

Install and Configure tcp_wrappers

Install and configure Wietse Venema's tcp_wrappers on both your firewall and DMZ servers. tcp_wrappers allows you to define access control to various services, depending on a limited set of criteria, such as username, IP address, or DNS domain.

You might be asking why it's necessary to configure and install additional products when your firewall will be doing the same thing. And that's a valid question. The answer is to avoid single points of failure, and to provide security in layers. If one layer is pierced and bypassed, other layers will be standing guard behind the breach.

tcp_wrappers are lightweight and extremely useful on internal servers; not just on firewalls and DMZ servers. Keep in mind that most information security breaches, intentional or accidental, happen internally. It's only the external defacements, massive distributed denial of service (DDoS) attacks, virus-du-jour, and stolen credit card databases that grab the press. That, and misplaced hard drives with highly sensitive nuclear information.

tcp_wrappers have two main files that allow access to the individually defined services. The following two files are checked for rules governing access to individual or wildcard services:

/etc/hosts.allow
/etc/hosts.deny

Like most firewalls, access is granted or denied on the first matching rule. The rules are checked in order, first in hosts.allow and then in hosts.deny.

Care should be taken when using the KNOWN or UNKNOWN wildcards. ALL will always match whatever criteria you are testing. Read the hosts_access manual page included with tcp_wrappers for further details on syntax and rules setup.

tcp_wrappers is installed and configured by default on most GNU/Linux distributions and BSD releases. For those UNIX systems that do not have tcp_wrappers installed by default, they can be found at ftp://ftp.porcupine.org/pub/security/index.html. Retrieve the source, compile, and install the binaries on the servers.

Lock Down Your DNS Server

The Berkeley Internet Name Daemon, or BIND, is the reference implementation of the name service providing DNS for the Internet. The Internet Software Consortium (ISC) is responsible for implementing and maintaining BIND. There are three basic versions of BIND: BIND 4, BIND 8, and (recently) BIND 9.

BIND 4 has been around forever, and has its share of exploits. Only very old versions of UNIX systems and GNU/Linux distributions came with BIND 4. Still, you'll be surprised how many installations still have the older BIND 4 running. You should upgrade to a newer version of BIND. The unfortunate thing is that the file format defining the zones served by the server has changed. There are conversion scripts, but there is sure to be some hand editing.

BIND 8 is the current stable release, and offers many more features and better control and granularity in access control. The settings described later are discussed with BIND 8 in mind.

BIND 9 was released late in 2000. It offers many new features, such as IPv6 support, DNSSEC, full Dynamic DNS, incremental zone transfers, multiple views (internal, external, and so on) from a single server, and scalability improvements. If any of those features are important to your configuration, you should investigate using BIND 9; otherwise, it's best left to the adventurous.

Although almost all UNIX systems and GNU/Linux distributions come with BIND as the name server, it is important you make sure you are at a recommended release. Before deploying a DNS server, internally or on the DMZ, make sure it is at least version 8.2.2-P5. Any version prior to that has serious exploits. This warning should not be ignored. The Internet Software Consortium themselves have issued a statement that if you are running any version of BIND prior to 8.2.2-P5, you should assume your server has already been compromised. Check your UNIX system or GNU/Linux distribution. If the version of BIND is not at least 8.2.2-P5, check with your vendor for upgrades. If an upgrade is not available, you can compile a version of BIND yourself on a workstation, and install the binaries on your server. The source code can be found at http://www.isc.org/products/BIND/.

First, restrict zone transfers to specific secondary servers in your primary zones. The acl command allows you to define an access control list composed of blocks of addresses to be used with a named identifier. Using ACLs provides a self-documenting method of administrating the named.conf configuration file. In the following example, we define two ACLs comprising our externally visible DNS servers and the secondary servers at our ISP:

acl your-company-dns {
 172.16.30.12;
 172.16.30.24;
};
acl your-ISP-dns {
 199.177.202.10;
 204.95.224.200;
};

The following allow-transfer option directive placed in your named.conf file will default all defined zones to only allow transfers for the defined hosts:

options {
 allow-transfer { 
  your-company-dns; 
  your-ISP-dns;
 };
};

You can override the allow-transfer statement in the options directive by placing the allow-transfer statement in the zone definition:

zone "yourdomain.com" {
 type master;
 file "db.yourdomain-com";
 allow-transfer { 172.16.30.12; 192.168.71.200; };
}

The default allow-transfer option will prevent zone transfers to hosts not specified in the ACLs. However, if you want to restrict all zone transfers on your secondary servers and any secondary zones on your primary servers, use predefined match list none. This can be accomplished with the following allow-transfer directive in your zone definitions:

zone "yourdomain.com" {
 type slave;
 file "db.yourdomain-com.s";
 masters { 192.168.71.1; };
 allow-transfer { none; };
};

Finally, because you will be allowing recursive queries through your servers, it's best to enable access control lists for your internal networks. Using a nested, named acl with the allow-query option in the zone definition, you can then restrict recursive queries to internal hosts only as seen in the following example:

acl internal-net {
 192.168.71.0/24; 
};

acl dmz-net {
 172.16.30.0/24; 
};

acl trusted-hosts {
 localhost;
 internal-net; 
 dmz-net;
};

zone "yourdomain.com" {
 type master;
 file "db.yourdomain-com"
 allow-query { trusted-hosts; };
};

Que's Concise Guide to DNS and BIND by Nicolai Langfeldt is a wonderful resource to further grok BIND configuration and maintenance.

Tighten Sendmail Default Options

Send mail comes with just about every UNIX/Linux installation as the default mail transfer agent (MTA). As a result of being so widely installed, it has been estimated that sendmail handles a majority of the email on the Internet. Because it runs as suid root, sendmail exploits affect millions of machines.

sendmail version 8.11.0 is available at the time of publication, and supports new features such as STARTTLS and SMTP AUTH encryption. Upgrade to the newest version available, if possible, but please make sure that you are running a version no later than version 8.9.3 because of security exploits.

To enable the Realtime Blackhole List feature, use the following in your sendmail.mc file:

FEATURE(rbl)dnl

Additionally, you might want to disable the SMTP VRFY and EXPN commands in sendmail. These commands are often used by intruders to gather information about your system:

define(´confPRIVACY_FLAGS', ´novrfy,noexpn')dnl

There are several additional flags you can set to make sendmail have a more secure stance:

• authwarnings—Add X-Authentication-Warning header in messages on certain conditions that might indicate mail system spoof attempts.

• needmailhelo—Require that the sending site uses the SMTP HELO command first when connecting to send email.

• needexpnhelo—Require that the sending site uses the SMTP HELO command before allowing any EXPN usage.

• needvrfyhelo—Require that the sending site uses the SMTP HELO command before allowing any VRFY usage.

• noreceipts—Disable Delivery Status Notification (DSNs) of delivery and read receipts.

• goaway—Set all flags except restrictmailq and restrictqrun.

• restrictmailq—Prevent users from using the mailq command to view the contents of the mail queue.

• restrictqrun—Stop users from processing the queue.

Better than sendmail: Making Postfix Your MTA

According to its Web page, Postfix's goals are "to be fast, easy to administer, and secure, while at the same time being sendmail compatible enough to not upset existing users."

Postfix was primarily written by Wietse Venema of tcp_wrappers fame. Postfix was designed to be modular, thus Postfix is not a single executable like sendmail; rather, Postfix comprises a collection of specialized programs that perform specific tasks. All the programs except for the master control process (oddly called master because it runs without root privilege) run as nonprivileged users, limiting the damage an attacker can inflict on your system. Because of the speed, ease of configuration (and thus less chance of misconfiguration), and security, it is recommended that you investigate replacing sendmail with Postfix. For those of you who do not dream in sendmail.cf syntax, Postfix will make email administration both easier and more secure.

Postfix is now distributed with most GNU/Linux and BSD releases, although it is not often installed by default. Usually, it is a simple matter of installing it via your package management system, or (in the BSD case) via the ports collection.

If you are using an operating system that does not distribute Postfix, despair not. You can download and compile the sources easily on a development workstation and then install the binaries on your mail server. The sources, FAQs, and documentation can be found at http://www.postfix.org/

Linux-Specific Tasks

There are many GNU/Linux distributions out there. Each vendor has its own installation process, which usually changes between new versions of the vendor's distribution. The "forerunners" of GNU/Linux distributions are Red Hat, SuSE, TurboLinux, Mandrake, Caldera, Slackware, and Debian. That does not mean specifically that you should use any one of them because the high number of distributions allows vendors to tailor their GNU/Linux distributions to specific tasks such as embedded systems, routers, and firewalls. Take the time to carefully investigate the available distributions, and determine which best fits your needs.

With that said, two of these general distributions stand out, but for different reasons. Red Hat, because it has had the most name recognition, and is usually the first to get any sort of corporate support in the way of commercial software or commercial technical service. Many vendors, such as Oracle, IBM, and Check Point, have released products for Red Hat-specific distributions. This does not mean that those software releases will not run on other GNU/Linux distributions, but if there is a problem, the vendor might not support your installation of its product on a non-Red Hat distribution.

Debian is the second distribution that deserves mention. First, not because it is entirely free, but because it is maintained by a nonprofit organization made up entirely of volunteers. These volunteers are highly motivated by quality and pride in their efforts to make Debian the most stable and completely 100% free distribution available. Debian has proven to be extremely stable and easy to manage and upgrade remotely. The upgrade process is by far the easiest of any of the GNU/Linux distributions. Debian installations can be upgraded without the need for reboots, replacing every installed package and running process excepting the kernel. Additionally, the Debian packaging system and its front ends allow extremely fine-grained control over which packages, utilities, libraries, and files exist on your system. Debian also is currently available on six different architectures, with more than 3,900 included software packages to select from when installing.

For both Debian and Red Hat installations, you should choose custom installations, and select the individual packages you want on your system. There should be no need to install development packages, any of the new KDE or GNOME desktops, and certainly not X Window. Unfortunately, neither distribution yet has a minimal secure server or firewall predefined install-set.

During the installation process, you should choose to enable shadow password file support; choose to use MD5 hashes for the passwords rather than the normal crypt function. If you miss these options during the install, you can change them after installation. In Red Hat, use the setup utility. In Debian, you can use the shadowconfig utility to enable or disable shadow passwords. To enable MD5 hashes, you have to edit the appropriate files under /etc/pam.d to include md5 on the password lines.

You should also enable ipchains support, even if this is an application server on the DMZ. ipchains provides additional layers of security, and allows you to protect the server from traffic should the firewall fail for some reason. A sample ipchains configuration is discussed later in the article.

You should additionally read and monitor the security and errata/updates lists from your distribution vendor. With Debian, it is extremely easy to automatically install security updates using the apt-get utility. For Red Hat installations starting with the 6.0 release, there is the up2date utility to retrieve updated packages for your release.

For those people who choose to install Red Hat Linux, there is a security-related project called Bastille Linux, whose aim is not just to harden your Linux installation, but to educate the administrators on how to harden the system. Bastille Linux supports Red Hat and Mandrake Linux distributions with project goals to become distribution, and UNIX flavor, agnostic. The Bastille Linux product is a set of scripts that asks a series of questions and then allows you to apply those modifications to your system. The questions describe what needs to be done, why it should be done, and why you might not want to do it. It is very educational, especially for those administrators just getting familiar with Linux. Bastille Linux can be found at http://www.bastille-linux.org/.

Another excellent source of information for administrators is the Linux Administrator's Security Guide. It covers an extremely wide array of topics related to Linux and security. You can find the Linux Administrator's Security Guide online at http://www.securityportal.com/lasg/.

Solaris-Specific Tasks

Solaris has four default install-sets: Core, End-User, Developer, and Entire Distribution. Installing any install-set higher than the Core installation will enable more services than are required for DMZ servers or firewalls. In reality, you can often remove a significant percentage of the default Core install-set, depending on your server's application requirements.

For Solaris-based servers, there are several excellent documents from Sun in its Blueprints Online archive at http://www.sun.com/software/solutions/blueprints/online.html. The following three papers are excellent starting points for building secure Solaris servers:

• "Solaris Operating Environment Minimization for Security: A Simple, Reproducible and Secure Application Installation Methodology" by Alex Noordergraaf and Keith Watson. Although this paper specifically covers the iPlanet Web server requirements, similar requirements are necessary for using Apache or other Web servers.

• "Solaris Operating Environment Security" by Alex Noordergraaf and Keith Watson. An overview of general security options on a Solaris server. This paper includes some specifics for the SPARC architecture; however, most of the material is applicable to Intel architectures as well.

• "Solaris Operating Environment Network Settings for Security" by Alex Noordergraaf and Keith Watson is another excellent paper on kernel tuning and application parameters that affect network security.

As a matter of fact, Sun's Blueprints Online is a wealth of whitepapers outlining Best Practices regarding Solaris Operating Environments, whether it is a DMZ Web server, firewall, or internal highly available database cluster.

Lance Spitzner also has an excellent Solaris hardening document that details the hardening process for building a Check Point FireWall-1 firewall on several recent versions of Solaris (through version 8) for the Intel and SPARC platforms. The living document resides at http://www.enteract.com/~lspitz/armoring.html.

Finally, there is an equivalent to the Bastille-Linux hardening scripts for Solaris called TITAN. The TITAN project and documentation can be found at http://www.fish.com/titan/.

OpenBSD-Specific Tasks

This section concentrates on OpenBSD 2.7, which is one of the three more famous BSD variants; the others being NetBSD and FreeBSD. Each variant has focused on a different problem: NetBSD is the most portable, FreeBSD has the best performance, and OpenBSD is the most secure.

One of the great strengths of OpenBSD is the highly secure default stance of a default install of OpenBSD. The OpenBSD Web site claims "three years without a remote hole in the default install, only one localhost hole in two years in the default install." Almost all services are disabled until the administrator has enough experience to properly configure them.

Two additional changes necessary for an OpenBSD box to become a firewall are to disable sendmail and enable IP filter support. Both changes are made to the same file, /etc/rc.conf. To disable sendmail, change

sendmail_flags="-q30m"

to

sendmail_flags=NO

To enable IP filter support, you must change

ipfilter=NO

to

ipfilter=YES

Additionally, if you will be doing Network Address Translation (NAT), providing transparent proxying, or providing support for FTP, you must enable the ipnat option by setting ipnat=YES. Syntax for IP filters will be covered briefly later in the chapter.