March 2003
Book Reviews: Two Security Titles
by Jeffrey Taylor
Building Secure Servers with Linux
Michael D. Bauer
O'Reilly, 2003
ISBN: 0-596-00217-3
$44.95, 439 pages
 |
Real World Linux Security, 2nd Edition
Bob Toxen
Prentice Hall, 2003
ISBN: 0-13-046456-2
$49.99, 810 pages (with CD-ROM)
 |
From the titles, Building Secure Servers with Linux (Secure Servers) and Real World Linux Security (Linux Security), you might think that there would be a lot of overlap between these two books. There is surprisingly little. Secure Servers offers the above-ground view — how to configure servers so they are secure. Linux Security provides the below-ground view — how to secure the OS and network against people who don't play by the rules. The authors' writing styles are very different.
Secure Servers has the quiet, competent approach of a typical O'Reilly book (as the subtitle says, "Best Practices of the White Hats"). The Secure Servers author, Michael Bauer, writes the "Paranoid Penguin" column in Linux Journal. That title owes more to alliteration and poetic license than questionable sanity.
Linux Security, on the other hand, contains all the war stories, harrowing tales, and chest thumping of an alpha geek — stuff to scare the suits into spending more on security, but not good bedtime reading. The Linux Security author, Bob Toxen, was one of the original authors of BSD Unix (Berkeley System Distribution), and he still carries a lot of the Berkeley attitude — bright, arrogant, knowledgeable, and a former gray hat. For example, Toxen says:
The best way to prevent buffer overflow problems and other security bugs is to use good programming practices and to have all code audited thoroughly by someone experienced in auditing code. Even in well-written code, I can usually spot at least one bug per page of source.
One client will be flying me to California to audit some recent code for their server. Even though there are thousands of units around the world with this server, operating for more than a year, there have been no reported bugs. No patches nor upgrades to the server have been required. This has been due to good programming practices (and some luck).
Toxen is a useful guide when you need to crawl through the sewers to plug the cracks where the cockroaches get in.
Having stated my preferences on the table, I think the more valuable book may be the one that goes against my preferences. I like things that work, so I do not have much experience and knowledge about breaking things.
Both books have plenty of references, mostly URLs. Security is a moving target, so print resources must always be supplemented by online resources for the most current information. Both books are copyrighted 2003 (so they were current approximately August 2002). From Secure Servers about Apache:
A secure web service starts with a secure web server, which in turn, starts with good code — no buffer overflows, race conditions, or other problems that could be exploited to gain root privileges. It should be immune to remote exploits by the swarming script kiddies. By any criteria, Apache is pretty good. No serious exploit has been reported since January 1997; security patches have addressed minor vulnerabilities.
Clearly this was written before the Slapper exploit of mod_ssl in September 2002.
Secure Servers is easy to read and it just flows. The writing is transparent and does not distract from the content. The humor is gentle and will likely age well:
You've toiled for hours crafting your firewall rules and hardening your email and DNS services, and you believe that no evil force could breach your fortress walls. But now you blast a hole straight through those walls to a port on your server. Then you let anyone in the world run programs on your server at that port, using their own input. These are the signs of an unbalanced mind — or of a Web administrator.
Linux Security reads like a collection of articles or HOWTOs by someone who watches too much late night TV. It contains frequent digs at people who were nailed by crackers and suggests that had those people followed the author's advice, all would have been well. There are odd breaks in continuity and occasional repetition. Sometimes the sections highlighted with a gray background are asides and can be skipped. At other times, those highlighted sections are used for emphasis and must be read to understand the following text. Sometimes the following text just changes the topic.
Secure Servers covers OS hardening, OpenSSH, Stunnel and OpenSSL, DNS (BIND and djbdns), Sendmail and Postfix, Apache, FTP, syslog (and syslog-ng), Tripwire, and Snort. The "Hardening Linux" section describes removing unused services, restricting privileges, setting up a firewall with IPtables, port scanning (nmap and Nessus), and the Bastille Linux hardening script — all in 60 pages.
Linux Security devotes 160 pages to the same material. On the other hand, Secure Servers has 26 pages on BIND, 18 pages on djbdns (another DNS server), and 3 pages on integrating the two. Linux Security contains 2 pages on BIND. Both cover Tripwire (15 pages in Secure Servers vs. 5 pages in Linux Security) and Snort (13 vs. 1 page).
Linux Security covers largely the same topics — BIND but no djbdns, several VPN alternatives to Stunnel, Sendmail but not Postfix, Apache, FTP, and syslog but not syslog-ng. There is much more emphasis on OS hardening. GPG gets a chapter of its own (not mentioned at all in Secure Servers). Firewalls get two chapters (100 pages vs. 13 pages in Secure Servers). Only Secure Servers covers "stealth logging" (remote logging to another computer that has no IP address). Linux Security has a large section on how to prepare for and recover from a compromise, in addition to advice on when and how to prosecute an attacker.
Some more sophisticated attacks start a trojan and then delete the executable file. Linux Security explains how to find these and how to gather information on them by using the debugger and the linker, and by printing out strings in the executable. It's pretty slick. Other explanations describe how to isolate the system, gather the evidence and, after waiting for the kernel's periodic sync to disk, cut the power. This method is recommended against trojans that can detect a shutdown and try to do as much damage as possible or encyst themselves.
I noticed a couple of typos in Secure Servers in the Postfix section, but both were minor. (On page 234, near the top, "postfix /etc/aliases" should be "postalias /etc/aliases". On the opposite page near the bottom, "FQDSs" should probably be "FQDNs".)
In Linux Security, I have a quibble with "No 7.x or later distribution of Linux ..." on page 594. Presumably the author means no Linux distribution circa Redhat 7.0 or SuSE 7.0. Debian is currently at 3.0, and if it contains vulnerabilities, I'm sure they'll be fixed long before the 7.0 release. Or before the 7.0 release of the Linux kernel.
Also in several places, Toxen states that local traffic on cable modems can be sniffed. I've heard conflicting stories on this and don't know whether it is an old wives' tale or is something that is/was true at some particular time and place. I have tried several times to sniff traffic on my cable modem and have seen nothing but my own traffic. I have read several pieces by people who should know that cable modem traffic is encrypted on the cable and not sniffable. One confusing aspect is that it does appear to be true that cable modems will pass broadcast traffic but the router in the cable company's office will not. So your neighbors may show up in WinNeighborhood (and clones).
Another objection I have to Linux Security is that there is a page or more on how to install each package. They are mostly the same: "./configure; make; su; make install". Secure Servers explains it once and then just references it unless there are significant differences.
A couple other areas in Linux Security rankle with me. It contains 1 1/2 pages trashing the SuSE firewall scripts. The author finds the scripts harder to understand than his own custom scripts and says:
I make liberal use of variables in a file that is separate from the main rules file. Clients then can edit the variables file to enable or disable specific features without needing to understand the rules set.
But this is precisely what the SuSE firewall packages do! Additionally, there are several hooks, so you can add your own rules. Toxen writes:
SuSE might have served its customers better by following my procedure of providing clients with a well-written and well-commented IP Table or IP Chains script that they can alter directly.
I think this contradicts the previous quote. Several other complaints simply don't jibe with my experience, and I wonder whether the author was using one of the other firewall packages (there are several on the SuSE CDs). Most firewall packages are just GUI front-ends to the raw IP chains or IP tables rules. I like SuSE's expert-in-a-box approach. Several times when I began to carry out suggestions from Linux Security, I found that the SuSEfirewall package had beat me to it. After Toxen's SuSE rant, the book contains 70 pages of dense, mixed variable assignment and rules examples for building your own firewall from scratch. I remain unconvinced that is is necessary for low- or even medium-profile systems. For high-profile systems, though, you had better have a real expert, not an expert-in-a-book.
The other gripe I have is Section 2.6.2, "Finding Permission Problems". Before you modify any permissions, record the original values somewhere (e.g., "ls -l > ls-l" or "ls -lR > ls-R" for whole directory trees). I jumped before looking and now several applications (e.g., Quake3) do not work. I spent several days re-installing and restoring from backups, but this does not always restore the original permissions, just the content. It will probably take a clean install to get everything working again. If your distribution includes a hardening package (e.g., harden_suse or Bastille), use it first. Then try out his suggestions, a file or directory at a time. Let the ramifications shake out for a day or a week before making the next batch of changes.
It should be clear which book I prefer. The real question is: if I were sent to some desert isle with Internet connectivity, which one would I take? If I were setting up a LAN with no hostile users and a low-profile Web site, I would take Michael Bauer's Building Secure Servers with Linux. If I had to set up and maintain a system against hostile users or a world of crackers, I would definitely take Bob Toxen's Real World Linux Security. It has much more of what I don't know and don't want to learn the hard way. However, if you are black hat who has just taken a straight job as a sys admin, go for Bauer's book and read his Linux Journal column, too. In either case, request a care package containing the other book.