Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

3.2. Automated Hardening with Bastille Linux

The last tool we'll explore in this chapter is
Bastille. You might be wondering why
I've saved this powerful hardening utility for last:
doesn't it automate many of the tasks
we've just covered? It does, but with two caveats.

First, the Linux version of Bastille remains somewhat Red
Hat-centric. On the one hand, Debian 3.0 includes a deb package for
Bastille 1.3, which seems to work pretty well. On the other hand, the
Bastille 2.03 RPM included with SUSE 9.0 Enterprise Linux reportedly
yields uneven results (though if you're a SUSE user,
I certainly encourage you to try it out and provide feedback to the
Bastille team). So Bastille still works best if you run a
distribution derived from Red Hat, specifically Red Hat itself,
Mandrake, or Immunix.

Second, even if you do run a supported distribution,
it's extremely important that you use Bastille as a
tool rather than a crutch. There's no good shortcut
for learning enough about how your system works to secure it.

The Bastille guys (Jay Beale and Jon Lasser) are at least as convinced of this as
I am: Bastille has a remarkable focus on educating its users.

3.2.1. Background

Bastille Linux is a powerful set of Perl scripts that both secure
Linux systems and educate their administrators. It asks clear,
specific questions about your system that allow it to create a custom
security configuration. It also explains each question in detail so
that by the time you've finished a Bastille session,
you've learned quite a bit about Linux/Unix
security. If you already understand system security and are
interested only in using Bastille to save time, you can run Bastille
in an "explain less" mode that asks
all the same questions but skips the explanations.

3.2.1.1 How Bastille came to be

The original goal of the Bastille team (led by Jon Lasser and Jay
Beale) was to create a new secure Linux distribution based on Red
Hat. The quickest way to get their project off the ground was to
start with a normal Red Hat installation and then to
"Bastille-ify" it with Perl
scripts.

Before long, the team had decided that a set of hardening scripts
used on different distributions would be less redundant and more
flexible than an entirely new distribution. Rather than moving away
from the script approach altogether, the Bastille team has instead
evolved the scripts themselves.

The Perl scripts comprising Bastille Linux are quite intelligent and
make fewer assumptions about your system than they did when Bastille
was used only on fresh installations of Red Hat. Your system
needn't be a "clean
install" for Bastille to work: it transparently
gleans a lot of information about your system before making changes
to it.

3.2.2. Obtaining and Installing Bastille

To get the latest version of Bastille Linux, point your web browser to
http://www.bastille-linux.org/.
This page contains links to the Bastille packages and also contains
complete instructions on how to install them and the Perl modules
that Bastille requires. Unlike earlier versions, Bastille 2.0 is now
distributed as a single RPM in addition to its traditional
source-code tarball.

In addition to Bastille itself, RPM-based Linux^[6] users will need either perl-Tk or perl-Curses, depending
on whether you intend to run Bastille in text-console or X Window
mode. Since not all versions of all RPM-based distributions include
these packages, the Bastille team maintains a chart that recommends
the proper packages to use for various versions of Red Hat and
Mandrake Linux, available at http://www.bastille-linux.org/perl-rpm-chartl.

^[6] Except Fedora, which as of this writing isn't
yet supported, but it may be by the time you read this.

If you run Debian, you can find the deb package
bastille in the admin group
on your Debian installation media or your favorite Debian mirror
site. As befits its age, Debian 3.0 (stable)
uses Bastille v1.3, but the testing and
unstable versions use the much newer Bastille
v2.1. Debian users also need libcurses-perl,
perl-tk, or libgtk-perl,
again depending on whether you intend to run Bastille in text-console
or X Window System mode.

I recommend the text-based interface. Bastille, unlike the scanners
we just covered, must be run on the host you wish to harden.
(Remember, bastion hosts shouldn't
run the X Window System unless absolutely necessary.) Once your RPMs or debs have successfully installed,
you're ready to harden.

3.2.3. Running Bastille

In Bastille 1.3, you run Bastille by invoking the command
InteractiveBastille. Depending on whether
you've installed perl-Curses,
perl-Tk, or both (or their Debian equivalents),
you can run InteractiveBastille with either the
-c flag for curses or -x for Tk
(X Window).

Starting a Bastille 2.x session is similar, except rather than
InteractiveBastille, the command is now simply
called bastille; this command supports the same
two flags as InteractiveBastille,
-c and -x, for specifying which
interface to use.

Next, you'll need to read
Bastille's explanations (Figure 3-15), answer its questions, and when you reach the
end, reboot to implement Bastille's changes.
That's really all there is to running Bastille.

3.2.4. Some Notes on InteractiveBastille

