|
You use a "hardening program" to try to make your system as secure as possible, from the ground up. Generally, you deactivate unnecessary services and better the configurations of the ones you leave enabled. This is wildly effective, as it can eliminate many of the vulnerabilities that are common on Linux/Unix platforms. This article presents a walkthrough of Bastille Linux, a popular hardening program for Red Hat and Mandrake, available for free from Jon Lasser, Pete Watkins, myself, and the rest of the Bastille Linux project. This walkthrough won't be the kind of "paranoid" setup that I enjoy most, as that could remove too much functionality for the average reader. Don't worry - I'll explain what we'll break in each setting, how we'll break it, and how you can fix it. But first, a shameless plug: I'll let you know about the cool features in the newest Bastille version, which we've just released.
Cool Features in Bastille Linux 1.1:
-
Bastille now runs on Non-Virgin systems!
Bastille is now much smarter, allowing it to run on systems that have been in use for a while. It uses pattern matching - based API routines and has a whole lot more of them. It also assumes a lot less about the state of the target machine.
-
Bastille can now be run multiple times!
Again, Bastille is much more intelligent. It shouldn't make improvements that are already in place, whether they were made by you or by the program on a previous run.
-
Undo functionality implemented!
Every single file change is backed up in an undo directory, with the directory structure preserved and permissions left alone. You can back out individual changes made by Bastille or simply back out everything altogether!
-
Impotent (log only) mode added!
While the logging is a little rough, Bastille can log every action it would have taken on your system without actually taking those actions!
-
Non - Red Hat / Mandrake support is much fuller now.
Bastille can now be more easily extended to other distributions of Linux, as we've removed most Red Hat specific content. Most of our modules will run on any distribution, as soon as we code the binary locations into our ConfigureForDistro() subroutine.
With all that said, please be assured that development is continuing. We're implementing even more cool functionality and we're all quite sure that Bastille is, and will continue to be, one of the most full-featured hardening programs out! Got a suggestion? E-mail me at jay@bastille-linux.org. With that said, let's get to the walkthrough!
Starting The Walkthrough:
At the time of this writing, Bastille 1.1.0 has been released. It might be a little rough around the edges, but if something doesn't work as planned, it can be easily undone or we can release a quick fix. I'm recommending this version specifically because the new architecture is much more featureful. Let's download, install and run Bastille on an x86-based Red Hat 6.x box. First, switch to console mode. While Bastille uses a GUI-like (curses-based) Text User Interface, it's still a console tool that runs best on a standard size 80x25 screen.
( Hit
Bastille starts with the four most powerful steps you can take to secure a Linux/Unix box:
-
Apply a firewall (packet filter) to prevent access to possibly vulnerable services
-
Apply system patches for all known security holes
-
Perform a SUID - root Audit
-
Deactivate or restrict unnecessary services
Let's step through these...
(Module: IPCHAINS)
Bastille starts by offering to configure a firewall. While this is not all that is required to secure a machine, firewalls can be great start. They function to block network traffic from hitting your machine's network daemons. Why not just secure the daemons or deactivate them? Actually, we'll take all three of these actions. Why not just do one or the other? The answer is a basic tenet of operating system security: Defense in Depth.
Defense In Depth
Protect each service or possible vulnerability through multiple means, so that if one fails, the remaining methods keep your machine from being compromised.
To keep this article from getting too deep too fast, we'll skip firewalling for now. Bastille has very good explanations in the IPCHAINS module - further, the default answers should be fairly safe. Unfortunately, this module is long enough to necessitate its own walkthrough. Look for a future article, Real Soon Now on this topic.
Q: Would you like to run the ipchains script? [N]
A: N
(Module: Patch Download)
Bastille now tells us about downloading new patches. This is VERY important. Bastille can minimize damage from vulnerable services through preventive measures, but it really is most effective to patch the security holes in the first place! Most operating systems (save OpenBSD) seem to release with vulnerable programs, some of which can be abused to gain root on your system. If you're still not patching, please remember the remote vulnerability present in Red Hat 6.0's BIND version... This step, however, is best done manually...
Q: Would you like to download and install updated rpms?
A: N
(Module: File Permissions)
Now we'll audit file permissions. If you're an advanced user, you may use the general permissions audit. This audit, adapted from a SANS document, restricts permissions on many binaries. Most people should choose N here.
Q: Would you like to set more restrictive permissions on the administrative utilities? [N]
A: N
Now we get to that third "most powerful action" quoted from above: the SUID Audit. Bastille lets us strip the SUID bit on about half of the SUID programs on a Red Hat 6.x or Mandrake system. Since this is the non-paranoid run, we won't disable all of them...
We'll leave the SUID bit on mount/umount, so that ordinary users can still mount floppies and cdroms.
Q: Would you like to disable suid status for mount/umount?
A: N
We'll also leave ping and traceroute active, so ordinary users can test network connectivity. These are really not needed, but I am attempting to be less paranoid, in the name of user convenience.
Q: Would you like to disable suid status for ping?
A: N
We'll strip the SUID bit from dump and restore, which are used for system backups. Root can take care of system backups.
Q: Would you like to disable SUID status for dump and restore?
A: Y
We'll also rip SUID status off of cardctl, which is used to configure PCMCIA services - you can answer N here if you're running a notebook.
Q: Would you like to disable SUID status for cardctl?
A: Y
We'll also rip SUID status off of at, because it has had a rich history of security problems. You can achieve all the same functionality with cron, so this is safe.
Q: Would you like to disable SUID status for at?
A: Y
We can safely tear SUID off of dos (dosemu). Dosemu is a DOS emulator for Linux and, as such, is very open to manipulation by the user. It also is used by few users - feel free to re-enable suid if you're planning on making this available to many users.
Q: Would you like to disable SUID status for DOSEMU?
A: Y
It is also very safe to remove the SUID bit from the news (UseNet) server control utilities, inndstart and startinnfeed. Most people reading this article aren't running a news server on their machines... Even if they were, only root should be starting the news server! Ordinary users can read news without needing to be able to start a news server, especially since most people read UseNet via their ISP's news server.
Q: Would you like to disable SUID status for news server tools?
A: Y
We'll leave the SUID bit on the printing utilities, though you should disable these if your machine won't be used for printing.
Q: Would you like to disable SUID status for printing utilities?
A: N
Now, we get to one of my favorite topics, the Berkeley r-tools, like rcp, rlogin and rsh. These harbingers of doom use IP addresses for authentication, which unfortunately is not a suitable method of authentication. Trust me here, turn these the heck off!
Q: Would you like to disable SUID status for the r-tools?
A: Y
We'll slip back to permissive mode now, and leave SUID on usernetctl. This utility is used by ordinary users to activate and deactivate network interfaces, like their dial-up modems. Feel free to leave this on...
Q: Would you like to disable SUID status for usernetctl?
A: N
Q: Would you like to disable SUID status for traceroute?A: N
Now, I promise there aren't so many questions in most of the other modules!
Module: Account Security
Bastille now moves to Account Security, which is not the last of the four "most powerful steps" that I outlined above. Don't panic! We'll come back to that one... Often a system cracker starts by stealing one of your user's accounts or by compromising a non-user account. The AccountSecurity module enforces some Best Practices and creates a few tricks, as we'll show below.
We'll create a second superuser account. You should use this for root activities and leave the root account untouched.
Q: Would you like to set up a second UID 0 account?
A: Y
Bastille will now request permission to disable the Berkeley r-tools: rsh, rlogin, rcp by making PAM modifications, commenting out lines in inetd.conf, and removing all permissions on these binaries.
Q: May we take strong steps to disallow the dangerous r-protocols? [Y]
A: Y
We'll now elect to enforce password aging, to freeze unused accounts before they can be used to compromise your system.
Q: Would you like to enforce password aging? [Y]
A: Y
If you haven't created an ordinary user account, you should let Bastille do this for you. Otherwise, skip it like so:
Q: Would you like to create a non-root user account? [N]
A: N
We'll restrict most users from using cron - it represents a double risk: first, it runs as root and might be open to compromise. Second, an attacker can use cron to hide commands and run them outside of the interactive sessions that you'd be able to monitor easily.
Q: Would you like to restrict the use of cron to administrative accounts? [Y]
A: Y
We'll also go ahead, in the future, and assign a restricted/useless shell, like /bin/false, to all non-user accounts.
Module: Boot Security
Interestingly enough, in Red Hat 6.0, anyone who can get to a LILO prompt can have root on your system! Try this at the LILO prompt: type "linux single". You'll find yourself with a nice root shell! If we deactivate that, you can still type at the LILO prompt: linux init=/bin/bash. We can do something about this.
Q: Would you like to password-protect the LILO prompt? [N]
A: Y
Q: Enter LILO password, please. []
A: put-in-your-own-password-please-or-you've-done-something really-dumb
This solution actually prevents both of the exploits above, as it protects the LILO prompt. We can protect this prompt further by not giving an attacker any chance to even try a password...
Q: Would you like to reduce the LILO delay time to zero? [N]
A: N
We can write this lilo configuration to our hard drive or to a pre-made boot floppy, or both. Supposing that we boot from your hard drive only:
Q: Do you ever boot Linux from the hard drive? [Y]
A: Y
Q: Would you like to write the LILO changes to a boot floppy? [N]
A: N
We could disable CTRL-ALT-DEL rebooting, but this doesn't always make sense.
Q: Would you like to disable CTRL-ALT-DELETE rebooting? [N]
A: N
We can take one final step to prevent the "LILO: linux single" root-grab. Remember: Defense in Depth!
Q: Would you like to password protect single-user mode? [Y]
A: Y
Module: SecureInetd
OK, back to the fourth of the "four most powerful steps." Our last "powerful" step, restricting and deactivating unnecessary services, follows from another basic tenet of system security: Minimalism.
(Applied) Minimalism
Since crackers may discover an exploitable vulnerability in any service running with privilege, minimize both the number of these services and their levels of privilege.
This principal will save your butt over and over. A Red Hat 6.0 box running with "Everything" installed and every service active can be rooted remotely rather easily through, among other things, its Name Server. If you take the five minutes to turn this off, you win! If you had to leave it on, but you lower its level of privilege by setting it to run as an ordinary user, you win again. Otherwise, you can be rooted by the least experienced script kiddie.
We'll start the process of restricting unnecessary services by changing /etc/inetd.conf and the TCP Wrappers /etc/hosts.allow file. We'll disable telnet, ftp, pop, imap, rsh, rlogin, and talk. Pop and imap are mail protocols that should be disallowed unless you really do use them. Telnet, rlogin and rsh are all horribly insecure and can be replaced by ssh. Often, rcp and ftp can be replaced by the much safer scp. We remove talk simply because we don't need it.
Q: Would you like to modify inetd.conf and /etc/hosts.allow to optimize use of Wrappers? [Y]
A: Y
You can turn these back on, or allow them from required systems, by editing the /etc/hosts.allow file. Try: man hosts_access. Moving on, we'll choose to leave ssh open to the entire Internet, for now.
Q: Would you like to set sshd to accept connections only from a small list of IP addresses. [N]
A: N
Finally, we'll choose to add "Authorized Use Only" banners to the system. These are often required to successfully prosecute system crackers.
Q: Would you like to make "Authorized Use" banners? [Y]
A: Y
Module: DisableUserTools
Following the principle of Minimalism, we can now set permissions to only allow root to use the compiler. If you need users to run this, please don't choose Y here.
Q: Would you like to disable the compiler? [N]
A: Y
Module: ConfigureMiscPAM
Sidetracking from the "minimalism" stuff, we make some modifications that should make it difficult for any one user, including the "nobody", "web" or "ftp" users, to abuse system resources to cause a Denial of Service (DoS) attack.
Q: Would you like to put limits on system resource usage? [Y]
A: Y
Q: Should we restrict console access to a small group of user accounts? [N]
A: N
Module: Logging
We'll add some additional logging to the system, creating special logs for kernel messages and severe error messages and, furthermore, logging important information to two virtual TTY's. After we're done, you'll use
Q: Would you like to add additional logging? [Y]
A: Y
Unless you have a remote logging host, we'll answer the next question like so:
Q: Do you have a remote logging host? [N]
A: N
Process accounting logs every process as it starts. If you've got the disk space and CPU time to spare, or are very paranoid, this can be very useful. Most people shouldn't touch this.
Q: Would you like to set up process accounting? [N]
A: N
Module: MiscellaneousDaemons
We now get directly back to our Minimalism-motivated process. We'll turn off every system daemon that you don't need. In this walkthrough, we turn most everything off. You can turn it back on with the command chkconfig .
Q: Would you like to disable apmd? [Y]
A: Y
Q: Would you like to deactivate NFS and Samba? [Y]
A: Y
Q: Would you like to disable atd? [Y]
A: Y
Q: Would you like to disable PCMCIA services? [Y]
A: Y
Q: Would you like to disable the DHCP daemon? [Y]
A: Y
Q: Would you like to disable GPM? [Y]
A: Y
Q: Would you like to disable the news server daemon? [Y]
A: Y
Q: Would you like to deactivate the routing daemons? [Y]
A: Y
Q: Would you like to deactivate NIS server and client programs? [Y]
A: Y
Q: Would you like to disable SNMPD? [Y]
A: Y
Module: Sendmail
Continuing to follow the principle of Minimalism, we can now deactivate sendmail's "listen mode." It will still be available to send mail off the system, but won't receive any from the network. If you need to receive mail via sendmail, choose Y:
Q: Do you want to leave sendmail running in daemon mode? [Y]
A: N
To disable automated sendmail altogether, we'd choose N for the next question.
Q: Would you like to run sendmail via cron to process the queue? [N]
A: Y
Finally, we'll disable some sendmail commands that are commonly used to gain information about your system for cracking or spamming.
Q: Would you like to disable the VRFY and EXPN sendmail commands? [Y]
A: Y
Module: RemoteAccess
You should install Secure Shell (ssh) on every system that needs remote access, though you may want to do it manually.
Q: Would you like to download and install ssh? [N]
A: Y
Module: DNS
You might notice a strange practice in the remaining modules: we tighten services that we turn off. We recommend you do this because you never known when you might have to turn them back on. Paranoid, yes, but from experience, a sound practice.
We secure DNS initially by running it as an ordinary user and restricting (chroot-ing) it to a small subset of the filesystem. This turns the recent BIND (DNS) exploit from a root-grab into DNS server Denial of Service (DoS). Actually, we (and the guys at SANS) implemented and suggested this months before the exploit was found.
Q: Would you like to chroot named and set it to run as a non-root user? [N]
A: Y
Q:Would you like to deactivate named, at least for now? [Y]
A: Y
You'll have to get used to two small changes in the way your admin your DNS server when you do this - read the Bastille explanations carefully.
Module: Apache
Unless you'll be using your web server immediately, we'll turn it off for now. Reactivate it later with chkconfig httpd on.
Q: Would you like to deactivate the Apache web server? [Y]
A: Y
If you only need the webserver to test web pages that you're working on locally, we can bind it to a your local interface. We could also bind it to only one interface (like your ethernet card, but not your PPP link.) I assume here that your web server must be viewable by the entire internet.
Q: Would you like to bind the web server to listen only to the localhost? [N]
A: N
Q: Would you like to bind the web server to a particular interface? [N]
A: N
We have more choices than just deactivating Apache. While Apache has some nice features, we'd prefer to disable features we aren't directly using. Apache can follow symbolic links, so that if one of your users makes a link from his web directory to /, Apache can show any user-viewable file to the entire Internet! We'll turn this off:
Q: Would you like to deactivate the following of symbolic links? [Y]
A: Y
Server side includes aren't used by most casual users. They can be rather dangerous.
Q: Would you like to deactivate server-side includes? [Y]
A: Y
CGI scripts incredibly useful on servers - simultaneously, badly written CGI scripts represent one of the most common methods of system compromise today. Decide carefully: will you be writing, downloading or buying CGI scripts? Many conscious sites run them on only some servers and then only after auditing each CGI script for problems.
Q: Would you like to disable CGI scripts, at least for now? [Y]
A: Y
Lastly, we think about indices. In the absence of a index.html file, Apache will list all files in the current directory. These aren't as bad as symbolic links, since they don't enable an attacker to see files outside the web directories.
Q: Would you like to disable indexes? [N]
A: N
Module: Printing
If your box isn't being used to print, we can disable the printing daemon and strip SUID from lpr and lprm, like so:
Q: Would you like to disable printing? [N]
A: Y
Module: FTP
Last module! Anybody tired yet? We now can prune back the access of the FTP daemon, wu-ftpd. From a security perspective, FTP is a very problematic protocol. Further, wu-ftpd has had a number of security alerts lately. Most security-conscious people try to avoid running an ftpd like the plague and you might want to follow their example. Even if you can, let's prune this daemon.
Of all possible configurations, the worst is one that allows anonymous upload. Luckily, this is not the default configuration! Still, Red Hat's default configuration allows user/password access as well as anonymous download. You can deactivate one or both of these. Here, we deactivate only user ftp access:
Q: Would you like to disable user privileges on the FTP daemon? [N]
A: Y
Q: Would you like to disable anonymous download? [N]
A: N
Wrap-Up:
OK, that's it. We've made our choices in the front end, which should now create a configuration file. Let's implement these choices like so:
( Exit from the Credits screen by pressing Tab )
# ./BackEnd.pl
Your changes should now be implemented. You'll find your machine to be slightly less functional, but only in ways that you chose. You'll find backup copies of every configuration file changed in /root/Bastille/undo/backup. Reboot your machine and notice the changes. An attacker will find far fewer avenues of attack against your machine, depending on what options you picked.
Jay Beale is the Lead Developer of the Bastille Linux Project (http://www.bastille-linux.org). He is the author of several articles on Linux/Un*x security, along with the upcoming book "Securing Linux the Bastille Way," to be published by Addison Wesley. At his day job, Jay is a security admin working on Solaris and Linux boxes.
|