Battening down the Hatches with Bastille
Okay, we've carefully read and answered the questions in InteractiveBastille.pl; we've run BackEnd.pl; we've checked Bastille's work by going over its logs, and we've gone back and rerun BackEnd.pl after tweaking a module or two. Are we there yet?
No, nor will we ever be! Security is a process, not a product. The surest way to create a vulnerable system is to plug it in, turn it on and forget about it, even if at some point prior to forgetting about it you hardened it.
Oops, I'm preaching—force of habit (I do this stuff for a living). Well, even in the immediate task of hardening our system, after running Bastille we've still got a few tasks left before taking a breather.
Remember back at the beginning of the article when I started preaching about the big trade-off that comes with functionality? One of the many ramifications of this is that even Bastille can only do so much; it's impossible to anticipate and create Bastille modules for every software package that might be installed in any given Linux distribution.
Some distributions, Debian and SuSE in particular, include an enormous number of packages—so many that in a recent Slashdot interview Bastille's Jon Lasser (see Resources) referred to them as being especially problematic as a result, from a security standpoint. He hastened to point out that this doesn't mean that systems with a lot of different software packages can't be secured; it simply means that it takes more work.
Therefore, be sure to do the following after running Bastille:
Disable Any Remaining Unnecessary Services: Check which services still have startup scripts in /etc/rc.d/rcX.d, where X is your default runlevel. (You can find your default runlevel with the command grep initdefault /etc/inittab.)
Startup scripts begin with a capital S. If you don't know what “Ssomedaemon” does, try man somedaemon. If you don't need it, then mv Ssomedaemon dis_Ssomedaemon (if it doesn't begin with S, the script won't be run at startup).
Take the Time to Learn and Secure Your Applications: Bastille makes it possible to secure a system before knowing very much about system security—that's why its creators have spent so much time adding educational content to it. But both the applications it secures and especially the ones it doesn't won't remain secure unless you invest the time needed to understand them.
BIND, for example, which provides DNS (name) resolution to network applications, has a variety of security features. Bastille configures some of them (on Red Hat and Mandrake, that is) but only scratches the surface. The Bind Operators' Guide and the named man page are required reading for any system administration who runs BIND, period. Put another way: RTFM!
Disable Any Remaining Unused User Accounts: One of SuSE's more annoying quirks is the inclusion of a long list of entries in /etc/passwd for application-specific user accounts regardless of whether those applications are even installed. While very few of these are privileged accounts, many can be used for interactive login (i.e., they specify a shell rather than /bin/false).
This is hardly unique to SuSE. Therefore, be sure to check /etc/passwd and comment out any unnecessary entries. If in doubt, change the final field (default shell) from a real shell to /bin/false—only actual user accounts need shells!
Maintain Your System Software: I've said it at least twice already, but there's no substitute for keeping current. Keep abreast of your distribution's security patches and bulletins! And as you learn more about Linux security, make sure you apply that knowledge to the stuff you installed back when you were a newbie. Do not hook your machine up to the Internet, power it up and forget about it.
Install an IDS: As soon as possible after installing the operating system, install Intrusion Detection software like tripwire or snort. It's the simplest thing you can do to minimize your chances of finding out from the wrong people (FBI, angry system administrators, etc.) that your system has been hacked and used to attack others. See Bobby S. Wen's article “Open-Source Intrusion Detection Tools for Linux” (LJ October 2000).
Monitor Your Logs: The last system-hardening tidbit I'll leave you with this month is the necessity of reading the logs you told Bastille to enhance. These logs are no good to you at all if you never open them.
Parsing log files can be tedious work though, so it's a good idea to either write scripts that periodically check the logs for suspicious activity, or install a tool like swatch, which does for log monitoring what Bastille does for system tightening. In fact, it's worth its own Paranoid Penguin column....
|September 2015 Issue of Linux Journal: HOW-TOs||Sep 01, 2015|
|September 2015 Video Preview||Sep 01, 2015|
|Using tshark to Watch and Inspect Network Traffic||Aug 31, 2015|
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
- Optimization in GCC
- Using tshark to Watch and Inspect Network Traffic
- September 2015 Issue of Linux Journal: HOW-TOs
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Firefox Security Exploit Targets Linux Users and Web Developers
- Where's That Pesky Hidden Word?
- My Network Go-Bag
- Doing Astronomy with Python