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....
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script