Locking Down Linux with Bastille

Kristy Westphal

As is widely known throughout the security community, default installations of operating systems are not very secure with regard to file system permissions, services enabled by default, and access control settings. Although many vendors are attempting to make their operating systems better by default, there are still some basic checks that can be done to make a system even more secure.

This article is intended to introduce you to Bastille, an operating system hardening tool for the Linux environment. Furthermore, it is intended to explain exactly what Bastille does to help harden the Linux system.

Bastille is a modular Perl program developed by a collaboration of Jon Lasser and Jay Beale. More information can be found at:

http://www.bastille-linux.org

Bastille works not only on Red Hat, Mandrake, and Debian Linux, but also for HP-UX and Mac OS X. The operating system version used in this article is Red Hat Advanced Server, and it comes in RPM package or source tarball. The RPM version referred to here is Bastille-2.1.1-1.0.i386.rpm. To get started, you really only need access to the RPM file; however, if you want to use Bastille on several systems, you will want to use a config file (more on the config file later in this article).

Bastille helps automate and facilitate the hardening of a default installation. Doing the same steps by hand would take much longer than just running through the setup script. Bastille normally runs through a GUI that requires two additional Perl modules to run -- Tk and Curses. You can find the right version here:

http://www.bastille-linux.org/perl-rpm-chart.html

Running Bastille

Once you have downloaded the latest RPM file from the Bastille Web site, do the following steps (as the root user):

1. Install the rpm:

# rpm -ivh Bastille-2.1.1-1.0.i386.rpm

# bastille

You can get around the operating system guess errors by using the "- -os version" option at the command line, specifying which version you are indeed using. For Red Hat, you can utilize Bastille for versions starting from 6.0 (indicated by a "- - os RH6.0") up to Red Hat 9 (RH9). In my case, I let it choose which version was a close fit, because Advanced server was not an option.

Another feature of Bastille is that it is easy to uninstall. All of the original files are stored in /var/log/Bastillerevert/ directory, should you want to peruse just one file.

To revert your installation, simply do:

# bastille -r

Bastille is a truly community-driven project that encompasses many areas of security. The Perl scripts cover everything from the firewall module and bootup security, to PAM (pluggable authentication modules) and account security. Bastille also targets locking down inherently insecure services such as FTP, sendmail, and inetd. Let's take a closer look at what Bastille does to these areas.

Apache

Apache is a free Web server that gets installed in most installations of Red Hat. The easiest way to secure Apache is to simply turn it off, and this is the first question that Bastille asks you. Regardless of whether you turn off Apache, Bastille will assist you in locking down various areas that generally need to be addressed in default Apache installations.

The first Apache recommendation that Bastille makes is to bind the Web server to the local interface only. In this fashion, you can still make updates to the Web servers on the machine itself at http://localhost/, while the Web server still displays pages to browsers set at that server. You can also bind to a specific interface (not localhost) if you want.

Two other common security issues with Web servers are the following of symbolic links and server-side includes. Bastille turns off both of these. This prevents the use of symbolic links to see files that normally should not be viewed by the entire world. Server-side includes (SSIs) are commands in the HTML pages of a Web site that are processed on the server. If not well implemented, SSIs can access files on the server that were not intended to be accessed (like password files or other configuration files). Bastille can turn off SSIs for you.

Lastly, Bastille targets three other areas of Apache security: CGIs, the Apache index file (which you can choose to turn off), and chroot Apache. CGIs (Common Gateway Interfaces) often result in execution of programs on the Web server itself. If implemented well, this is not a problem, but if you are unsure of what the CGI scripts do on your server, it is best to disable them.

Chrooting Apache (either in the 1.3.x or 2.x tree) can be a handy feature. This will isolate your Web server to a limited file system. This, in turn, will limit where someone should be able to go on the system itself if they happen to break into something on your Web site. There are manual steps to be done after the installation of Bastille, but these are documented in the /var/log/Bastille/TODO file once the entire Bastille installation is completed.

Account Security

The highlights of the account security scripts include locking down r-services, assigning password-aging parameters, restricting who may use cron, the default umask settings, and restricting which ttys root can log in on.

R-services (meaning the use of services like rsh, rcp, and rlogin) utilize the .rhosts file to establish trust relationships between various hosts. Enabling these services can make it easier for an attacker to compromise security on more than one system, because the attacker can fake traffic to appear to be one user and jump to other host without a password. It is always recommended to do away with r-services, as well as telnet and FTP, and use something more secure, such as ssh, sftp, and scp.

Password aging is a very standard way to force users to periodically change their passwords. This is also not typically enabled by default. Therefore, it is recommended to set this parameter (Bastille sets it to 180 days; I recommend 90 days at a minimum). If you do want make the change to less than 180 days, you can change the parameter in the /usr/lib/Bastille/AccountSecurity.pm script.

