November 4, 2002

Bastille's Beale: How to avoid security problems, Linux vs. Windows security

-By Grant Gross -

If it's not the Slapper worm, it's the Mighty worm -- if you're watching the technology press recently, you might think Linux is plagued with security problems lately. And then there's the never-ending Linux vs. Microsoft security debate, revived by Newsfactor a couple of weeks ago.

We went to Jay Beale with our questions about the current state of Linux security. He's a security consultant specializing in host lockdown, network security and security audits. Jay also serves as lead developer of the Bastille project, which creates a hardening script for Linux and HP-UX, is a member of the Honeynet Project, and is a core participant in the Center for Internet Security.

More about Jay: He writes the Center for Internet Security's Unix host security tool, currently in use worldwide by organizations from the Fortune 500 to the Department of Defense. He maintains the Center's Linux Security benchmark document and, as a core participant in the non-profit Center's Unix team, is working with U.S. agencies to develop a Unix security standard for industry and government. A former security team director for MandrakeSoft, he is currently finishing the Addison Wesley book, "Locking Down Linux the Bastille Way."

Read on for Beale's take on how you can make your system more secure, on the Linux vs. Windows security debate, and on the Digital Millennium Copyright Act's impact on security testing. It seems as if malicious hackers are targeting Linux more lately, perhaps
because of its growing popularity. Recently, there have been reports of the
Slapper and Mighty worms. Do you see that trend?

Beale: I really don't see that kind of trend here. Most of the vulnerability
hunting that gets done isn't really this targeted. It's much more
opportunistic. People found some juicy vulnerabilities in Apache and
wrote exploits. A little later, people start writing worms to
automate the process. This happens often enough. Honestly, I feel
safer on Linux partly because worms are such a rare occurrence, compared
to the Windows world, which has to spend so much time fighting each and
every one. So far, we've been a lot safer on Linux.

In terms of people attacking Linux instead of Windows, I'm very
encouraged by the chart on, which shows that the
top attacked port by a wide margin is 137, used for Windows filesharing
and such. Port 80, which includes all the Slapper/Mighty worm activity,
appears to show at most half that much activity!

Anyway, I wouldn't throw out your Linux box just yet! If you had to name a couple of top security risks for Linux sysadmins these days, what would you say?

Beale: The most recent risk has been back-doored software, where Bad Guys break into the distribution Web site for, say, sendmail, and replace the current
sendmail distribution source with a trojan'd one. The compilation or
installation process for this sendmail will set up a backdoor, like a
root shell listening to a particular port. You've just downloaded
sendmail from the primary distribution site and been hacked by the
install process!

The only way to avoid this is to immediately start checking PGP/GPG
signatures on every single source or binary package you download. MD5s
aren't good enough -- anyone who can replace the package can also replace
the MD5 listed in the same place. PGP signatures can only be modified
if the attacker can get the maintainer's private key, which is extremely
rare. How rare?

Beale: I've never heard of it happening. What other risks exist?

Beale: Well, the top risk always seems to be our users. (laughs) My colleagues
who have users telnet-ing around between machines probably have it worst,
because sooo many passwords are stolen this way. Someone using a cleartext
authentication method like telnet is just asking to have their password
eavesdropped on and their account used by Bad Guys to break into servers.

While we're on passwords, there's another tough one that comes with hosting
users. The more users you have, the greater the chance that someone's
using an easy password, like one that's in a dictionary or even one that's
in a dictionary with a "1" appended. Actually, if your site is large enough,
there's a pretty good chance you have a few users who have either their username
as their password or your default starter password, like "changeme." If you
put me through some kind of Swordfish movie-related challenge to break into
your many-user Unix box without any "hacker tools," I wouldn't try to break
the encryption or find an exploit against the ssh daemon -- I'd be brute
forcing passwords!

The last major risk out there is just the sheer amount of software installed
by our operating systems and the massive functionality bundled with that
software. I mean, look at how many different modules are bundled with
Apache! Most of the apache vulnerabilities in the past have been in the
modules, rather than in the core Apache server. This is hopefully where
hardening comes in -- it's security's counterbalancing force to
feature-creep. I'm working on a paper, actually, to tell people how
to configure Apache servers for better security. Much of this has to do
with which modules you can remove or how you can better contain those
modules... A related question: What are the top things sysadmins can do to protect

