Real World Linux Security

Don Marti

Issue #86, June 2001

This book is here to help you, not scare you, and you should be able to get through the most important parts in a weekend.

Real World Linux Security is the kind of book to which we have to give a good review, as it is seemingly written to butter us up. Bob Toxen says most Linux distributions install too many extra dæmons by default, he lists privacy-violating web advertiser DoubleClick, Inc. as a security issue, and he even uses http://www.linuxjournal.com/ as one of the hosts in an example. We like him already.

We also have to like the concept of a big, fun workbook full of things we can do to increase the security of our Linux systems and how to prepare to get back up with minimum pain if they do get compromised. So please resist the temptation to, after taking one look at these 694 pages of cracks, sploits, bugs and vulnerabilities, go home, unplug your Linux box from the Net and crouch behind it with a shotgun. This book is here to help you, not scare you, and you should be able to get through the most important parts in a weekend. There's no cause for alarm, but no reason to be smug either.

Do you really need this book? We'd like to be able to say you only need it if you offer network services or develop software. In the future, when Linux distributions start to be a little more sensible about their default security policies, you might be able to get by without this book, if you install a locked-down, client-only configuration and subscribe to a mailing list for occasional security updates and bug fixes. But in the future you'll have an apartment on the Moon, too. This is still the wild and wooly Linux scene of Earth, 2001, and every checklist network feature printed on the side of the shrink-wrapped distribution package means more work for you—something you'll have to secure or remove.

Before we get to the good parts of RWLS, let's start with the savage criticism, shall we? First of all, the book mentions browser security but isn't up to the current state of the art in privacy tools. It's good for Toxen to mention that DoubleClick is a security risk, but setting up blackhole routes to some of their servers just gives you something to maintain when DoubleClick moves them. It isn't going to be as effective as making your nameserver authoritative for the doubleclick.net domain or, better yet, running a proxy. And there are better ways to manage cookies than just linking .netscape/cookies to /dev/null.

However, this is basically a book for the system administrator, so no big deal. Users can easily find browser privacy hints—the hard part is locking down services. Strangely enough, though, in Chapter 13 Toxen dismisses the entire network time protocol (NTP) with the comment, “Some people prefer NTP, but it uses only UDP, which is too insecure.” Instead of NTP, he recommends using the older netdate or rdate programs from cron and manually calculating the clock drift if a system gets cracked.

NTP has cryptographic authentication capabilities and, even when used without authentication, will only let an attacker who spoofs UDP packets fake out your computer clock v-e-r-y s-l-o-w-l-y. Don't the advantages of having to-the-second synchronized file modification times and log entries on all your systems outweigh the risks of this difficult attack? Why make yourself have to correct the logs when you can least afford the time to do so?

Coming up with a reasonably secure NTP plan, though, is something you should be able to do after you understand the security principles explained in the rest of the book. Hints: use authentication among your in-house NTP servers and those of cooperative ISPs, friends or business associates; use more than one trustworthy public time server; add a radio clock if you're paranoid; and check your logs.

That's about it for the savage criticism. What you can expect to like about this book is a bunch of configuration tweaks, coding tips, preparatory measures to minimize the effects of an intrusion, security philosophy, anecdotes, office politics and tips on how to steal laptops at airports. The book seems to hop around a little, but it's not like you're reading some free-form brain dump here; if you're doing security, you really do have to think about things at more than one level at a time. Toxen's “knucklehead with a laptop and a phone line” who does an end run around the firewall could be anybody—a home user on DSL, or a traveling user who checks into the Embassy Suites in Las Vegas (which I personally recommend if you're ever in Las Vegas) and plugs into the “High Speed Internet Access in Your Room Only $9.95”.

If your organization depends mostly on a firewall for security, the laptop scenario should give you the heebie-jeebies. Toxen does discuss firewalling, but mainly concentrates on host-based security—he points out that many threats come from inside the organization. Early in the book, he introduces the concept of an “attack path” which you, as the system administrator, should design so that an intruder has to break through as many difficult layers as possible on the path to root on an important box. A firewall can be one step on the path, so he does cover IP chains.

Web developers will get a lot of help from this book, both in detail-minded advice about CGI and other web technologies, and in architecture for web sites. Toxen's “one-way credit card server” architecture, where a separate box keeps credit card data outside the main commerce site database, is a cool idea and applicable to other types of sensitive data, too. Defense in depth is the way to go. Just because an evil recruiter can break in and get a list of employee addresses shouldn't also mean she can see their Wasserman test results or SAT scores.

RWLS gets a thumbs-up in the fun reading department, too, especially the stories of how Toxen, as a UC-Berkeley student, got and kept root on their BSD UNIX systems. Organizationally, the sections are divided clearly enough so that you can read the general stuff and the specifics about what you run now, then read sections on other services as you add them or take responsibility for them.

Unless you code and run an ambitious internet site on your own, you probably won't be responsible for all the security tasks covered in this book. It reveals just how broad of a field Linux security really is. You'll certainly find things to go through and check on your own system in order to cut your intrusion risks now, and you'll also find thought-provoking reading for planning future projects with security in mind.

Don Marti is the technical editor for Linux Journal. He can be reached at info@linuxjournal.com.