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.
Im glad that wasn't really what it said.
public class null extends java applet { System.out.print ("Tabula Rasa"); }
No, come to think of it, that's sending the wrong kind of message.
"Made up/misattributed quote that makes me look smart. I am on
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...
Class C2 rating, Orange Book, IIRC. The same rating that Microsoft made such a big deal about Windows NT obtaining. So much for that bit of marketting.
Javascript + Nintendo DSi = DSiCade
ifconfig eth0 down
There, I've save y'all $20
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.
Because it's not OpenBSD?
--
The universe is a figment of its own imagination.
The universe is a figment of its own imagination.
I reviewed a similar book with the same title for Linux Journal a few months ago. If you're into security, you might find it interesting.
"A diplomat is a man who always remembers a woman's birthday but never remembers her age." -Robert Frost
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.
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.
Or you can buy it for 23.50 USD at bookpool:
9 47562-0071223?v=glance&n=283155&n=507846&s=books&v =glance
n quiry.asp?userid=ao05LCTCMJ&isbn=1590594444&itm=3
http://www.bookpool.com/sm/1590594444
or for 29.69 at Amazon:
http://www.amazon.com/gp/product/1590594444/002-0
or you could spend 40.49 at BN:
http://search.barnesandnoble.com/booksearch/isbnI
But of course BN is linked in this review.
It looks like the publisher already has a book out called "Hardening Apache".
Dave K. Mt. Laurel, NJ USA
Just show it a female penguin dressed to kill.
Results 1 - 10 of about 191,000 for 'sendmail "security hole"'
Results 1 - 10 of about 1,910,000 for 'sendmail bug'.
Any questions?
How about prices which include shipping and are less than Amazon's cover price?
(there are online bookstores other than Amazon and B&N)
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.
It's not just about limiting the number of default services. The OpenBSD project has performed years of strenuous code audits. Those have identified, and thus resulted in the fixing, of many bugs.
Then there's the whole emphasis on security in the first place. Code doesn't make its way into OpenBSD without being heavily scrutinized.
OpenBSD is secure because they don't enable potentially dangerous services right off the bat, but also because their development process puts such a heavy emphasis on only including highly secure code.
Cyric Zndovzny at your service.
#include <viagra.h>
BeauHD. Worst editor since kdawson.
(let alone know where to get it [nsa.gov]?)
Getting SELinux is easy. Some distributions (notably Fedora and CentOS) have it installed and enabled by default, and I suspect that anyone who has done any amount of research into "hardening" their system has heard of SELinux.
A good Windows admin can "secure" his system as well as a good Linux "admin". The difference is how much work and effort are required.
I like Ubuntu. By default, Ubuntu installs with no open ports. So, securing Ubuntu against worm attacks takes no effort on a default installation.
But securing Windows against worm attacks requires constantly reading the vulnerability disclosures. Or adding an additional layer that requires a different skill set.
It's only when you get beyond the default installation that admin skills become important. The current problem is that there are so many older versions of Windows out there were sold with a very open default installation that are still vulnerable.
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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Have you thought for yourself today?
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>
"...for when keeping your box in a safe, cut off from the outside world, isn't an option..." Exactly. The most secure box in the world, irregardless of OS or Distro, is the one that hasn't yet, isn't currently, and never will be connected to the internet. But, unfortunatly, that isn't always a practical solution. I'll look out for this one.
"We are Samurai, the Keyboard...Cowboys"