Someone on the Atlanta Linux Enthusiasts mailing list asks how "Real World Linux Security" differs from other previously published security books.
Geoffrey, thanks for this excellent question.
> Linux Firewalls - by Ziegler
This is a good book and gives far more details on firewalls than my book does, though mine takes the reader through the most common firewall configurations, including the use of a DMZ. I recommend it in my book. A single home Linux system has no use for a separate firewall.
It is unfortunate, though, that there has been so much hype about firewalls that most people think they are all that you need. In my book I explain crackers' common techniques for "tunneling through almost all firewalls" and ways to do "end runs" around any of them.
In the former case, most firewalls give different response to various types of packets depending on whether or not there is a system at any specified IP address beyond the firewall. One usually can further determine which ports are open (with servers running) on said system beyond the firewall.
If there is an older FTP server on a system inside the firewall that the firewall grants access to from the Internet, it is likely that many attacking requests can be relayed through to vulnerable systems inside the firewall. Remember that most companies think "We have a firewall so we don't have to secure any of our UNIX, Linux, VMS, or Windows systems inside of it." Big mistake!
The nmap program can do both of these types of probing and I discuss nmap too.
Most firewalls just block specified IP addresses from accessing specified ports (services) and protect against TCP Syn Flood attacks and similar protocol level attacks.
I do explain how to use IP Chains to serve as a firewall, with some complete examples. All but the most ancient Linux systems are resistant to these protocol level attacks and I explain how to configure a Linux firewall to protect vulnerable Windows systems from most of them. I also tell how recent a kernel must be to be able to resist various attacks. I explain how to configure Sendmail to block the ILOVEYOU virus (even from mail addressed to accounts on Windows boxes inside the firewall) as an example. I explain how to configure Snort to detect this attack.
> Building Internet Firewalls - by Zwicky, Cooper, Chapman
As I recall this is half on UNIX firewalls and half on NT firewalls. Since I, like many others involved in security, consider NT to be too full of security bugs and design flaws to be taken seriously as a secure system and because the book is on Linux and UNIX, I'm not too interested in this book and I cannot recommend it for Linux and UNIX SysAdmins. For those who want to deploy NT firewalls, I hear that it is a good book.
> Maximum Linux Security - by Anonymous
This certainly is direct competition for my book. I have a copy for my research as I do the other books mentioned and many others.
How does mine differ?
Frankly Maximum Linux Security (MLS) is mostly about how to break into other people's systems and provides far less useful information about how a SysAdmin can protect his system against break-in. First and most obviously, a large portion of MLS seems to be comprised of "fluff" or "filler", i.e., information that is not of any use and which I do not find particularly interesting.
For example, it has too many pages of unneeded printout, portions from man pages, and similar information easily obtained from one's system. In my opinion, Anonymous clearly has very limited SysAdmin experience; I have 25 years of experience as a SysAdmin and UNIX and Linux (combined) kernel and system programming, having learned directly from Bill Joy, Steve Bourne, and others. He does not take the time to research, test, and present the command sequences necessary to accomplish many of the things he suggests but simply says "set up shadowed passwords"; I explain exactly how.
MLS spends many pages giving the history of passwords through the ages, including talking about ancient Egyptians, the history of the word "cryptography", ROT-13, the measuring of people's differing body odor instead of using passwords (despite there being no inexpensive technology to do this), and other items not relevant to an overworked SysAdmin wanting to secure his system quickly. In this section he spends about a page just giving printouts of sample /etc/passwd and /etc/shadow files. I believe I give a sample line from each.
My Operating Systems class at Berkeley was designed personally by Ken Thompson. I helped develop Berkeley UNIX and was one of the four people who ported UNIX to the Silicon Graphics hardware. I've also enhanced a C2 version of the UNIX kernel (secure UNIX). In other words, I've learned from the best.
I find much of MLS' advice is repetition of "conventional wisdom". His advice on what to do if broken into echoes that of most books on security: restore from backups or original media (CD-ROM). For those with user data and production systems, that's of questionable value.
I spend 64 pages explaining how to recover, including ways that will find all Trojans planted and other mischief in a simple-to-follow algorithmic way. I also explain ways to track the cracker to his originating system and how to work with law enforcement and legal types to prosecute. I explain how to find out who to contact at a person's ISP to get the cracker's account shut down, and I've been successful in doing this. I explain how to do "fire drills" to practice recovering from attacks and I explain how to set up "Tiger Teams" to try to break into one's own systems. I've done a great deal of original research for many of the ideas in my book. These ideas will not be a rehash of information on previous mailing lists, articles or books because they have never appeared been published before.
In my book, I talk extensively about passwords as this is one of the most important issues in Linux security. I explain why certain classes of passwords are bad because they can be guessed easily (names of one's Alma Mater or SO) or which can be cracked easily by cracker programs (any single word in the dictionary).
I explain ways to create passwords that are very hard to break and how to safeguard them. I explain the dangers of login simulators that can trick you into thinking your giving your password to "login" but you're really giving it to a cracker's simple program. I do provide a short shell script that does this to illustrate how easy it is.
I explain how MD5 passwords are much harder to break than the older DES passwords because the MD5 algorithm takes 20 times the CPU and because it allows passwords of more than 8 significant characters. I explain the advantage of shadowed passwords over non-shadowed passwords (ordinary users cannot see the encrypted passwords, making them much harder to crack).
I then explain that even recent versions of Red Hat are not enabling both MD5 and shadowing by default. I believe I quote version numbers.
I then take the reader step-by-step through the process of enabling these both on Red Hat and Slackware. I explain dangers of errors and how to prevent getting stuck in a hole. In almost any non-obvious thing to do, I give step-by-step instructions. This took time and testing to get right. MLS seems not to in most cases.
I explain how to cause the passwd program to check passwords for "crackability" with cracklib and to reject easily cracked passwords. Cracklib, unlike crack, does not have code to crack passwords but it does know the algorithms and will analyze a known password to see if it could be cracked with these algorithms. In other words, if a new password that you ask the passwd program to use for you is found in a dictionary of the English language, it will reject it.
I do point people towards the crack program and Jack the Ripper and recommend that SysAdmins use it to ensure passwords on their own systems cannot be cracked easily. However, I do not list a whole lot of cracking programs merely to educate crackers. The cracking techniques I do list usually are to prove certain vulnerabilities to show why certain defenses do not work and why other defenses that do work are important.
In the section on passwords, MLS gives a table of various attacks leading to a cracker getting to see the data in /etc/shadow. In other words, ways that a cracker can see the data in /etc/shadow that normally is protected against viewing by ordinary users. He does this by saying that there are two holes in imapd and one in telnet, a cracker tool that can can search core dumps of telnet to find the portion of the dump that has these shadow password. He does not explain how one might take advantage of these holes nor what versions of these programs that these holes are in or even if the buggy versions are on Linux or some ancient UNIX system.
While these techniques may have worked against ancient UNIX systems that made core files readable by all, Linux core dumps only are readable by the effective user of the program, root in all of these cases. If the cracker is root he can read /etc/shadow directly. In other words, his information is obsolete and of no use to the modern-day Linux SysAdmin. This is typical of his book, unfortunately.
My book is organized by what one hopes to accomplish. Chapter 1 is an introduction (and available for viewing on Barnes & Noble's web page on the book). Chapter 2 is "Quick Fixes for Common Problems". It allows a busy SysAdmin to quickly fix the most severe security problems in a minimum of time. Even within this chapter and others I rate the relative risks of different problems and their fixes with 1 to 5 skull and crossbones symbols. In Appendix H there is a table of vulnerabilities sorted by these Danger Levels.
Later Chapters go through each subsystem in depth covering each issue and how to secure it or, in some case such as NFS, why you don't want to enable it in most systems because of unfixable security problems. I cover Sendmail 8.10, the Netscape browser, and Samba. I don't believe that MLS covers any of these.
I talk about how to configure your system to automatically detect most attacks and lock out the attacking system from getting any service and notifying the SysAdmin via pager, email, by making dramatic use of the sound card, and by flashing the lights with the X10 system.
I explain how to do a simple kernel modification that prevents cracker servers (Trojans listening on high numbered ports). I provide a program that provides a list of open network ports, similar to netstat, but which warns of suspicious open ports. A port is suspicious if it is the default port of a known cracker tool or if it is a high numbered TCP port in a listen state (which should not happen).
I explain how to disable control-alt-delete from having any effect, like crashing your system. MLS suggests setting ctrlaltdel to soft so that malicious users will not be able to corrupt the system's data if they reboot.
MLS mentions the name GNU Privacy Guard (the Free Software Foundation's replacement for PGP, commonly called GPG.) I spend a number of pages taking the reader through all of the steps of downloading, installing, and using it. It is a wonderful tool and I find it much easier to understand and use than PGP.
My configuration values to enable Sendmail to resist Denial of Service (DoS) attacks come from Sendmail, Inc., headed by Eric Allman who created Sendmail. My section discussing them (and permission to use their copyrighted material) was approved be Eric.
Two of my book's reviewers, Mike Warfield and Kurt Seifried, are recognized world-class Linux security experts. A third, Steve Friedl is a talented security consultant. The remaining three reviewers are Linux SysAdmins that reviewed regarding the value of each part of the book to SysAdmins (and they had me delete or change things they did not find useful).
Real World Linux Security's foreword was written by Eric Raymond and Steve Bourne provided a cover quote.
I also use humor and entertaining stories throughout it to make an otherwise dry subject fun. Some of my technical reviewers have reported laughing out loud while reading some passages.
But why not see for yourself? Give Real World Linux Security a test drive? Go into Borders or the Engineers Bookstore across from Tech and look at both. Pick a critical question that you need answered and try finding the answer in each book.
> You know the old school essay, compare and contrast.... :)
> Until later: Geoffrey