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.
It's important people learn more about vulnerabilities and how to mitigate them as it gives bad ammunition to the anti-linux crowd when high publicity things happen like spreadfirefox being hacked when generally and in this example proper patching would've prevented it from happening in the first place.
"Reforming Linux"
www.omglolh4x.com
Im glad that wasn't really what it said.
public class null extends java applet { System.out.print ("Tabula Rasa"); }
GNU/Linux is hard enough
an ill wind that blows no good
...for when keeping your box in a safe, cut off from the outside world, isn't an option.
Is there anything about SELinux in this? Also does it deal with creating jails?
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?
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...
OK, how many Amazon patent infringement jokes about this article will we see today?
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.
Most decent Linux distributions are rather secure by default. Often times that level of security is more that sufficient, while still offering a decent level of performance.
But then there are times when you need to make sure that the system isn't just extremely difficult to crack. That's when you need to make sure the system is basically impenetrable. Of course, you'll probably degrade the performance somewhat, in addition to other tradeoffs.
Cyric Zndovzny at your service.
harden your computer using one of these kits:N br=315
http://www.bondo-online.com/catalog_item.asp?item
it works with both Linux (TM) and Windows (TM).
#include <viagra.h>
BeauHD. Worst editor since kdawson.
There was a review in December 04 in the Jem Report which seemed pretty fair. Of course, they are comparing somewhat out-of-date OS versions at this point, but it's still worth a look.
I don't find enough difference in security for my purposes (running the server and maintaining desktops at our medical practice) between OpenBSD and Linux to make it worthwhile. The software we use is much more readily available for Linux, and we've had no security issues in the 2+ years we've run it. I can't see learning to administer another system (I'm not a programmer or real sysadmin, just pretending).
Your needs might be different - and probably are!
Using plain ol' text since 1968
Hardening Linux with concepts from the 60's is like hardening cheese with milk from the 60's.
Their "statement of assurance" makes it kind of scary to try and do a commercial selinux distro of your own.
s surance.pdf
http://www.securecomputing.com/pdf/Statement_of_A
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
If the review is to be believed, where is the mention of a BIOS boot password? The system shoudn't even boot a floppy disk without approval from the owner. Physical access == root access? Then put a password on it.
But even that isn't enough. What will truly stop people from accessing your data? Volume encryption? Ha! That may work to slow down a thief who has removed the hard disk. But when you mount that volume for normal use, everything inside it is decrypted for the duration of the mount, hence accessible to root.
File information should be visible, only with explicit trust of a user's verified identity.
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)
Yeah I did some googling after I posted, and the patent issue is pretty old. This LWN article is interesting on the subject, and apparently if the commenter ejhuff is correct the first two patents are already expired and the final patent expires in June 2006. It hasn't scared Red Hat away from implementing SELinux.
Either way, it hasn't stopped my employer from implementing SELinux in our product, either. Blatant plug: download our LiveCD if you'd like to check out our SELinux implementation.
All movements for social change begin as missions, evolve into businesses, and end up as rackets.
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?
SELinux was originally developed by the NSA and is fully GPLed
More specifically, the NSA paid Secure Computing Corp to develop something for them that turned into SELinux.
The corporation currently has 20 patents related to security in the patent db. They only mention three in their "assurance." What about the other 17?
The code is GPL, and it appears they won't drag you into court for a GPL'd hobby distro today, but what happens when you sell service on top? Do they knock on your door asking for a little protection money? What happens tomorrow?
And then this gem from the "Assurance":
However, Secure Computing does not extend the Assurance
to software that merely interoperates with SELinux, or is merely included with a
distribution of SELinux.
It's GPL heaven to have it in the kernel, but as soon as an application interacts with our IP, all "assurance" bets are off is how I read it.
So, let's say I make a nice firewall script, they can drag me into court and claim my script is an application that's interacting with their IP or I pay protection money and stay out of court.
I'm no expert, so help me if I'm reading this wrong.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
Yeah, I'm not an expert on patent law either, but I'm sure Red Hat *did* have experts investigate this issue and it didn't stop them from adding SELinux to RHEL.
All movements for social change begin as missions, evolve into businesses, and end up as rackets.
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>
I don't need a 584 page book to tell me how to harden linux. Just run bastille: http://www.bastille-linux.org/
PHP does very little to prevent an inexperienced developer from programming insecure software. Indeed, as you have found out, they're not doing anything to deal with the known problem of lousy scripts causing severe security problems.
I blame PHP in that it could probably do more to prevent such security problems, but it does not.
Cyric Zndovzny at your service.
nice pic ;-) isn't half what I thought it'd be though ;(
FragHARD or don't frag at all
Do you blame GCC/VC++ as well? Most exploited software these days are C applications.
:P
Sure PHP could do better, but it's not unusual in this regard. It's just as mediocre as anything else.
It's been my experience that Bookpool almost always has the best prices for technical books (AddAll confirms this is the case for this one). Plus, they offer free shipping on orders over $40.
1) Install OpenBSD
2) Drink Beer
3) Drink more Beer.
There is a very efficient way to secure your Linux box from the average script kiddy. It's simple and only takes about 5 seconds.
/usr/bin/wget
:-)
chmod 500
Congratulations: you've stopped practically every script kiddy. (Every exploit I've ever seen has used wget to pull down a "root kit". So deny wget to every user but root. If you want to be clever, you can allow sudo use of wget, but don't feel obliged.)
Of course, this isn't real security. But if I'm running poorly debugged PHP apps on my webserver (you know who you are), then it's a must if I'm to stop my machine getting comprimised.
Oh yes: and learn how chroot works. It'll save you a great many headaches
Cheers,
Robert
--- My dad's political betting
You took a different pill, clearly...
"As the intrepid kobold companion continues his journey, he begins to wonder... if priests raises dead, why anybody die?
I can't believe no one's mentioned what I believe is a popular and good piece of software: Bastille Linux. http://www.bastille-linux.org/>
mark "use it, no compromises in five years"
Which is why we do our hardening during install, via the mechanisms provided by the distribution (ie %post section in kickstart files for RedHat).
... there is always a toss-up between security and convenience. The hardenings we apply for production servers wouldn't make a very useable workstation, and default installations have to consider both.
...
Thing is
Thus, distributions which allow for flexible yet easy to manage policies may be better. Although not commonly considered a server-grade distribution, Mandriva actually has a good framework for managing this, msec. Choose msec level 5 during installation (aka "Paranoid") will result in quite a hardened installation. Try it, but remember to add users to the wheel, xgrp, ctools, ntools groups or you will find it quite unuseable
How much of a problem is it to allow root logins?