Depending upon your policy, you may want to restrict who can use cron to schedule jobs on the system. If you do want to restrict access to cron by limiting it through the cron.allow script, then select this setting when running Bastille. You will need to go back later and modify the accounts you want to include in the file.

It is very important to have a strong default umask setting on your system. Why? Because it sets the permissions for all new files and directories created. Having more strict settings prevent unauthorized access to these items without having to manually set them each time you make something new. Bastille changes your settings to 077, which will translate into 700 (or owner full permissions, groups and others none) for all new files and directories (owner has all permissions, groups and others have none). It is easier to start strict and go back to more permissive setup if needed, so this is highly recommended.

Bootup Security

Bastille targets three boot settings that may require more stringent settings. These include: password protecting GRUB (the Grand Unified Bootloader), disabling CTRL+ALT+DELETE rebooting, and password protecting single-user mode.

Bootup security sometimes can be overkill for systems that are physically well protected. However, it can be necessary for systems that do not reside behind the closed doors of a data center. So, in this area, I recommend password protecting single-user mode no matter what the physical location; it's a good precaution to make sure that anyone who takes a system down to single-user mode actually belongs there. Otherwise, I would not necessarily recommend that you enable the passworded GRUB or disable CTRL+ALT+DEL for rebooting unless you have issues with protecting the system console.

PAM

Bastille addresses a few items regarding the Pluggable Authentication Module. These include the number of processes that each user is allowed (up to 150), and denying the capability for users to create core files. Both of these items are set in the /etc/security/limits.conf file and are handy because it restricts the amount of resources that users are able to consume on your system, thereby helping to prevent a denial-of-service attack.

Furthermore, you can restrict the use of console access only to those administrators who need it. This is an important additional layer of security for those systems not protected by a lot of physical security.

User Tools

Several tools accessible to all users may need to be further restricted, again depending upon the purpose of the machine. Bastille addresses whether compilers are truly needed, especially on an Internet-facing system where no compiling should be needed. Making these tools available allows easy compiling access for an attacker who just uploads his code and compiles it on the compromised machine to ensure that it will run properly on that operating system.

DNS (Domain Name Service)

If you are running the named daemon on your server, Bastille will ask you whether you want to put it in a chroot environment, limited only to the files that it needs. Doing so increases the security of DNS because it can run as a non-privileged user in the chroot environment rather than a normal daemon under root. If "named" is running, Bastille prompts you to turn it off if you are not going to use it. This is highly recommended even if you intend to use it later, because you can always turn it back on and configure it as needed.

File Permissions

File permissions are really at the heart of what Bastille does best. The default file permissions for most *nix installs are not the preferred level. Bastille looks at several types of files and permission combinations that should be revisited, such as: removing non-root access for certain administrative functions; scanning your system for world-writable files; changing access to suid (or scripts with sudo administrative access) such as mount, ping, dump; PCMCIA card access; at for job scheduling; DOS emulators; news; print; r-tools, user net control for user access to NICs; traceroute; and access to XWrapper and XFree86.

For any installation, it is wise to lock access to any program that requires pseudo-administrator privileges, so I would recommend these regardless of installation purpose.

Firewall

If you choose to enable the firewall packet filtering script, Bastille will walk you through various settings to help you configure your firewall. This is only a strong recommendation in two situations:

1. This is an Internet-facing box, and you want to add additional security beyond your border firewall.

2. This is an internal box, and you want to add additional security.

Furthermore, I would recommend that you initiate this setup if you want the server you are configuring to be a firewall or you want to implement Network Address Translation. If you are unfamiliar with using iptables or ipchains (the firewall that you will be using, depending upon which version of Linux you use), then you can simply accept the minimum security standard recommendations from Bastille. Otherwise, you can modify the setting after implementation.

Options provided by Bastille include: running FTP, mail (SMTP), and domain name service (DNS), designating which interfaces are trusted and which are public, logging on certain ports (always recommended if you can afford the processing time and disk space), anti-spoofing rules, rejecting traffic under certain circumstances, handling ICMP requests, NTP synchronization, and starting the firewall at boot time (also always recommended).

As an added bonus to your firewall configuration, Bastille includes the opportunity to install a port scan attack detector to work in conjunction with your firewall. It runs through the logs generated by your firewall to analyze whether certain types of traffic constitute a port scan. It has some features that make it very useful and worthwhile (e.g., timing of scans, what constitutes a scan), especially if you are relying on this server as your primary firewall.

This tool can also implement Snort Intrusion Detection System signatures if you want to incorporate that feature. A benefit of doing this would be that you would need an extra server to implement an IDS. However, you may find that traffic gets bogged down through your firewall, depending on what type of hardware you are using.

