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.
He should have titled it, "Liagra."
taken! (by Davidleeroth) Thanks Bingo Foo!
"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?
When you can use an OS that starts out secure?
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
One of the best things to do, like it or not, is avoid PHP. It has shown to be less than suitable when it comes to security. Indeed, the SpreadFirefox incidents you mention were due to faulty PHP-based systems.
While it doesn't involve the security of Linux (or any other open-source OS) in any way, the security issues that plague PHP do end up making the entire community look bad. Thus I think the open source community as a whole should put more pressure on the PHP developers to introduce technology that will prevent ill-written scripts from executing.
One doesn't want to have to hold the hands of experienced developers, but at the same time we can't let the unnecessary and misdirected damage to our reputations continue because of poorly written PHP scripts.
The Linux and *BSD projects have gone out of their way to make sure that their system is secure, even in the face of inexperienced users. It's time for the PHP team to do the same.
Cyric Zndovzny at your service.
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)
I thought Linux was a secure system as is, why would you need hardening?
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.
This article is also good. Deals with PAM a lot.
http://www.puschitz.com/SecuringLinux.shtml
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.
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?
1: Disconnect box from internet ...
2:
3: Profit!
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.
...but it would be less than one page long:
:-)
"Mix up some concrete, pour half the concrete into a bucket, put the Windows CD package (unopened) into the bucket, pour the remaining conrete into the bucket, and let the concrete harden overnight. Your Windows is now hardened."
there are online bookstores other than Amazon and B&N
Yes, but Spammy McTroll doesn't get his $0.02 Amazon affiliate reward when you buy the book elsewhere.
I don't need a 584 page book to tell me how to harden linux. Just run bastille: http://www.bastille-linux.org/
They said hard. Huh huh huh huh
nice pic ;-) isn't half what I thought it'd be though ;(
FragHARD or don't frag at all
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.
Delete it and install OpenBSD.
Take it easy? I'll take it anyway I can get it . . .
"delineating many potential vulnerabilities, and how to mitigate them"
Could you please translate that for non-native English speakers?
Security with computers is similar to the cat and mouse game that law enforcement and the good guys play all the time.
One side gets ahead of the game, for awhile, and then visa versa.
Law enforcement will tell us, as we already know, that for them to be effective, they NEED the support of the community.
This book seems to have some good points that can be used by all.
However the fact remains, NOONE can protect their systems from attack, whether it is from a kid, or the government.
Therefore I am working on a theory for a detection and recovery system that will compete with the current insane race to 'protect' from the 'unprotectible'.
The theory is actually quite simple.
We are the good guys and 'should' have the most at stake AND motivation in keeping our systems 'up & running' properly.
The bad guys usually (or should not) DON'T have a greater motivation to get into, or ruin our data.
Therein lies the crux of the matter to solve this problem of security and the anxiety that it brings to so many.
I propose that by shifting the emphasis to 'detection' (ids, etc) and recovery (raid, etc), that a minimal of problems can be had.
This in lieu of the current 'thought' and preaching concerning how is best to 'harden' our systems, buy constantly worrying about patches and firefalls.
I'm sure many will say this is insane because by shifting the work involved by the administrator from 'fighting' the bad guys by constantly patching and tweaking, he will allow more 'intrusions'.
And this is so, but when coupled with a system(s) that quickly identifies any intrusions, and an 'immediate' responce (ie. recovery of backup data), there will be less ambition for the bad guy to continualy attempt to corrupt a system which is brought back on line almost immediately after any attacks by him.
I'm sure many are saying "what about companies private data and businesses that handles alot of cash like banks"?
Well there should be more of a motivation for the banks or corporations than for the average person or other businesses that are not involved with cash per say-- then my theory still holds that whoever has the larger motivation, will be able to detect and correct any anomlies with their systems data.
In other words, if a bank can detect a theft 'immediately' then they can (should) take action 'immmediatly' (ie. 'recoop', or undo any transactions BEFORE' the attacking party has made the theft complete).
On the other hand, if the so-called bad guy, who thinks that banks or corporations are evil, they may have the stronger motivation to 'protect' their transactions, therebye putting the banks and corportations in a situation where they are at a well deserved 'loss'.
In summary, I believe this race is a classic 'good vs evil' one, and I am betting on the acomplishments of the 'good works', as oppossed to trying to stop the 'bad works' from occuring in the first place.
--
The InterNet is a terrible thing to waste. Arrest Bill Gates and shut down Microsoft immediately.
I will gladly loose all of life's battles.. in order to win the war..
1) Install OpenBSD
2) Drink Beer
3) Drink more Beer.
I guess I missed out on this one, just looks like a bunch of random numbers :\
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?