Originally published at LinuxSecurity.com ( original article)
Recently I got an opportunity to speak with Jay Beale, the Lead Developer of the Bastille Project. Jay is the author of several articles on Unix/Linux 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. You can learn more about his articles, talks and favorite security links via http://www.bastille-linux.org/jay.
LinuxSecurity.com: Can you briefly describe the bastille-linux project? What is the goal/objective of bastille?
Jay Beale: Bastille Linux is a project to harden, or "lock-down," Linux systems. It asks the user a number of questions, which it uses to provide the most comprehensive security, without removing needed functionality. We're trying to make a more secure environment for every class of user, without restricting them too much.
We've been very successful so far - Bastille can stop almost every single root grab vulnerability that I know of against Red Hat 6.x. In the case of the well-known BIND remote root vulnerability, we had secured against that one before it was even discovered!
LinuxSecurity.com: How was it started?
Jay Beale: Bastille started about almost two years ago, when Jon Lasser began making UMBC Linux, a secure distribution that he could give out to students and faculty, without worrying that their new boxes would be quickly "rooted." While at a SANS conference, he met a number of people who were doing the same thing. Through a beer-enabled Birds of a Feather (BoF) session, they decided to stop duplicating effort, banding together to create the new Bastille Linux distribution.
Fast forward a few months. As many would-be distribution makers quickly learn, this group found out that making a new distribution was very hard work, before you even tried to secure it. They shifted strategy, and instead decided to modify the existing Red Hat distribution. This was faster and could be far more comprehensive. I joined up then, bringing a rather long Perl script with me that would turn a virgin Red Hat 6.0 box into more secure one. Jon and I became partners, Lead Coordinator and Lead Developer, and I posted a "modules wanted" sign in the form of a Spec Document for the script.
At that point, we were joined by the people that make up our core team, including Pete Watkins, who brought his strong and comprehensive IPCHAINS firewall, Sweth Chandramouli, who's helping me with architecture design, and Mike Rash, who's working on Intrusion Detection. We've got a great team on board, really, with a number of people dedicated to testing Bastille and generating ideas.
LinuxSecurity.com: Can you describe your background? How long have you been involved with security and Linux?
Jay Beale: Two years ago, I was a mathematician with an interest in computing and physics. I became interested in computer security when I took my first sysadmin job about two years ago. Security is one of the few areas of computing that is rather complex - yet, there's an underlying structure running through the entire field. It really fascinated me from the beginning, so I read everything I could find and started tinkering at home and at work.
Later on, I began working as a security admin., doing everything from writing host-based Intrusion Detection, to handling hacker break-ins, to writing hardening scripts. Bastille's main module development started as an extension of ideas I implemented for Solaris, actually. Now, I'm writing a book on applied Linux Security for Addison Wesley and writing articles for various sites, in addition to keeping up with Bastille, which is no small task.
LinuxSecurity.com: Do you ever expect vendors to ship Linux in a configuration that obviates the need for such a project?
Jay Beale: This really is possible, though it's a long shot... The problem is that users need their systems to "work" and, more and more, they don't have the time to tinker with them a great deal first. So, most vendors ship with ftp on, Apache with server-side-includes/cgi enabled, and no password on single user mode.
You see, to secure a system, you'll have to remove some functionality. This is due to a basic premise of computer security: to fully secure a system, you really have to grind it into dust, scatter the pieces to the wind, and hope that Entropy does it's part. Since you can't do this, you make tradeoffs.
I think things like Bastille will always be around for three reasons. First, vendors have incentives to make systems easy to use - Bastille works against this, but educates the admin/user to compensate. Second, we're going to keep researching, creating and implementing ideas before the vendors. Third, much of what we do isn't necessarily the vendor's "job" - implementing an intrusion detection system is usually a third party function. Bastille does a great deal to systems and we're about to start doing even more - we're growing beyond a simple hardening system into more facets of system security.
LinuxSecurity.com: What are the most difficult challenges you've faced while developing it?
Jay Beale: The toughest problems are really in the architecture, rather than features. Bastille's original goal to make a new distribution, press our own CD's and such. Then, we were still making a new distro, by installing Red Hat and modifying that directly after install. Now, we can modify a year-old system, but that took an architecture overhaul and an intense code audit to implement. This wasn't so much an added feature, as the problem was getting redefined after we implemented our first solution!
Actually, another problem that we're considering over time is that as Bastille does more and more, it has to ask a lot more questions! Right now, if you read all the explanations, it takes about an hour to run through the interactive portion. It's nowhere near as bad as a Linux kernel, but it annoys some users who just want a quick fix. Rather than abandoning these users, we're making "One Shot" configurations, where they can choose a sample configuration that matches their own and deploy that. While they miss a crucial part of securing the system (Secure the Admin!) they still get a safer system...
LinuxSecurity.com: What type of user would be most interested in running bastille?
Jay Beale: I think Bastille is accessible to every class of user, from the newbie to experienced admins. Every class of user tends to find it more comprehensive than anything they do by hand. Newbies find it useful because it explains everything it wants to do and asks questions, so as not to break anything. Experienced sysadmins find it useful because it automates what would normally take many man-hours, especially when you scale it to hundreds of systems. Further, many experienced sysadmins haven't ever had the time to learn about or implement security on their systems. They find themselves trying to make time, in the middle of the night, right after someone "hacks" their systems.
LinuxSecurity.com: What do you think of the state of security today on Linux?
Jay Beale: I think Linux security is getting better, but we're in a tough arena. Given the accessibility of Linux, most crackers have it on hand and are coding exploits for it first. Using Open source makes a program that much easier to audit for holes, so people are discovering some of the vulnerabilities very quickly and not all of them are White Hats. It's also a difficult situation, in that development is moving so much faster than audits.
Honestly, we've also got an amazing advantage: we've got the numbers, baby. The "Ping of Death" vulnerability was corrected in, if reports are to be believed, 1 hour for Linux. No vendor came close to that! While Linux may have had many more security vulnerabilities than Solaris in the past three years, these holes get patched a whole lot faster. Kurt Seifried's report on this noted that while Sun has, on average, only six announced vulnerabilities per year, it takes then around 90 days to fix them - this doesn't even account for all the programs, like WU-ftpd or BIND 8, that you generally add to a Sun box. The thing to remember, though, is that every operating system will have holes. It is human nature to make mistakes, no matter how many geniuses work on a system. Further, there are many creative, bright people in the cracking community - they will win many battles here.
LinuxSecurity.com: What features does it offer the average Linux user?
Jay Beale: Bastille is very accessible to the average user. It doesn't just start securing, but instead asks permission for every step it takes. Further, it educates. This key feature came out of a design problem I faced about a quarter way through writing the first script. The average Linux user tends to install their distro with everything installed and everything turned on, because they're not sure what it all does and they don't want to miss something. Bastille was asking the user questions, like "can we disable routing daemons?" when we hadn't explained what a routing daemon was or why they shouldn't need one. Pete and I ended up writing explanations for each question, so anyone could make educated choices, whether they were a newbie or an experienced sysadmin.
Bastille also has lots of other nice features: it can be re-run to keep a system secure after patches, everything it does can be undone, and it's fairly comprehensive. It tightens user account security, configures a well-tuned firewall, configures Apache, makes sane boot security choices, configures some smart PAM options, chroot's your DNS server, restricts access within your FTP server, sets better file permissions and audits your Set-UID root programs. It also configures stronger logging, locks down Sendmail a bit, and tries to turn off services and daemons that you don't need. This is really just the start, though! We're expanding this right now with new modules, including a basic network IDS system and a number of other modules under development.
LinuxSecurity.com: What new features are you working on?
Jay Beale: Expect some really incredible news on this in a few months. We're kicking around some great architecture ideas with the help of Yoann Vandoorselaere, from Mandrake. Sweth and others are helping us move rapidly to support far more than just Red Hat and Mandrake. We're eyeing FreeBSD, Solaris, Irix, Slackware, Debian and everything we can possibly generalize this to.
LinuxSecurity.com: What do you think are the biggest security concerns with using Linux today?
Jay Beale: Honestly, there aren't too many other security concerns that are specific to Linux. All of it generalizes to Unix and most of it applies to operating systems as a whole.
I think too many programs run with superuser privilege. We can kludge this, the way we do with programs that drop privilege, but we can also stop making this an all-or-nothing, user-or-root game. We should think beyond the basic security mechanisms present in Unix/Linux. Let's start implementing our programs using capabilities and dropping the number of programs on the system which use root.
Actually, I think computer security as a whole is a very tough problem. We're trying to make computers easier and easier to use, often at the cost of security. Cracker activity has grown immensely, as many more would-be script kiddies get Internet access. When I got my first shell account, the Internet was well known mostly among the University crowd - now, everyone's got access to the Internet and it's becoming a rougher neighborhood. I'm not saying world-wide Internet access is bad - it's an amazing resource, but one that some people are choosing to abuse.
LinuxSecurity.com: Security is always about tradeoffs. What tradeoffs do you face while developing bastille? Certainly it would be easiest to just remove rlogin, telnet, and other inherently-insecure programs, but this isn't always possible.
Jay Beale: Well, I think we've got a nice solution here. We're letting the user decide what tradeoffs to make and we're providing the user with the background to make that decision. Bastille is highly granular, taking many actions and asking the user about each one. In the end, the user decides whether or not to kill telnet, but we try to help them make an educated decision, by presenting facts like these: telnet is cleartext, so that someone eavesdropping can steal your account from under you - using programs like hunt, they can even steal your entire session!
Educating the end-user and letting them make all the decisions was a new approach, but we felt it was the only one that worked for a community as diverse in background as the Linux community.
LinuxSecurity.com: Thanks for taking the time with us today, and we wish you and your team members the greatest of success with this project!