Implementing Security, Part II: Hardening Your UNIX/Linux Servers

Continuing with part 2 of this two-article series, Joseph Dries helps you continue to expand upon your list of basic security processes by looking at UNIX/Linux hardening, protecting your servers from network based TCP/IP attacks, and utilizing centralized logging servers.

This article was excerpted from The Concise Guide to Enterprise Internetworking and Security.

"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:

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:

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:

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:

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.

"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.

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.