How To Install and Use Bastille To Harden an Ubuntu 12.04

Status: Deprecated

This article covers a version of Ubuntu that is no longer supported. If you are currently operate a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:

See Instead:
This guide might still be useful as a reference, but may not work on other Ubuntu releases. If available, we strongly recommend using a guide written for the version of Ubuntu you are using. You can use the search functionality at the top of the page to find a more recent version.

Introduction

Bastille is an extremely useful tool for system administrators and Linux users of all levels looking to enhance or assess their level of security. At a first glance, Bastille itself [and its points of interest] might seem to be within the desktop computing domain. Moreover, it has recently lost its popularity, not being one of the go-to applications and becoming a not-cool tool amongst online communities.

However, Bastille is a true gem that should be praised generously; it's a wonderful system administration tool dedicated to the true art of not just OS (operating system) hardening but also security assessment and education.

In this DigitalOcean article, using Bastille, we are going to enhance the security of our system and greatly power up our knowledge and understanding of Linux system hardening by analyzing what Bastille in essence aims to teach with its thorough guide notes as we analyze various aspects of the process.

Hardening of Operating Systems

Operating system hardening (or simply hardening) is an umbrella term for actions taken by users (maintainers, system administrator etc.) with the goal of preventing intrusion attacks by malicious parties wanting to steal information, harm operations or cause damages in general as much as possible.

Security being one of those bottomless pits, no matter the effort spent or level of experience applied, no full proof solution can be reached and it is never safe to assume safety. The next unknown might come along in the form of an attack and take over.

However, luckily, when one acts with prudence the "unknown" today is an odd occurrence that cedes with the help of common knowledge, relatively mature(d) systems and simple to use tools such as Bastille that can be accessed by many with ease.

Some Common System Aspects Causing Vulnerabilities

As mentioned above, the number of things to look out for in order to enhance security is endless. Below, we will try to mention some of the [system] aspects that can cause vulnerability, giving way to attacks or actions causing harm.

Default operating system applications and its tools must be kept up-to-date.

Overloading the system with unnecessary applications with access to various system resources must be avoided in order to prevent exploits.

All unwanted (and unused) default executables / binaries and access methods must either be removed or disabled.

Strong password and key rotations must be set up for the system and its users to encourage password sharing and higher level dictionary attacks.

Account access must be disabled and locked down after too many repeating failures to log in to prevent brute-force attacks.

User level access must be limited on a strict regime to prevent root level access upon hijacking of a single account.

Logging in as root should not be permitted.

Intrusion preventing / fighting applications are better to be used as they can follow certain specific patterns to automatically fight some attacks.

Exposing the server to the outside world should not be done unless necessary -- better to opt in for internal network connections whenever possible.

Solid backup policy must be in place for recovery and ensuring data integrity.

Disk partitioning should be considered to prevent certain attacks aiming to make the disk inoperative for the system and its applications.

Responding to outside world and to look-up attempts should not be permitted unless necessary and application versions should be obscured to not to encourage certain application level fault exploits.

Datacenter auditing and physical server security must be ensured.

Hardening and Assessment with Bastille

Having talked about what Bastille is and going through some system aspects which can turn into vulnerabilities, we are ready to talk about what Bastille does.

Note: Given that Bastille will make system level changes (and important ones too!), it is recommended that you try it first on a fresh server installation. Also, please make sure to have backups (as always) before trying something new. When using Bastille, you are highly encouraged to read its explanations for the system tunings it will perform as they are extremely valuable. Here, we are working with Ubuntu Long Term Support (LTS) versions --10.04 and 12.04-- due to their maturity, stability and the long term support they get from the company. If you are using a non-LTS or one of the more recent versions, certain things (e.g. sources.list file) might appear a little bit different.

Preparing the system

As recommended, we should start with updating our system's application sources list (where package managers -- such as aptitude -- look for applications) and upgrading if necessary.

For Ubuntu, run the following:

sudo aptitude update
sudo aptitude -y upgrade

Installing Bastille Hardening and Assessment Tool

Depending on your version of Ubuntu, in order to get Bastille, you might need to enable the Universe repository (see the explanations below). Please follow along and try to install Bastille and if the package manager (aptitude) complains that it is unable to locate Bastille, continue to the following section (troubleshooting) and try it once again.