Beale: I think the number one thing sysadmins can do to protect themselves is
to harden their systems. Also called "lock-down" or "security tightening,"
this involves:

  1. Configuring necessary software for better security
  2. Deactivating unnecessary software
  3. Configuring the base operating system for increased security

Of course, I write a program to do this, Bastille Linux, a program to test
this, the Center for Internet Security's Unix Tester, and a book on how to
do all of this, due out from Addisson Wesley, so it's clear that this is
where I spend much of my research time.

The number two thing you can do is patch all your systems. As boring as
that is, it removes the vulnerabilities in your software that crackers use
to break in, so it's pretty darn important. The reason I rank it as number
two is that your machine is still hackable during the time that an attacker
has an exploit (attack tool) while you're still waiting for a patch to be

Because the existence of the vulnerability, along with the code
for the exploit, often sits in the Underground for some time, combined with
the non-zero time it takes a vendor to release a patch and you to apply it,
you might have a hackable system for months before you get the patch applied.
This is where hardening comes in. I gave a talk at Black Hat on how most
of the WU-FTPd exploits could be thwarted, before you ever knew about them, by
hardening the server proactively. You can actually break the exploits so
that you can't be hacked, even while you still have broken software on the

I would say the third most important step a sysadmin could take would be
to install a firewall on the system, or at least on the network. If a bit
of software is unreachable, it's hard to attack. On the other hand, always
remember that firewalls rarely protect applications that you need accessible
to the world. For instance, my firewall can't block access to my public
webserver! It won't do a thing to protect it. Honestly, this is probably
where much of the hacking effort is going to go. An attacker can rob
an Internet-accessible bank or store blind if the Web application has a
vulnerability in it -- he won't need any buffer overflows and the firewall
won't stop him. There a few security-enhanced Linux distros out there these days. What do you generally think about the efforts of these projects, including EnGarde and SELinux?

Beale: Well, most of the security-enhanced distributions hinge on pretty deep
kernel modifications.

SELinux is primarily just NSA's kernel mod. EnGarde uses the LIDS kernel
patch. And WireX's Immunix does this sort of thing too. In each case,
the kernel modification primarily segments the system into pieces, such
that someone breaking into one piece, say Apache, can't modify the core
system or any other piece, say, the SSH server. So even someone getting
root on your system usually can't actually do much, because they've
only got root in the one piece of the system. They might be able to,
at most, replace the Apache content, but they can't create accounts or
trojan your SSH daemon or any of that. It's actually quite nice.

On the other hand, any of this comes with much greater difficulty in
system administration. I wouldn't recommend almost anyone I know to run
SELinux until they undergo some pretty significant training, self-training
or otherwise. It's just quite different to get used to that model.
EnGarde addresses this, actually, by adding a Web-based administration
tool that knows how to navigate this system. Immunix addresses this
by making the kernel modifications much less involved and architecting
things in such a way that the kernel-based access control is only
applied to particular parts of the OS.

I really do like the security-enhanced distributions. You're gaining
a great deal when you go with a vendor whose primary goal is security.
But I always caution people to take this step carefully. You need to
make sure you choose one, and receive training for it, such that you
continue to serve your needs. I don't do any good to my organization
if I make them secure while failing to keep their core functions going. What's going on with Bastille Linux right now? Where's the project at?

Beale: Well, for readers who don't know, Bastille Linux is a hardening program.
Basically, it's a tool that increases the security of a system in every way
that we've thought to automate. This includes steps like reconfiguring
DNS, Web, FTP and Mail servers for better security, but also includes
single-machine or single network firewalls and port scan detection tools.

Now, our most recent piece of good news is that we're officially supporting
HP-UX, making our name just slightly inaccurate. Then again, we probably started
that trend a few years ago, naming ourselves after a defeated French jail!

I'm quite interested in continuing that trend, extending Bastille to run on
things like Mac OS X and maybe even Solaris. Only time will tell!

