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.

Comments

IDS

[afra242]

Does the book go into IDS tools such as Snort? I couldn't find any reference to this, but I can't imagine it to be left out of the book. Are there any well known tutorials/books out there on these tools?

Btw, thanks to fellow Slashdot readers for recommending DenyHosts - superb tool to stop those brute force SSH attacks...

securing networks

[Paralizer]

I've been using Linux (gentoo) at home for a few years now, and I seem to be able to fix most problems I have with it that arise. In a few months it is likely I will be hired by my university to become one of two administrators for our Linux network (I'm a student as is the current administrator).

I've never really dealt with security issues on my home machine as it's behind a firewall and really isn't a target anyone would be interested in, but if I take the position as an administrator at my school I'll be responsible for maintaining and keeping upward of 100 computers secure and running.

For a beginner such as myself, and with my limited experience with Linux and Linux security, would this book be the best resource? Certainly by the review it seems sufficient, but I'm interested in what other people may recommend too.

Re:securing networks

[MyDixieWrecked]

I'm also a gentoo guy.

I picked up O'Reilly's book "Building Secure Servers with Linux" and learned a lot.

it pretty much explains how to set up iptables, the theory behind ssh and ways of better securing it (private/public/shared keys, etc), ways of securing apache, and a slew of other stuff. It's all about best practices.

The only real problem I had with the book is that in some cases, the author is truly paranoid and goes seriously overboard with some techniques, and some of his ideas would never work on a gentoo system. One such thing is that he advises against having development tools (namely gcc) on the server, that way, even if someone manages to compromise the box, they won't have any tools to build/run their rootkit. He suggests using a separate NIC and connecting with a laptop to transfer the binaries to the server. although that will give you a serious piece of mind, it's overkill for many people.

I'm considering picking up this book, though. I like to read about computer security, and I'm amazed at the ingenuity of hackers, from the white-hat to the black-hat. Computer security is quite facinating.

Re:securing networks

[jcnnghm]

I originally got Hardening Linux out of the library, and liked it enough to buy it after I renewed it twice. I think it's a pretty good desktop reference and is quite informative. It's fairly easy to follow, straightforward, and just plain useful.

I also purchased Hardening Apache, although I haven't had a chance to make use of it.

Sendmail? In a secure system

[Animats]

As Google puts it,

Results 1 - 10 of about 191,000 for 'sendmail "security hole"'
Results 1 - 10 of about 1,910,000 for 'sendmail bug'.

Any questions?

Re:I'll stick with OpenBSD and Trusted Solaris.

[sgifford]

You know, the thing that's been keeping me on Linux lately is Debian's apt. I've gotten addicted to the ease of keeping Debian systems up-to-date, especially since I'm responsible for about a dozen systems in different locations and don't have much time to take care of them. I found that when I maintained Solaris systems, package management was a pain, and I procrastinated updating things because it was time-consuming and sometimes broke things. On OpenBSD, recompiling everything from ports seems time-consuming and error prone, especially with a large update (like X). Plus I like being able to use debsums to track checksums on everything I've installed, and have it tell me if any of my executables have changed; sort of a poor-man's tripwire.

On the other hand, it's been a while since I took a look. Has package management gotten better on Solaris or OpenBSD, to the point where I can keep a system up-to-date with about 1 minute a week of my attention?

I keep hoping somebody will package a Debian OpenBSD. That's something I'd use in a heartbeat, if it were well-maintained.

SELinux et al

[jd]

SELinux is in the kernel and one popular distribution at least (Fedora Core) has SELinux-enabled utilities and configuration files as standard, so anyone using that will be using it whether they know what it is or not.

Having said that, there are some good arguments that GRSecurity and some of the other Linux-hardening patches offer better role-based security than SELinux, due to potential limitations of the Linux Security Modules infrastructure. Those seriously interested in hardening Linux would be very well-advised to look through what is available. Having said that, BEWARE FUD! There's lots of claims and counter-claims, and nothing seems to have earned more rigid, fundamentalist stances than computer security.

There are checks for Common Criteria level 3 for Linux, but none for level 4 (which I believe RHEL is now certified to, or was it SuSE?) and there is a lot of contention as to whether these checks actually do anything useful. Are role-based memory locks and network locks actually useful? It would severely limit the security mechanisms you could use, so if you needed some other criteria as well, you might be stuck. POSIX ACLs or Trustees or do you need ACLs at all with role-based mechanisms?