FTP

As Bastille mentions, FTP is generally an insecure service that should be avoided if possible. However, saying that and making it happen are often two different things, mostly because of the legacy issues that need to be overcome in order to stop using FTP. Knowing this, Bastille offers assistance in locking down the FTP daemon.

Items in the lockdown include: use of the FTP access file to restrict who can even use FTP, disabling anonymous access to the service, disabling Internet access to the service (if possible), and restricting the use of anonymous download.

Logging

Logging is the most useful tool for troubleshooting anything, but often gets overlooked in how much granularity is enabled. Bastille offers to help increase the granularity, adding kernel logging and messages of "warning" and "error", as well as process accounting. Increasing the level of logging always increases the amount of disk space needed, so be sure to balance this carefully.

Also, Bastille will send syslogs to an alternate remote server if you have central logging established in your environment.

Miscellaneous Daemons

Any good hardening tool will disable services that are installed by default but are not really necessary. Bastille addresses: apmd (which monitors battery power and is really only useful for laptops/notebooks), remotefs for use of NFS/Samba shares, nfs_server, PCMCIA, dhcpd, gpm (which adds mouse support to text mode), innd for news server, routed, gated, nis server, snmpd, pytdaemon, pwgrd, rbootd, xaccess, rendezvous, autodiskmount, and ntpd.

Printing

Bastille will turn off printing for systems that do not need to have a print daemon running.

Inetd

For older services that need to run through inetd, Bastille can configure tcpwrapper and xinetd services to deny all attempted connections by default. If you tend to use more secure services like ssh, and not telnet and FTP, and you want to have security above and beyond your firewall, you may choose to enable this option. This can be tricky if you aren't sure which services you need, so use with caution!

Otherwise, you can individually enable services, such as telnet or FTP. Banners for these services, which are often forgotten but nevertheless useful for legal purposes, can also be set with Bastille, if you still need to use FTP or telnet. Furthermore, you can list the owner of the system in the banner.

Sendmail

Unless your server is a mail server that needs to accept incoming mail, it advisable not to run sendmail in daemon mode. Bastille will not only do this for you, but it will configure cron to check the queue every 15 minutes and send any mail that it finds. It will also disable the use of vrfy and expn, which often can leak unwanted information about your mail users.

The tmp Directory

The /tmp directory often becomes an easy location in which an attacker can place files after compromising your system. By using the TMPDIR scripts proposed by Bastille (in conjunction with supporting the /etc/profile.d scripts), each user who logs in will create a /tmp directory that is safe for use. This can typically be implemented with minimal impact to the user system.

Running Bastille across Several Systems

While the GUI is descriptive and useful, it is not ideal when you need to install Bastille on many systems. The config file is a pre-configured setup file that Bastille needs to run. The config becomes established when you do your first installation of Bastille, saving all the settings in a text file so that you do not have to manually answer the questions for each installation. The assumption is that by using the config file, you can standardize security across your Linux systems. You can use the config file by using the "-b" option with the bastille command.

The caveat with using this config file is that Bastille independently examines every system that it runs on. If it finds something on a particular system not addressed in the config file, it will not run. You may see something like:

ERROR:   A fatal error has occurred. Not all of the questions
         that pertain to this system have been answered.  Rerun
         the interactive portion of bastille on this system.
         MODULE.QUESTION=FilePermissions.suidprint

/usr/lib/Bastille

# lprm=cancel / lpq=lpstat / lpr=lp (lp is the suid one)
   if (&getGlobalConfig("FilePermissions","suidprint") eq "Y") {
       &B_remove_suid(&getGlobal('BIN',"lpq"));
       &B_remove_suid(&getGlobal('BIN',"lpr"));
       &B_remove_suid(&getGlobal('BIN',"lprm"));
       if (&GetDistro =~ "^HP-UX") {
           &B_remove_suid(&getGlobal('BIN',"lpalt"));
       }           

FilePermissions.suidprint="Y"

Conclusion

This article has covered many security issues that must be addressed after the operating system has been installed. Although the thought of locking down the system may be daunting, tools like Bastille are available not only to assist you but also to help you learn why it is important to persevere in this process.

Resources

Apache Tutorial -- http://httpd.apache.org/docs/howto/ssi.html#whataressi

Bastille Web Site -- http://www.bastille-linux.org

Kristy Westphal, CISSP, is a versatile IT professional, skilled in information security, troubleshooting, and process analysis. Her experience in the Information Technology field has allowed her to become knowledgeable in several flavors of Unix and Windows, as well as various aspects of intrusion detection and disaster recovery planning. She is currently employed by Arizona Department of Economic Security as Information Security Officer.