Slashdot Mirror
Hardening Linux
r3lody writes "Hardening Linux, by James Turnbull, stands out as an important text that clearly lays out how to make your Linux boxes as secure as possible. Mr. Turnbull has done a noteworthy job in delineating many potential vulnerabilities, and how to mitigate them. Each chapter covers a particular area in depth, with carefully worded and easy-to-follow examples. In the cases where you need to install some other piece of software to provide extra security, Turnbull gives you the step-by-step details, removing the chance of misinterpretation. As you finish each chapter, you will want to apply your newfound knowledge to the machines at your disposal." Read on for r3lody's review.
Hardening Linux
author
James Turnbull
pages
584
publisher
Apress
rating
9/10
reviewer
Ray Lodato (rlodato AT yahoo DOT com)
ISBN
1590594444
summary
In-depth explanations with step-by-step techniques for securing Linux and common applications.
Naturally, the strongest building will collapse if built on a weak foundation, so Turnbull starts by considering what you need to harden a stand-alone Linux host. He discusses what applications to install and how to secure the boot loader (both LILO and GRUB are covered). The init sequences and scripts are covered next, as well as the login screen. Information on securing users and groups using PAM (Pluggable Authentication Modules) comes next, followed by package management and kernel patching. Finally, Turnbull finishes up with how to keep informed on security issues in the future. All of that is contained in chapter 1, and there are ten more to go! Each chapter ends with a list of resources in the form of mailing lists, web sites, books, etc., so you can fill in any blanks Turnbull may have left in.
Current security postures dictate that every network-connected device needs to be secured from the inside out. Turnbull apparently believes the same thing, and covers the Netfilter firewall framework built into the Linux kernel. Once again providing the careful step-by-step procedures, he demonstrates how to use iptables to manipulate Netfilter chains for maximum protection. There are a number of kernel parameters to Netfilter that can be modified using the sysctl command. James describes the more important ones (such as conf/all/accept_redirects, icmp_echo_ignore_broadcasts, and all under the /proc/sys/net/ipv4 pseudo-directory), and how to keep the changes in place across reboots. He also discusses how to log firewall rules, and keep the code updated using Patch-O-Matic.
As each subsequent chapter unfolds, Turnbull carefully explains how to tighten remote administration, files and file systems, mail, ftp, and DNS/BIND. He gives additional information on how to log important information securely and efficiently monitor the data collected. In addition, tools for testing the security of your hosts are described very clearly, from the inside out and the outside in, along with explanations of how to detect penetrations and recover from them.
Writing about securing a computer system can be written on a few different levels, from the general suggestions which apply to just about any program, to the specific which apply to just one. Turnbull picked commonly used programs and provide step-by-step procedures for locking them down. For example, if you are hardening a mail server, you will find descriptions of Sendmail and Postfix, but not of Qmail or Courier. While this might limit the appeal of the book to just those using the more common programs, it allows a depth that would be otherwise unavailable.
The only quibble I have is that his book does not go far enough. While the chosen applications are covered in great depth, some applications are missing. There is no coverage for a web server, such as Apache, or a database server, such as MySQL. I can only hope that a future edition of the book includes chapters on these and other categories of programs.
Hardening Linux by James Turnbull belongs on the shelf of anyone who installs and maintains Linux servers. The information is easy to follow, and will help you configure your systems very securely. The additional insights into why the configurations are important is extremely valuable in its own right."
You can purchase Hardening Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Naturally, the strongest building will collapse if built on a weak foundation, so Turnbull starts by considering what you need to harden a stand-alone Linux host. He discusses what applications to install and how to secure the boot loader (both LILO and GRUB are covered). The init sequences and scripts are covered next, as well as the login screen. Information on securing users and groups using PAM (Pluggable Authentication Modules) comes next, followed by package management and kernel patching. Finally, Turnbull finishes up with how to keep informed on security issues in the future. All of that is contained in chapter 1, and there are ten more to go! Each chapter ends with a list of resources in the form of mailing lists, web sites, books, etc., so you can fill in any blanks Turnbull may have left in.
Current security postures dictate that every network-connected device needs to be secured from the inside out. Turnbull apparently believes the same thing, and covers the Netfilter firewall framework built into the Linux kernel. Once again providing the careful step-by-step procedures, he demonstrates how to use iptables to manipulate Netfilter chains for maximum protection. There are a number of kernel parameters to Netfilter that can be modified using the sysctl command. James describes the more important ones (such as conf/all/accept_redirects, icmp_echo_ignore_broadcasts, and all under the /proc/sys/net/ipv4 pseudo-directory), and how to keep the changes in place across reboots. He also discusses how to log firewall rules, and keep the code updated using Patch-O-Matic.
As each subsequent chapter unfolds, Turnbull carefully explains how to tighten remote administration, files and file systems, mail, ftp, and DNS/BIND. He gives additional information on how to log important information securely and efficiently monitor the data collected. In addition, tools for testing the security of your hosts are described very clearly, from the inside out and the outside in, along with explanations of how to detect penetrations and recover from them.
Writing about securing a computer system can be written on a few different levels, from the general suggestions which apply to just about any program, to the specific which apply to just one. Turnbull picked commonly used programs and provide step-by-step procedures for locking them down. For example, if you are hardening a mail server, you will find descriptions of Sendmail and Postfix, but not of Qmail or Courier. While this might limit the appeal of the book to just those using the more common programs, it allows a depth that would be otherwise unavailable.
The only quibble I have is that his book does not go far enough. While the chosen applications are covered in great depth, some applications are missing. There is no coverage for a web server, such as Apache, or a database server, such as MySQL. I can only hope that a future edition of the book includes chapters on these and other categories of programs.
Hardening Linux by James Turnbull belongs on the shelf of anyone who installs and maintains Linux servers. The information is easy to follow, and will help you configure your systems very securely. The additional insights into why the configurations are important is extremely valuable in its own right."
You can purchase Hardening Linux from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Surely a good way to harden Linux would be to apply as many of these 'hardenings' at install time, particularly for server installs?
So why aren't they?
While I'm sure a properly secured Linux system does make a fantastic server, I find that I tend to stick with OpenBSD and Trusted Solaris for those systems that need to be impenetrable.
Has anyone done a recent comparison/evaluation of a highly secured Linux system versus similar OpenBSD and Trusted Solaris systems?
Cyric Zndovzny at your service.
I hope this isn't taken as a troll. How can Linux users claim better security than Windows, then write books about how to make sure the OS really is secure?
If we could get the average Joe Bob Windows user to read a book about security, I'm sure we'd see a lot fewer Windows security breaches, too.
All of which just suggests to me that the difference is in the user base (that's a compliment), not the technology.
Like always, a higher degree of security often means that tradeoffs must be made. In many cases such tradeoffs reduce the ease of use of the system, or reduce the performance. Such tradeoffs aren't always suitable.
Take OpenBSD, for instance. While it offers an extremely high level of security, it comes at a price. A system running OpenBSD usually does not perform as well as a system running FreeBSD or NetBSD, for instance. You may also have to use older versions of software, or not use certain software at all (ie. PHP).
In many situations, performance is more of an issue that security. Most Linux distributions, especially those intended for use on servers, are fairly secure out of the box. So users end up getting a higher degree of performance, even if there security level isn't as high as possible. A good blend, one might say. However, if you do need the utmost level of security, you can always use something like SELinux or OpenBSD.
Cyric Zndovzny at your service.
i'm not sure if it's actually php's fault, it seems that because it's such an easy and available language (on every web host by default) it attracts n00bs a bit too much - the kind of people who are graphics designers who fancy themselves as programmers or 'web developers'. then there's the books - i've seen way too many tutorials telling the user to do extract($_GET); and things like that, sql injection anyone? the whole addslashes() stuff is a bit confusing too - there are so many functions that do something very similar (plus php.ini options too). i personally haven't touched php in over a year (i mainly got tired of working with crap programmers and the slowness of the xml parser), but recently tried php5, doesn't seem to be any security features added - something like perl's taint mode would be nice.
#include <sig.h>
Does the system have Perl?
First you paste a Mime::Base64-running Perl program in, and then you launch it and paste in the Base64 code. Look, you can get binaries on the system from a shell window!
This is what is known as 'security-through-inconvience'.
If corporations are people, aren't stockholders guilty of slavery?