InteractiveBastille explains itself extremely
well during the course of a Bastille session. This verbosity
notwithstanding, the following general observations on certain
sections may prove useful to the beginner:

Module 1: Firewall.pm

Bastille has one of the better facilities I've seen
for automatically generating packet filters. By answering the
questions in this section, you'll gain a new script
in /etc/init.d, called
bastillefirewall, which can be used to
initialize ipchains or iptables, whichever your kernel supports. Note
that you must manually review and activate this script (i.e.,
double-check the script with your text editor of choice and then
create symbolic links to it with chkconfig).

Module 2: FilePermissions.pm

This module restricts access to certain utilities and files, mainly
by disabling their SUID status. The SUID problem is discussed in
Section 3.1.6, earlier in this
chapter.

Module 3: AccountSecurity.pm

This module allows you to create a new administration account and
generally tighten up the security of user-account management via
password aging, tty restrictions, etc. These are all excellent steps
to take; I recommend using them all.

Module 4: BootSecurity.pm

If it's possible for unknown or untrusted persons to
sit in front of your system, reboot or power-cycle it, and interrupt
the boot process, these settings can make it harder for them to
compromise the system.

Module 5: SecureInetd.pm

inetd and xinetd can pose
numerous security problems. This Bastille module configures access
controls for inetd or
xinetd services, depending on which is installed
on your system. If you're using
inetd, Bastille will configure
tcpwrappers; otherwise, it will use
xinetd's more granular
native-access controls.

Module 6: DisableUserTools.pm

The "User Tools" in question here
are the system's programming utilities: compilers,
linkers, etc. Disabling these is a good idea if this is a bastion
host. Note that as in most other cases, when Bastille says
"disable," it actually means
"restrict to root-access
only."

Module 7: ConfigureMiscPAM.pm

Several useful restrictions on user accounts are set here. Note,
however, that the file-size restriction of 40 MB that Bastille sets
may cause strange behavior on your system. Be prepared to edit
/etc/security/limits.conf later if this happens
to you.

Module 8: Logging.pm

Too little logging is enabled by default on most systems. This module
increases the overall amount of logging and allows you to send log
data to a remote host. Process accounting (i.e., tracking all
processes) can also be enabled here but is overkill for most systems.

Module 9: MiscellaneousDaemons.pm

In this section, you can disable a number of services that tend to be
enabled by default, despite being unnecessary for most users.

Module 10: Sendmail.pm

This Bastille module performs some rudimentary tweaks to Sendmail:
notably, disabling its startup script if the system is not an SMTP
gateway and disabling dangerous SMTP commands such as EXPN and VRFY
if it is.

Module 11: Apache.pm

This module addresses several aspects of Apache (web server)
security, including interface/IP bindings, server-side includes, and
CGI.

Module 12: Printing.pm

It's common for lpd, the
line printer daemon, to be active even if no
printers have been configured. That may not sound too frightening,
but there have been important security exposures in
lpd recently and in the past. This module
disables printing if it isn't needed.

Module 13: TMPDIR.pm

Since /tmp is world-readable and writable, there
have been security problems associated with its use. This module sets
up TMPDIR and TMP environment
variables for your user accounts; these variables define alternate
temporary directories that are less likely to be abused than
/tmp.

3.2.5. Bastille's Logs

So, after InteractiveBastille is finished and
the system is rebooted, what then? How do we know what happened?
Thanks to Bastille's
excellent logging, it's easy to determine exactly
which changes were successful and, equally important, which failed.

It's probably a good idea to review these logs
regardless of whether you think something's gone
wrong; meaningful logging is one of Bastille's
better features. Whether a beginner or a security guru, you should
know not only what changes Bastille makes, but how it makes them.

Bastille writes its logs into
/root/Bastille/log/ (Bastille's
home directory varies by distribution). Two logs are created:
action-log and error-log.
action-log provides a comprehensive and detailed
accounting of all Bastille's activities. Errors and
other unexpected events are logged to
error-log.

3.2.6. Hooray! I'm Completely Secure Now! Or Am I?

Okay, we've carefully read and answered the
questions in InteractiveBastille, we've rebooted,
and we've reviewed Bastille's work
by going over its logs. Are we there yet?

Well, our system is clearly much more secure than it was before we
started. But as Bruce Schneier is fond of saying, security is a
process, not a product. While much of the work necessary to
bastionize a system only needs to be performed once, many important
security tasks, such as applying security patches and monitoring
logs, must be performed on an ongoing basis.

Also, remember our quest for
"Defense in Depth": having
done as much as possible to harden our base operating system, we
still need to leverage any and all security features supported by our
important applications and services. That's what the
rest of this book is about.