Battening down the Hatches with Bastille

So, after InteractiveBastille.pl creates config and BackEnd.pl implements it, what then? How do I know what happened? Thanks to Bastille's excellent logging, it's easy to determine exactly which changes were successful and, equally important, which failed, and that makes this a good place to discuss running Bastille on non-Red Hat distributions.

As I mentioned earlier, while Bastille is optimized for Red Hat and Red Hat-derived Linux distributions (e.g., Mandrake, Yellow Dog, etc.), it is intelligent enough to work on others as well. And in fact, my own experience bears this out: I ran Bastille 1.1.0 on a system running SuSE Linux 6.3, and I'm pleased to report that far more of Bastille worked than not.

The first thing I noticed during my SuSE-6.3 Bastille session was that several actions are explicitly Red Hat-centric (InteractiveBastille.pl gives warning to that effect). Module 2, PatchDownload.pm, is strictly for Red Hat systems. And as noted above, Module 12, RemoteAccess.pm, installs the Red Hat i386 version of Secure Shell 1.2.27.

One other question in my session, regarding whether I should run named in a chroot jail [see “Paranoid Penguin: Securing DNS and Bind”, LJ October 2000] came with the same warning. Luckily, both downloading patches and configuring named to run chrooted are things one can do manually without too much trouble.

Although these were the only explicitly Red Hat parts that Bastille warned me about during the InteractiveBastille.pl session, there were other parts of Bastille that didn't deal with SuSE too well. BackEnd.pl returned no errors (to the console) at all; I wasn't aware that anything had failed until I read Bastille's logs.

Note that 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. And whether a beginner or a security guru, you should know not only what changes Bastille makes, but how it makes them.

Logically enough, Bastille writes its logs into /root/Bastille/log/. Two logs are created by BackEnd.pl: action-log and error-log. action-log provides a comprehensive and detailed accounting of all of Bastille's activities. Errors and other unexpected events are logged to error-log.

Most of the errors in my SuSE Bastille session involved files not residing where Bastille expected them. In a few cases this was due to SuSE keeping them in different places than Red Hat does; for example, Red Hat puts Apache (web server) configuration files in /etc/httpd/conf, whereas SuSe puts them in /etc/httpd. Bastille therefore failed to make any changes to Apache on my SuSE system.

In this example and most other file-location errors, it was fairly easy to figure out how to make the changes manually; Bastille's list of questions, /root/Bastille/Questions.txt, provides plenty of hints (easily found via grep), and if you understand Perl you can parse the scripts in /root/Bastille/Bastille to determine precisely what Bastille was trying to do.

The easiest thing to do, however, is simply to change the paths in the Bastille scripts and then rerun BackEnd.pl. Many of the paths that I needed to change for SuSE were in /root/Bastille/Bastille/FilePermissions.pl. For each file identified by error-log as missing, I simply checked for it using which. If it did indeed exist but in an unexpected location, I edited /root/Bastille/Bastille/FilePermissions.pl accordingly.

In the example below (an excerpt of the real error-log on my SuSE system) we see that Bastille couldn't find, setserial, chkconfig or ifdown:

#ERROR: chmod: File /bin/setserial doesn't exist!
#ERROR: chmod: File /sbin/chkconfig doesn't exist!
#ERROR: chmod: File /sbin/ifdown doesn't exist!

I happen to know that chkconfig and ifdown don't exist on SuSE systems; they're unique to Red Hat and its derivatives. Therefore those particular “errors” were moot. What about setserial? Entering the command:

which setserial

returned the output:

/sbin/setserial

Then, entering the command:

grep setserial /root/Bastille/Bastille/*

returned the output:

/root/Bastille/Bastille/FilePermissions.pm:  &B_chmod(0750,"/bin/setserial");

The which command told me where setserial lives on my system; the grep command told me which Bastille module and even which line I had to edit to fix setserial's path.

For a relatively small number of nonexistent files this was no big deal; for each file I determined whether it existed on my system and if so, where. I then verified that FilePermissions.pm was the offending module and edited it accordingly. Doing this for all the files cited in error-log and then rerunning BackEnd.pl took less than 20 minutes.

There was one other problem that needed fixing, and it's illustrated in the following example:

#open /etc/httpd/conf/httpd.conf.bastille failed...
#open /etc/httpd/conf/httpd.conf failed.
Couldn't replace line(s) in /etc/httpd/conf/httpd.conf
#open /etc/httpd/conf/httpd.conf.bastille failed...
#open /etc/httpd/conf/httpd.conf failed.
Couldn't replace line(s) in /etc/httpd/conf/httpd.conf because open failed.

As you can see, this was caused by the aforementioned difference between Red Hat's and SuSE's Apache environments. Again I used my handy grep command:

grep httpd.conf /root/Bastille/Bastille/*.pm

This returned several lines:

API.pm:  $GLOBAL_FILE{"httpd.conf"}=

API.pm:  $GLOBAL_FILE{"httpd_access.conf"}=

API.orig.pm:   $GLOBAL_FILE{"httpd_access.conf"}=

Apache.pm:  my $httpd_file=$GLOBAL_FILE{"httpd.conf"};

This told me that Bastille's Apache module references a variable called GOLBAL_FILE to store httpd.conf's path, and this variable is set in API.pm. Changing this path in API.pm and again rerunning BackEnd.pl (with everything commented out except the line invoking Apache.pm) was a trivial matter.

This may seem like a lot of tinkering for the sake of paranoia. But, even if Bastille succeeds in completing only 80% of its tasks on a non-Red Hat system, that system is still significantly more secure than it was before, right? Absolutely.

But Murphy's Law tells us that one of those utilities whose permissions Bastille couldn't tighten down could very well be the one that a mischievous user exploits to grant himself or herself root access. Taking the time to identify and correct these Bastille “hiccoughs” pays off, especially if you've got more than one system to harden. Obviously, the more systems of a given type that need hardening, the bigger the return on your time investment in customizing Bastille for that type.