Close and save the file by pressing "CTRL+X" and confirming with entering "Y".

Upon adding the URL to the sources, you will need to update the repository list by executing:

aptitude update

Now you should be able to download Bastille as stated above via aptitude.

Using Bastille for Hardening

After installing Bastille, we are ready to work with it.

In order to run Bastille, run the following command:

sudo bastille

Note: Bastille has two working modes: CLI (command-line interface) and GUI (graphical user interface). If you were working with a desktop system with X-based interactive (graphical) interface, you could use its GUI by running sudo bastille -x instead (for which you might need to install the Perl's Tk module --aptitude install perl-tk).

Upon running the application, you will be shown a disclaimer regarding Bastille, its capabilities and what it will or will not do. Read the disclaimer carefully and type "accept" and press Enter in order to continue with the actual program. Read the second introduction screen where use of arrow keys and TAB is explained and again, press Enter to continue.

From now on you will be presented with questions one by one. You will be asked to answer them and for some, to enter text (such as warning messages). Please find the questions with explanations and recommended answers you should choose below.

Answering Bastille's Questions for Hardening

Questions:

Would you like to set more restrictive permissions on the administration utilities?

In general, the default file permissions set by most vendors are fairly secure. To make them more secure, though, you can remove non-root user access to some administrator functions.

If you choose this option, you'll be changing the permissions on some common system administration utilities so that they're not readable or executable by users other than root. These utilities (which include linuxconf, fsck, ifconfig, runlevel and portmap) are ones that most users should never have a need to access. This option will increase your system security, but there's a chance it will inconvenience your users.

Recommended answer is "Yes"

Before continuing with question number 2, you will be provided with further (and very helpful) explanations regarding "SUID". Press Enter to continue.

Would you like to disable SUID status for mount/umount?

Mount and umount are used for mounting (activating) and unmounting (deactivating) drives that were not automatically mounted at boot time. This can include floppy and CD-ROM drives. Disabling SUID would still allow anyone with the root password to mount and unmount drives.

Recommended answer is "Yes"

Would you like to disable SUID status for ping?

Ping is used for testing network connectivity. Specifically it's for testing the ability of the network to get a packet from this machine to another and back. The ping program is SUID since only the root user can open a raw socket. Since, however, it is often used only by the person responsible for networking the host, who normally has root access, we recommend disabling SUID status for it.

Recommended answer is "Yes"

Would you like to disable SUID status for traceroute?

The traceroute utility is used to test network connectivity. It is useful for debugging network problems, but it is generally not necessary, especially for non-privileged users. If non-root users will be needing to debug network connections, you can leave the SUID bit on traceroute. Otherwise, you should disable it.

Recommended answer is "Yes"

Should Bastille disable clear-text r-protocols that use IP-based authentication?

The BSD r-tools rely on IP-based authentication, which means that you can allow anyone with (for instance) root access on 192.168.1.1 have root access on 192.168.1.2. Administrators and other users have traditionally found this useful, as it lets them connect from one host to another without having to retype a password. The .rhosts file contains the names of the accounts and machines that are considered to be trusted. The problem with IP-based authentication, however, is that an intruder can craft "spoofed" or faked packets which claim to be from a trusted user on a trusted machine. Since the r-tools rely entirely on IP addresses (and remote username) for authentication, a spoofed packet will be accepted as real. Some of your users, or even possibly other administrators for this machine, might not be aware of the security problems with the BSD r-tools. If this is the case, they might create .rhosts files that would potentially allow crackers access to the machine. This option will disable the use of those r-tools both from your machine and as a means of logging into your machine.

Recommended answer is "Yes"

Would you like to enforce password aging?

Your operating system's default behavior, which we would change here, is to disable an account when the password hasn't changed in 99,999 days. This interval is too long to be useful. We can set the default to 60 days. At some point before the 60 days have passed, the system will ask the user to change his or her password. At the end of the 60 days, if the password has not been changed, the account will be temporarily disabled. We'll make sure this warning period is at least 5 days long. We would make this change in /etc/login.defs

Recommended answer is "Yes"

Do you want to set the default umask?

The umask sets the default permission for files that you create. Bastille can set one of several umasks in the default login configuration files. These cover standard shells like csh and most bourne shell variants like bash, sh, and ksh. If you are going to install other shells, you may have to configure them yourself. The only reason not to set at least a minimal default umask is if you are sure that you have already set one.

Recommended answer is "Yes" and opt for "077" (without quotes). Press TAB and Enter to continue.

Should we disallow root login on tty's 1-6?

You can restrict which tty's root can login on. Some sites choose to restrict root logins, so that an admin must login with an ordinary user account and then use "su" to become "root". This can stop an attacker who has only been able to steal the root password from logging in directly. He has to steal a second account's password to make use of the root password via the ttys.

Recommended answer is "No"

Would you like to password-protect the GRUB prompt?

If an attacker has physical access to this machine, and particularly to the keyboard, s/he could get super-user access through the Grand Unified Bootloader (GRUB) command line. We will look at other ways to prevent this later, but one easy way is to password-protect the GRUB prompt. If GRUB is password-protected, any user can reboot the machine normally, but only users with the password can pass arguments to the GRUB prompt. Note that this option can interfere dual-booting with a second operating system, since dual booting often requires that type an O/S name to boot one of the two operating systems. If this machine sits in a general purpose lab and dual boots, you probably shouldn't choose this option. Otherwise, this is strongly recommended for general use workstations and servers which are not locked away in their own room.

Recommended answer is "No" given you are on a virtual server.

Would you like to password protect single-user mode?

Anyone who can physically interact with your system can tell the bootloader to bring your machine up in " single user mode", where s/he is given root privileges and everyone else is locked out of the system. This doesn't require a password on most Unix systems. The method differs with the bootloader being used, thus on each operating system revision and architecture. You can test this attack on a Linux system that uses LILO by typing "linux single" at the LILO: prompt. Bastille can password-protect the bootprompt for you. You won't have to remember another password--single user mode, or "root" mode, will require the root password. We HIGHLY recommend that you password protect single user mode.

Recommended answer is "Yes"

Would you like to set a default-deny on TCP Wrappers and xinetd?

Not recommended for most users: Many network services can be configured to restrict access to certain network addresses (and in the case of xinetd services in Linux-Mandrake 8.0 and Red Hat 7.x, other criteria as well). For services running under the older inetd super-server (found in older versions of Linux-Mandrake and Red Hat, and current versions of some other distributions), some standalone services like OpenSSH, and --unless otherwise configured-- services running under Red Hat's xinetd super-server, you can configure restrictions based on network address in /etc/hosts.allow. The services using inetd or xinetd typically include telnet, ftp, pop, imap, finger, and a number of other services. If you would like, Bastille can configure a default policy for all inetd, xinetd, and TCP Wrappers-aware services to deny all connection attempts. While you might have already chosen to install Bastille's firewall , setting a default deny policy for these services gives more defense in depth. This will also configure xinetd so that the currently-installed xinetd services will use xinetd's more flexible access control and not/etc/hosts.allow. All other wrappers-based programs, like sshd, will obey the default-deny. As a special exception, Bastille currently allows "sshd" on a default-allow basis. If you wish this blocked as well, please change its line manually in hosts.allow.

Recommended answer is "No"

Should Bastille ensure the telnet service does not run on this system?

Telnet is not secure.

Telnet is shipped on most operating systems for backward compatibility, and it should not be used in an untrusted network.

Telnet is a clear-text protocol, meaning that any data transferred, including passwords, can be monitored by anyone else on your network (even if you use a switching router, as switches were designed for performance, not security and can be made to broadcast). Other networks can monitor this information too if the telnet session crosses multiple LANs.

There are also other more active attacks. For example, anyone who can eavesdrop can usually take over your telnet session, using a tool like Hunt or Ettercap.

The standard practice among security-conscious sites is to migrate as rapidly as practical from telnet to Secure Shell (command: ssh). We'd advise you to make this move as soon as possible. Secure shell implementations are available from openssh.org and ssh.com. Most Operating System vendors also distribute a version of secure shell, so check with your vendor first to see if there is a version that has been tested with your OS.

NOTE: Deactivating the "telnetd" service will not affect your telnet client.

Recommended answer is "Yes"

Should Bastille ensure inetd's FTP service does not run on this system?

Ftp is another problematic protocol. First, it is a clear-text protocol, like telnet -- this allows an attacker to eavesdrop on sessions and steal passwords. This also allows an attacker to take over an FTP session, using a clear-text-takeover tool like Hunt or Ettercap. Second, it can make effective firewalling difficult due to the way FTP requires many ports to stay open. Third, every major FTP daemon has had a long history of security vulnerability -- they represent one of the major successful attack vectors for remote root attacks.

FTP can be replaced by Secure Shell's scp and sftp programs.

NOTE: Answering "yes" to this question will also prevent the use of this machine as an anonymous ftp server.

Recommended answer is "Yes"

Would you like to display "Authorized Use" messages at log-in time?

At this point you can create "Authorized Use Only" messages for your site. These may be very helpful in prosecuting system crackers you may catch trying to break into your system. Bastille can make default messages which you may then later edit. This is sort of like an "anti-welcome mat" for your computer.

Recommended answer is "No" by default, "Yes" if you have other users.

Set and decide on the anti-welcome mat message and press *TAB** to continue.*

Who is responsible for granting authorization to use this machine?

Bastille will start to make the banner more specific by telling the user who is responsible for this machine. This will state explicitly from whom the user needs to obtain authorization to use this machine. Please type in the name of the company, person, or other organization who owns or is responsible for this machine.

Decide on the system owner's name and press *TAB** and then Enter to continue.*

Would you like to put limits on system resource usage?

Denial of Service attacks are often very difficult to defend against, since they don't require access of any kind to the target machine. Since several major daemons, including the web, name, and FTP servers, may run as a particular user, you can limit the effectiveness of many Denial of Service attacks by modifying /etc/security/limits.conf. If you restrict the resources available in this manner, you can effectively cripple most Denial of Service attacks.

If you choose this option, you'll be setting the following initial limits on resource usage:

The number of allowed core files will be set to zero. Core files can be useful for diagnosing system problems, but they are very large files and can be exploited by an attacker to fill up your file system. They can also be used to tune vulnerability exploitation tools. Finally, an attacker might use the core file from a crashed program to obtain privileged data that was dumped by the program.

Individual users are limited to 150 processes each. This should be more than enough for normal system usage, and is not enough to bring down your machine. (Linux only)

All of these values can be edited later.

Recommended answer is "No"

Should we restrict console access to a small group of user accounts?

Under some distributions, users logged in at the console have some special access rights (like the ability to mount the CD-ROM drive). You can disable this special access entirely, but a more flexible option is to restrict console access to a small group of trusted user accounts

Recommended answer is "Yes": Root

Would you like to add additional logging?

We would like to configure additional logging for your system. We will give you the option to log to a remote host, if your site already has one. We will add two additional logging files to the default setup and will also log some status messages to the 7th and 8th virtual terminals (the ones you'll see when you hit ALT-F7 and ALT-F8). This additional logging will not change the existing log files at all, so this is by no means a "risky" move.

Recommended answer is "Yes"

Set the logging and press *TAB** followed by Enter to continue.*

Do you have a remote logging host?

If you already have a remote logging host, we can set this machine to log to it.

Recommended answer is "No" unless you have, "Yes" otherwise.

Would you like to set up process accounting?

Linux has the ability to log which commands are run when and by whom. This is extremely useful in trying to reconstruct what a potential cracker actually ran. The drawbacks are that the logs get large quickly (a log rotate module is included to offset this), the parameters to commands are not recorded, and, like all log files, the accounting log is removable if the attacker has root. As this is rather disk and CPU intensive, please choose NO unless you have carefully considered this option.

Recommended answer is "Yes" or "No" depending on your preference.

Would you like to disable acpid and/or apmd?

apmd and acpid are used to monitor battery power and are used almost exclusively by notebook/laptop computers.

Recommended answer is "Yes"

Would you like to deactivate NFS and Samba?

We would like to disable the network file systems NFS (Network File System, common to most Unix variants) and SMB (Samba, which comes with most Linux distributions). We strongly recommend that you disable both of these. NFS has a history of major security vulnerabilities; Samba is slightly better, but it is still a shared file system and still raises potentially severe security concerns. Both services use clear-text, meaning that any data transferred can be monitored by anyone else on your network (even if you use a switching router , as switches were designed for performance, not security). Transferred data includes file handles, which can then be used to modify files.

These services are safer if you can set your firewall to block packets for either of them from entering or leaving your network, but it's probably best to deactivate them until you can investigate whether or not you need them and how to best secure them.

Recommended answer is "Yes"

Do you want to stop sendmail from running in daemon mode?

You do not need to have sendmail running in daemon mode to send and receive email, and unless you have a constant network connection, you probably cannot run sendmail in daemon mode. Daemon mode means that sendmail is constantly listening on a network connection waiting to receive mail.

If you disable daemon mode, Bastille will ask you if you would like to run sendmail every few minutes to process the queue of outgoing mail. Most programs which send mail will still do so immediately, and processing the queue will take care of transient errors.

If you receive all of your email via a POP/IMAP mailbox provided by your ISP, you may have no need of daemon -mode sendmail, unless you're running a special fetchmail-style POP/IMAP based retrieval program. For instance, you can turn daemon mode off if you read your mail via Netscape's common POP/IMAP read functionality. The only reason to run sendmail in daemon mode is if you are running a mail server.

Recommended answer is "Yes" but depends on your server's role.

Would you like to deactivate the Apache web server?

Will you be using the Apache web server immediately? Again, minimalism is a critical part of a good site security. If you don't need to run a web server, at least not right now, you should deactivate it.

You can restart the web server later by typing: /sbin/chkconfig httpd on

This is only recommended if this machine will not be used for printing in the near future. If you deactivate this, you might want to write down the commands above in case you decide to re-enable printing later.

Recommended answer is "Yes" for servers.

Would you like to disable printing?

If this machine is not going to need to print, you should stop the print scheduler and restrict the permissions on all the printing utilities.

This is only recommended if this machine will not be used for printing in the near future. If you deactivate this, you might want to write down the commands above in case you decide to re-enable printing later.

Recommended answer is "Yes" for servers.

Would you like to install TMPDIR/TMP scripts?

Many programs use the /tmp directory in ways that are dangerous on multi-user systems. Many of those programs will use an alternate directory if one is specified with the TMPDIR or TMP environment variables. We can install scripts that will be run when users log in that safely create suitable temporary directories and set the TMPDIR and TMP environment variables. This depends on your system supporting /etc/profile.d scripts.

Recommended answer is "Yes" if a multi-user system "No" if it is not.

Would you like to run the packet filtering script?

Using the packet filtering script, you will be able to do packet filtering/modification via the Linux kernel. You can use this to block certain types of connections to or from your machine, to turn your machine into a small firewall, and to do Network Address Translation (also known as "IP masquerading"), which lets several machines share a single IP address.

If you install the packet filtering script, it will create firewalling instructions for you. You will be prompted to make various choices (with suggested defaults), but you may need to edit it for your particular site and WILL need to individually activate it.

Recommended answer is "No" but depending on your objectives, it can be "Yes".

Approving Changes To Be Made

Upon answering all the questions, you will be prompted to ensure that you are done with it. After giving your confirming Bastille will do its job and show you (literally) the credits.

You can press Enter to return to the Linux shell.

Reverting Back Bastille's Changes

If you decide to revert the changes Bastille has made to your system, you can do so by executing the following command:

sudo RevertBastille

This is going to undo everything and you if you need Bastille again, you be required to go through each step one by one.

Note: Usually operating systems already come with many security options set correctly and for your benefit by default. After having reverted Bastille's changes, do not be alarmed if you see that some things haven't changed: that's because system defaults.

Using Bastille for Assessment

As we have mentioned at the beginning of the article, Bastille is also a great system security assessment tool as it provides you, very simply, an excellent report on certain aspects of possible vulnerabilities.

Generating the Assessment

In order to obtain an assessment report, run the following:

sudo bastille --assessnobrowser

After completing the tests, Bastille will tell you something similar to:

Bastille Hardening Assessment Completed
You can find a report in HTML format at:
file:///var/log/Bastille/Assessment/assessment-report.html
You can find a report in text format at:
/var/log/Bastille/Assessment/assessment-report.txt
You can find a more machine-parseable report at:
/var/log/Bastille/Assessment/assessment-log.txt

Viewing the Assessment Results

In order to view the assessment report, we will open up report in text format using a text editor (nano).

$ cat /var/log/Bastille/Assessment/assessment-report.txt

Here, you will be able to obtain a summary of what the settings are on your system regarding various aspects of security.

Also by looking at the end of the document you can learn your security level scored by Bastille.