Automated Hardening with Bastille Linux

bnwThe Bastille Hardening program "locks down" an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. Bastille can also assess a system's current state of hardening, granularly reporting on each of the security settings with which it works.

Bastille currently supports the Red Hat (Fedora Core, Enterprise, and Numbered/Classic), SUSE, Debian, Gentoo, and Mandrake distributions, along with HP-UX and Mac OS X. Bastille's focuses on letting the system's user/administrator choose exactly how to harden the operating system. In its default hardening mode, it interactively asks the user questions, explains the topics of those questions, and builds a policy based on the user's answers. It then applies the policy to the system. In its assessment mode, it builds a report intended to teach the user about available security settings as well as inform the user as to which settings have been tightened.

Installing Bastille

To get the latest version of Bastille Linux, 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 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-chart.html.

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, 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

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 (pic below), answer its questions, and when you reach the end, reboot to implement Bastille's changes. That's really all there is to running Bastille.

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

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.

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.

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.

well hope this article will be inhelp for the LINUX NEWBIE's out there, now you can secure your own linux servers easily…. πŸ™‚

till next time ciao πŸ˜› 

Advertisements

About this entry