Anyway, the Bastille Project is going very well right now due to the amazing
cooperation between Hewlett-Packard engineers, like Keith Buck, Rob Fritz, and
Tyler Easterling, an IBM engineer; Niki Rahimi, who's porting us to SuSE and
Turbolinux; a Debian developer, Javier Fernandez-Sanguino Pena; and a number
of others, like Mike Rash, James Durkin and Peter Watkins.

In addition to extending Bastille to more operating systems, I'm hoping to add
a great deal more Linux content to Bastille. I've researched a good deal of
new security tricks that I'd like to add. Of course, there are always a few
that you can't make an automated program do -- these take a human. We're
starting to use a facility to tell you about a few of these in the form of
a "To Do" list. You might even say that my book, no plug here, will be a
logical extension of this... Critics could argue that the number of choices in Linux, both among
security-focused distros and general distributions, works against Linux's
security. How would you respond to that?

Beale: I think the more options you have, the better things get really. I mean, the great thing about having umpteen vendors out there packaging Linux is that,
unlike in the Windows world, there's competition! You can pressure your vendor
to either increase their security or face losing your business to a competitor.

Additionally, one secret I learned while working at MandrakeSoft is that this
plethora of vendors brings an added advantage: the vendors' security people
help each other out! Each vendor has a limited number of security people, but
these people all share information and skills to help each other get security
vulnerabilities addressed quickly and effectively. This ends up working very
well for all their customers, which is why the competitors choose to work
together. Linux distributions get patches out faster than most any other
operating system vendors out there! I think you've answered this for me before, but it's worth noting again. The debate continues to rage about whether Linux and other Open Source apps are
inherently more secure than Windows. How do you answer that question when you're
asked (which I expect you are all the time)?

Beale: I am asked that question pretty often. I wrote an article a while back on
that, which is dated now, but hopefully interesting.

Honestly, it's an extremely difficult question. On the one hand, having
the source makes it much easier to audit software for vulnerabilities. I
mean, people do find vulnerabilities in closed source software too -- they
just have to use tools to make the job easier. They'll use disassemblers
and de-compilers to turn a program back into human-readable source code,
like C or Assembly. They'll also use "black box" tools like fuzzers, which
toss "bad" input into programs, watching for crashes that clue them into weak

If you're a Bad Guy, you theoretically have an easier time with Open Source
because none of these intermediaries are necessary. On the other hand, Open
Source also helps the Good Guys. Because we can also look at the source, we
might find the vulnerabilities first, if we're looking at that part of the
source. Now, I'm not going to throw any of that "many eyeballs" nonsense
at you -- much of the code we use never gets audited too much. So, it's
hard to say what the net effect of source availability is. In the world
of OpenBSD, where the source collection is relatively small and code
auditing is one of the highest priorities, Open Source does an amazing
job of reducing vulnerabilities. Hopefully, one of the code audit
projects for Linux might be nearly as vigilant.

Honestly, I think that one of the great reasons for OpenBSD's success
in reducing vulnerabilities is really that the operating system comes
pretty well-hardened by default. Their default security settings are
much stronger than any other vendors'. I mean, they've had some of
the same vulnerabilities that we've had in the Linux space, but the
vulnerable programs are either off-by-default or have better default
security settings. Obviously, this is the direction where Bastille
tries to take Linux and HP-UX. Recently, Red Hat published a security patch that was supposed to be available only for non-U.S. residents because of fears of the DMCA. What's your opinion of the DMCA? Does it hinder the reporting of security patches?

Beale: Well, I never fully understood why the DMCA got in the way there,
because, as an American, I never got to read what I couldn't read...
I don't know if the DMCA was really a threat or Red Hat was just
paranoid about it or what.

Anyway, I think it's pretty clear to everyone in the security
community, and in the academic research community, that the DMCA is
just horrible. I personally hope that sections of it are struck down
by the Supreme Court, as incompatible with the U.S. Constitution.

Researchers, whether academic or otherwise, need the ability to point
out the weaknesses in systems. In cryptography, the only reliable
way to make sure weak systems aren't used is to try to break them. No
researcher in the field would dream of recommending a cryptosystem
without first trying to break it or reading reports from people who
had. And this research then helps these same researchers build better
cryptosystems not vulnerable to known weaknesses. We need this
create-test-share-create cycle to build good crypto. And we need it
to build any good security system.


  • Security
Click Here!