Battening down the Hatches with Bastille
Are you one of the many people who, when running ps -ef for the first time after installing Linux, has no idea what half of those processes are? Don't be embarrassed; we all have to start somewhere, and it takes time (and a lot of man-page lookups) to understand the myriad of applications and dæmons it takes to make a UNIX system run. While there's no substitute for doing those man-page lookups and truly understanding our systems, we shouldn't punish ourselves by running insecure systems until we've achieved guru status.
Bastille Linux, a powerful set of system-hardening Perl scripts, secures Linux systems and educates their administrators: when run in interactive mode it asks clear, specific questions that allow it to create a custom security configuration for your system. It also explains each question in detail so that by the time you've finished a Bastille session, you've learned quite a bit about Linux/UNIX security.
If you already understand system security and are only interested in using Bastille to save time, you can run Bastille in its “explain less” mode that asks all the same questions but skips the explanations. If you're running Bastille on a “clean” Linux installation, you can even skip the questions altogether and choose one of several “secure by default” security templates depending on what type of system you want. And if you're a real cowboy/girl, you can write your own Bastille configuration template from scratch (or, more likely, by tweaking one of the provided templates to fit your needs).
You may be thinking “Why does so much stuff have to be running and enabled by default? Isn't it silly to use special scripts just to trim the fat, when we could simply leave out all that fat in the first place?”
In my opinion most distributions of Linux do have too many things enabled by default. But the fact is that ever-increasing numbers of Linux users are absolute beginners, and if the first time they install and reboot their Linux system, it doesn't do very much (or worse still, doesn't work at all), then fewer people will stick with Linux and learn to run it securely.
In other words, Linux packagers (the people who create distributions such as Red Hat, Caldera, etc.) usually prefer to err on the side of usability rather than on security. Personally I wish more distributions offered both maximum functionality and “paranoid” configuration options in their installers. (Note that Red Hat 7.0's installer does in fact offer such options, although their “paranoid” option isn't necessarily as secure as a post-Bastille configuration.)
The original goal of the Bastille team (led by Jon Lasser and Jay Beale) was to create a new secure Linux distribution based on Red Hat. The quickest way to get their project off the ground seemed to be to start with a normal Red Hat installation and then to “bastillify” it (my term) with Perl scripts.
Before long, the team had decided that a set of hardening scripts that could be used on different distributions would be less redundant and more flexible than an entirely new distribution. Rather than moving away from the script approach altogether, the Bastille team has instead evolved the scripts themselves.
The Perl scripts that comprise Bastille Linux are quite intelligent and make fewer assumptions about your system than they did in the days when Bastille was meant only to be used on fresh installations of Red Hat. Your system need not necessarily be either a “clean install” or even Red Hat for Bastille to work, thanks to new functionality in version 1.1.x that transparently gleans a good deal of information about your system before making changes to it.
Okay, you're psyched and ready for automated, educational system-hardening. One little warning before we proceed: your mileage may vary. Although Bastille can be used on most Linux distributions, it started out as strictly a Red Hat utility and is still optimized for Red Hat and Red Hat-derived distributions. I'll offer some tips on using Bastille on non-Red Hat-derived distributions, but I can't guarantee your results. When in doubt, refer to Bastille's web page (see Resources).
Speaking of which, that's the home and definitive source of both Bastille Linux and its documentation. A link to the latest version of Bastille Linux can always be found in big bold letters near the top of the home page at http://www.bastille-linux.org/. Once you've downloaded the tarball, move it to /root and unpack it:
tar -xzvf ./Bastille-X.Y.Z.tgz
That's it, it's installed!
Note that Bastille expects to live in /root. You can probably hack the Bastille scripts to reflect some other home, but I don't recommend it as this is an unsupported action (and affects a lot of scripts). This shouldn't bother you; we usually don't get to choose where RPMs and other software packages get installed either.
Also, you need to have the Perl 5 scripting language installed in order to run Bastille Linux. To check your system for Perl (and its version) simply enter the command perl -v. If Perl replies with a version number less than 5.0, or if your system replies with perl: command not found then you need to upgrade or install Perl. No current Linux distribution lacks a Perl 5 package; refer to your Linux CD-ROMs or your distribution's home page to obtain a binary package for your system.
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
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)