Security

Rob Toxen's new book, Real World Linux Security: Intrusion Prevention, Detection, and Recovery, appeared on store shelves late last year. Toxen, now the president and CTO of Fly-By-Day Consulting, sports a colorful professional résumé with an abundance of highlights: he's the creator of the Sunset Computer, one of the 162 recognized developers of Berkeley Unix, one of the four developers who did the initial port of Unix to the Silicon Graphics hardware, and the software architect of the Netgear ND508 and ND520, as well as of the Kennedy Space Center PC space shuttle payload document network.

We held a discussion with Toxen in ITworld.com's Interviews forum. You can read the complete conversation there; what follows is an abridged version.

Who needs it?

LinuxWorld.com: Bob, you're proud of your book -- I know that already from our conversations. Who should be reading the book besides Unix sysadmins with specific responsibility for security?

Bob Toxen: Who should read it? Anyone who manages one or more Linux or Unix systems. This group includes those with Linux systems at home and those users or programmers who manage systems without calling themselves system administrators. Programmers, Webmasters, and database administrators have tremendous influence over security and will benefit greatly from the book. Common errors and problems in programming, Webpage design, and databases are discussed too. Any system with access to the Internet or other large or public network is at risk. As I explain in section 2.9, "Firewalls and the Corporate Moat," simply putting up a firewall is not enough. For good security, it is necessary to understand the limitations of firewalls -- how crackers do end runs around them or tunnel through them -- and how to block these attacks.

Because no one security ring is 100 percent secure, most security experts recommend multiple rings of security, a strategy sometimes called security in depth. Thus, if a cracker breaks through one ring, there is a second ring to stop him, and maybe even more rings beyond that. In the physical world, multiple rings of security are common. To visit an executive of a large company, you may need a pass from a guard to drive your car into the parking lot, then explain your business to the lobby guard, and have an appointment with the executive's assistant. Frequently the systems behind a firewall need security improvements to reduce the risk of a break-in. For example, a firewall might let in email to some or all of various Linux workstations. If this is done, then those workstations will need to have an up-to-date version of Sendmail and a correct Sendmail configuration to prevent root exploits and spam relaying. Even someone's personal system receiving such email will need to be hardened to prevent it from being compromised and used to attack other, more critical systems.

LinuxWorld.com: How serious are you in claiming that anyone running a Unix host should read your book? There are on the order of a million home Linux hosts, many of them the property of hobbyists. Much as I like your book, its nearly 700 pages look to my eye to be too intimidating for much of that audience. You've got a good table of contents and index, so the book certainly can serve as a reference for emergencies. How should someone who isn't a full-time administrator approach Real World Linux Security? Do you have a list of the priority items that deserve amateurs' immediate attention?

Bob Toxen: I am very serious in claiming that anyone running a Unix or Linux system should read my book and secure their system, even those million home Linux hosts. I estimate that crackers will find roughly one-quarter to one-half of unsecured Linux and Unix systems and break in. The risk for other platforms is even higher.

The book has been organized to allow these part-time system administrators to eliminate the largest vulnerabilities very quickly in an organized manner. This is the goal of Chapter 2, "Quick Fixes for Common Problems." Each danger or tool discussed is rated with one to five skull-and-crossbones symbols to indicate how dangerous or helpful it is. This allows one to concentrate on the most important issues. These are sorted by danger level in Appendix H. There is very extensive cross-referencing to related sections that include the page numbers and there is a detailed index to find answers quickly.

Chapter 2 starts with a short section on understanding Linux security and even has an example of how a cracker might try to break into your system so you can start to understand how different pieces of security fit together. A bit later in this chapter, dangerous services such as NFS and finger are discussed. Many distributions enable these by default even though most users do not need them. They allow crackers to break in quite easily. Simply by spending a few minutes to turn them off, a system can be made much more secure than it was before.

Threat triage

LinuxWorld.com: You list categories of intruders ("disgruntled current employees," "ideological extremists," and so on). Do you have any notion on the scale of threat each represents? Many networks are so vulnerable that anyone can do a lot of damage. In organizations with at least some level of security consciousness, from what I've seen, it's employees who consistently cause the most harm.

Bob Toxen: While the FBI and others claim that about half of security breaches are by employees, my experience is that most of them are by outsiders. With most systems connected to the Internet the external threat is much higher. The probabilities of attacks by recreational crackers, ideological extremists, and people with grudges vary greatly by site in a generally obvious way. More important than an intruder's philosophy is their capability.

LinuxWorld.com: How does a newcomer to security management decide what's enough? Some systems deserve more protection than others. If I'm keeping a vanilla Linux box on the Net just so I can occasionally exchange email with my relatives, I'm not going to devote my life to keeping up with CERT. Do you have any tips on where to set the boundary between prudent precautions and overkill?

Bob Toxen: In the book, I discuss how to compute what the cost of a break-in is. This value would be a limiting factor on how much money (or time) to spend. For systems used mostly for email and surfing, updating the password, turning off unneeded services, and upgrading buggy servers may be enough. Then again, what if a cracker sends email from a nonexistent mistress to one's wife, or points one's young child at a hate site? Almost everyone makes purchases over the Web, and getting bogus charges removed from one's credit card account can be frustrating and difficult.

Unix vs. Linux; ssh1 vs. ssh2

LinuxWorld.com: Why is your book about Linux rather than Unix? How much difference do you see there? Out-of-the-box, of course, I'm a fan of OpenBSD, especially from a security standpoint. I generally don't see many differences between Linux and other Unixes; in fact, if anything, I am more comfortable with Linux because of the availability of such items as open source encrypting mass-storage drivers.

Bob Toxen: The book's title says Linux rather than Linux and Unix mostly because it was part of Prentice Hall's excellent open source technology series, and because Linux systems tend to do many things at once. Certainly most home Linux systems fit this category. How many people had Unix systems at home? I did but that is unusual. Many Unix systems are used for one or two specific tasks and are thus easier to secure; most of them also have full-time system administrators. Also, there are many, many people new to Linux that need to secure their systems, and most of them are Windows refugees rather than former Unix types. I do note differences between Unix and Linux when they're important.

LinuxWorld.com: In your book, you talk about the differences between ssh1, ssh2, and openssh. I'm using ssh1 on most installations; what's your current summary of its vulnerability?

Bob Toxen: I've read somewhere that there are some security vulnerabilities in the ssh1 design (beyond the buffer overflow in version 1.2.27 and earlier). Openssh requires first installing openssl and zlib. This triples the required effort over installing a single package, and triples the maintenance requirements for the same reason. The section on ssh was one of the last in the book to be written and it was behind schedule, so I chose ssh2 over openssh. At the time the patents had not expired, so I was probably legally prohibited from building openssh. On the other hand, the owner of ssh2 is getting ugly with new license restrictions even on simply downloading bug fixes for existing versions. I do find ssh2 to be less buggy. Either is a good choice. Be sure you are on a mailing list that will notify you when it's time for a security upgrade!

LinuxWorld.com: Thank you, Bob. I won't wish you good luck with your book; all you need is for it to get the attention it deserves.