Then there's the password file. Shadow is limited in the number of hashing algorithms it'll support and it may be vulnerable to rainbow dictionary cracks. The mainstream implementation does not support any unbroken hashing algorithms, which may pose other problems - though that is hard to prove. PAM is notoriously fragile, raising questions as to whether it can be considered safe or whether it should be redone. It is also unclear, especially if you use role-based computing, that the full username list should be exposed to all users. It may be more correct for the password and shadow files (if used) to be virtual, where the entries "present" depend on the user viewing the file. But that would add complexity (a BIG no-no in security) and latency.

Not all security options even exist for Linux, though it is unclear why. No Orange Book B-class patches exist for Linux, to the best of my knowledge, the best I've ever seen are just partial implementations. Very little encryption hardware is supported - far more specs have been published than have been coded to, and far more chips exist than specs. I won't even get into the limited security of e-mail clients and servers. How long have PGP and GnuPG been around??? X.400 may not be popular, but it is good on the security angle - so how many clients or servers exist for Linux???

All in all, this is an area the GOOD security guy will be doing a LOT of research in, no matter how much they know. And then, because nobody is an expert in everything and even fewer are experts in security, the REALLY GOOD security guy will not limit themselves to what they can know or understand. The REALLY REALLY GOOD security guys won't even limit themselves to what others can know or understand*.

*Ok, that's worded more for effect than accuracy. The accurate version would be that they are interested in solutions that make unauthorized access within the expected lifetime of the data and/or system highly unlikely at best - or, in the few cases you can do this, actually impossible. (You cannot break a one-time pad without the key, for example.) This is usually done by looking for "really hard problems" and hoping nobody comes up with a really easy solution. (A "really hard problem" is one that either cannot be solved in a determinate timeframe - such as NP-complete problems - or that cannot be solved, on average, in the timeframe you care about - which accounts for 99% of all popular strategies used in encryption.)

Protecting against seizure of the hardware

[Anonymous Coward]

Does the book cover how to protect your box from LE? Particularly if you are willing to suffer data loss, rather than have the data fall into the wrong hands?

Re:SELinux?

[HalfStarted]

That is pretty much on target. SELinux only provides really only provides MAC (Mandatory Access Control). This is a big first piece but isn't enough to completely secure a system, there are still other considerations, such as system auditing, needed to have a fully trusted system.

For the most part SELinux provides binary compatibility for user space applications and ever since it was integrated into the 2.6 kernel provides binary compatibility with most modules... there are some modules that don't behave well with SELinux, some can be fixed with fine grained SELinux policies the rest need patches to their source to interact with the kernel correctly.

Applications don't really have anything to do with SELinux really, what SELinux (or really, what any MAC system does) is compartmentalize the system so that if any given application is compromised the break is limited to that one application and can not be capitalized on to compromise the system at large. SELinux and all other MAC systems rely on correctness of the policy configuration to provide system level security. Extra steps are still needed to protect each independent app though to make sure it is hardened against break-in. While it is important that a cracker is not able to take control of your box you still want to keep him from crashing your application server or web pages and such.

In addition to SELinux (NSA SELinux there are other MAC systems such as:
GrSecurity and RSBAC (RSBAC seems to be down though).

Other very interesting thing to look at are hardened tool chains (gcc with PIE, position independent execution and SSP, stack smashing protection) as well as PaX which is a kernel patch that provides extended security options such as ALSR (Address space layout randomization), non-executable memory. PaX provides some very strong kernel level features that harden all applications from attack. It does come at a slight cost though; some of the features have a minor performance hit, notably nx memory on x86 machines because they do not provide a true NX bit for pages, it has a fairly steep learning curve and some applications plain don't work with it... XOrg and Java VMs for example, because the way they are written they need executable pages for dynamic code generation. PaX security options can be set at a per file or per role (in a MAC system) level so it is still possible to run these apps, they just will not make use of the protection provided by PaX and will need to be tightened down in other ways. The really big gotcha with PaX is that elfloader doesn't support global offset tables or procedure linkage tables. These are required for ALSR in particular so to use PaX libraries need to be statically linked or loaded with dlopen... none of the current binary graphics card drivers for NVidia or ATI work with PaX so if you can't get 3D acceleration from DRI et al. you don't get 3D acceleration.