Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security Books Media Software Book Reviews Linux

Hardening Linux 137

Posted by samzenpus from the like-steel dept.
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.
This discussion has been archived. No new comments can be posted.

Hardening Linux More

Hardening Linux

Comments Filter:
  • 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.

    • Avoid PHP. (Score:1, Flamebait)

      by CyricZ ( 887944 )
      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 wil

      • Re:Avoid PHP. (Score:2, Insightful)

        by BestNicksRTaken ( 582194 )
        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 some
        • 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.

          • Do you blame GCC/VC++ as well? Most exploited software these days are C applications.

            Sure PHP could do better, but it's not unusual in this regard. It's just as mediocre as anything else. :P
    • Actually, in terms of amunition the book itself sounds bad enough.

      " He discusses what applications to install...secure the boot loader...init sequences and scripts...securing users and groups....kernel patching. ... All of that is contained in chapter 1, and there are ten more to go!"

      They make it sound like Windows, where all of these things need to be done first in order to lockdown the system.

  • "Linux has a hard-on"

    Im glad that wasn't really what it said.

  • GNU/Linux is hard enough

  • ...for when keeping your box in a safe, cut off from the outside world, isn't an option.
    • ...for when keeping your box in a safe, cut off from the outside world, isn't an option.

      Class C2 rating, Orange Book, IIRC. The same rating that Microsoft made such a big deal about [theregister.co.uk] Windows NT obtaining. So much for that bit of marketting. :-)
    • "...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.
  • Is there anything about SELinux in this? Also does it deal with creating jails?


    • What percentage of people who need to harden Linux (but haven't done so, perhaps those who remain logged in as root; see also: Windows XP users who are signed in with Administrator privilege; unsecured wireless routers at home) have even heard of SELinux? (let alone know where to get it [nsa.gov]?)

      • Re:SELinux? (Score:3, Informative)

        by Spetiam ( 671180 )
        (let alone know where to get it [nsa.gov]?)

        Getting SELinux is easy. Some distributions (notably Fedora [redhat.com] and CentOS [centos.org]) 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.

      • SELinux et al (Score:5, Interesting)

        by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Friday November 11, 2005 @03:25PM (#14010557) Homepage Journal
        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.)

        • The goals of grsecurity (mostly PAX) and SELinux are completely different.

          SELinux is mainly a sandbox to restrict the damage a compromised application can inflict on a system.

          grsecurity aims to prevent the compromise from happening in the first place.
    • You know, SELinux has some IP issues that I just became aware of this week. For many this is probably old news.

      It seems some aspects of SELinux are patented and the patent holder allows distribution, but once $$ or something that competes with their product is involved, there's a license fee.

      Anyway, beyond the IP issues, just because the kernel has SElinux enabled doesn't mean the applications on top of the kernel have SELinux functionality.

      I think it's reasonable to say that SELinux does not solve many se
      • You know, SELinux has some IP issues that I just became aware of this week. For many this is probably old news. It seems some aspects of SELinux are patented and the patent holder allows distribution, but once $$ or something that competes with their product is involved, there's a license fee.

        Do you have a link for this SELinux patent issue? I've been developing SELinux policy for a while now and read the SELinux mailing lists daily and I've never heard such a thing. SELinux was originally developed by t
        • Their "statement of assurance" makes it kind of scary to try and do a commercial selinux distro of your own.

          http://www.securecomputing.com/pdf/Statement_of_As surance.pdf [securecomputing.com]

          • Yeah I did some googling after I posted, and the patent issue is pretty old. This LWN article [lwn.net] 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 [engardelinux.org] if you'd like to check out our SELinux implementation.
        • 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 p
          • 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.

        • Re:SELinux? (Score:3, Interesting)

          by HalfStarted ( 639977 )
          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 behav

    • SELinux is mentioned in a single paragraph on page 75. A link to the web site (http://www.nsa.gov/selinux/ [nsa.gov]) is given, with a brief description likening it to grsecurity.

      chroot jails are discussed for the FTP server vsftpd, and for BIND. vsftpd has a couple of parameters (chroot_local_user=YES|NO, chroot_list_enable=YES|NO, chroot_list_file=<filename>) to make it easy to set up the jail. Chrooting BIND follows the more traditional format of creating the duplicate tree for the new root, and is explain

  • So .. why doesn't Linux come setup with all this? (Score:1, Insightful)

    by Anonymous Coward
    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?

    • Re:So .. why doesn't Linux come setup with all thi (Score:5, Funny)

      by Jerry Coffin ( 824726 ) on Friday November 11, 2005 @02:31PM (#14010052)
      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?

      Because it's not OpenBSD?

      --
      The universe is a figment of its own imagination.

    • There are tradeoffs. (Score:5, Insightful)

      by CyricZ ( 887944 ) on Friday November 11, 2005 @02:41PM (#14010155)
      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.

    • Which is why we do our hardening during install, via the mechanisms provided by the distribution (ie %post section in kickstart files for RedHat).

      Thing is ... 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.

      Thus, distributions which allow for flexible yet easy to manage policies may be better. Although not commonly considered a server-grade distribution, Mandri

  • Linux II: The Hardening (Score:3, Funny)

    by Orrin Bloquy ( 898571 ) on Friday November 11, 2005 @02:23PM (#14009966) Journal
    No, come to think of it, that's sending the wrong kind of message.

  • IDS (Score:5, Interesting)

    by afra242 ( 465406 ) on Friday November 11, 2005 @02:23PM (#14009972)
    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 [sourceforge.net] - superb tool to stop those brute force SSH attacks...

    • Re:IDS (Score:4, Informative)

      by r3lody ( 800999 ) on Friday November 11, 2005 @03:30PM (#14010608)

      Chapter 6 (Using Tools for Security Testing) goes into NMAP and Nessus in depth, then mentions a few additional tools at the end. dsniff, Ethereal, Ettercap, LIDS, Netcat, SARA, Snort, tcpdump, and Titan each have a one-paragraph writeup, with links to the websites for the tools.

    • heh, my solution was to move ssh to a non-standard port and completely disable password auth (which cause a couple of friends who had access to the box to get pissed at me until they got around to generating keys).
    • I tried DenyHosts and found it disapointing. These days I use login_sentry [lumiere.net] which has been improved by a friend of mine. Check it out, cross platform too (/etc/hosts.deny).
  • OK, how many Amazon patent infringement jokes about this article will we see today?

  • The full text of the book (Score:5, Funny)

    by Anonymous Coward on Friday November 11, 2005 @02:26PM (#14010001)
    ifconfig eth0 down

    There, I've save y'all $20

  • I'll stick with OpenBSD and Trusted Solaris. (Score:3, Insightful)

    by CyricZ ( 887944 ) on Friday November 11, 2005 @02:29PM (#14010033)
    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?

    • 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-co
    • 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 t

  • A similar book (Score:3, Informative)

    by ChaserPnk ( 183094 ) on Friday November 11, 2005 @02:31PM (#14010058)
    I reviewed [linuxjournal.com] a similar book with the same title for Linux Journal a few months ago. If you're into security, you might find it interesting.

  • Hmmm... (Score:4, Insightful)

    by rackhamh ( 217889 ) on Friday November 11, 2005 @02:32PM (#14010065)
    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.

    • Re:Hmmm... (Score:2, Insightful)

      by halltk1983 ( 855209 )
      Jane wrecked her kia rio and died.
      Jim wrecked his Hummer and died
      Therefore both vehicles are deathtraps.

      Never mind that the accidents may have happened completely differently. One is safer than the other. It all a matter of degree.
    • Why couldn't Linux users claim that (assuming they justify the claim somehow)? If Joe Bob Windows read computer security books, his system would probably be safer. Does this tell us anything about the comparable inherent security of Windows vs. Linux? No.

      You seem to think that knowledgeable user base somehow precludes or lowers the possibility of better inherent system security. In fact the opposite is probably true -- people who understand computer security are probably going to select more secure syste

    • I believe the book focuses on securing a Linux *server*, rather than a single-user machine. By server, I mean a machine with multiple accounts where not every user can be fully trusted (this includes web servers, where each request comes from an anonymous user). Security on a Windows server has also been the subject of countless books.

      Furthermore, there are many Windows sysadmins out there who are fooled into a false sense of security by the appearant ease of use of Windows. Because Linux forces you to atte
    • Linux is more secure than Windows, but that doesn't mean that you can't make it even more secure with some effort. The reason it's not already done is that some of the ways of adding more security make it less friendly.

      For example, in Windows as it is, the moment you let execute anything they want on your computer, you can assume it's been breached, since practically everybody runs everything as Administrator on Windows. Not so on Linux.

      Now, while giving somebody an user account on your Linux box doesn't le

    • Because "better" != "perfect". (Score:5, Informative)

      by khasim ( 1285 ) <brandioch.conner@gmail.com> on Friday November 11, 2005 @03:19PM (#14010511)
      Just because Linux is better than Windows does not mean that Linux cannot be improved.
      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.
      Maybe, maybe not. There are lots of books on Windows security out there, also. And lots of people buy them. Microsoft even tried to make patching easy. Microsoft even provided a firewall with WinXP-sp2.
      All of which just suggests to me that the difference is in the user base (that's a compliment), not the technology.
      I don't see it like that.

      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.
    • 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.

      The problem is you have teach "Joe Bob Windows user" how to read first. :)

      Personally, I think a special campaign that sends out spam and phish attempts should be put into place. All those that respond will be identified and their computers confiscated, their cable and phone jacks removed from their house, and then they would be sterilized. We have to end this
    • "How can Linux users claim better security than Windows, then write books about how to make sure the OS really is secure?"

      One theory would be that *NIX has better security because the people who use it and develop it have spent the last 40 years having their systems attacked by an incredible variety of threats, so they've had no choice but to create systems which can be effectively secured.

      But that means that a lot is down to the operators as well as the software, which is why books are useful. A book on s

  • securing networks (Score:4, Interesting)

    by Paralizer ( 792155 ) on Friday November 11, 2005 @02:32PM (#14010068) Homepage
    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 (Score:4, Interesting)

      by MyDixieWrecked ( 548719 ) on Friday November 11, 2005 @02:57PM (#14010286) Homepage Journal
      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.
      • Production servers should never ever ever have development tools on them. Even gentoo lets you create packages. You should do this. Of course this is in a perfect world... but seriously, why would you need a compiler on a webserver?
      • I know what you mean, as I've considered this too. One possible way I thought of to address this under Gentoo would be to make a mechanism that effectively takes the entire build system (including gcc and libraries) offline for normal use. Maybe put those and /usr/portage on a separate partition and make it unmountable?

      • Re:securing networks (Score:3, Insightful)

        by DavidTC ( 10147 )
        Not having compilers is the STUPIDEST advice ever.

        Does the system have Perl?

        First you paste a Mime::Base64-running Perl program in, and then you launch it and paste in the Base64 code. Look, you can get binaries on the system from a shell window!

        This is what is known as 'security-through-inconvience'.

        • considering that the majority of attacks is by script kiddies, "security-through-inconvenience" is still security.

          I think the point of not having dev tools is not only to attempt to prevent someone from building their rootkit when they log in, but to also increase the amount of time it takes them to do any potential damage.

          I doubt that most attackers would be prepared with their Mime::Base64-running perl program right off the bat... unless of course, the attacker is a serious pro and their hacking my multi-
      • The other book I've been using (in addition to "Building Secure Servers with Linux") is "Practical Unix & Internet Security" (also O'Reilly).

        I think I'll add this one to the stack as well.

    • Re:securing networks (Score:3, Interesting)

      by jcnnghm ( 538570 )
      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.

  • Shameless (Score:5, Informative)

    by joeybagadonuts ( 849172 ) on Friday November 11, 2005 @02:32PM (#14010072)
    Or you can buy it for 23.50 USD at bookpool:
    http://www.bookpool.com/sm/1590594444 [bookpool.com]

    or for 29.69 at Amazon:
    http://www.amazon.com/gp/product/1590594444/002-09 47562-0071223?v=glance&n=283155&n=507846&s=books&v =glance [amazon.com]

    or you could spend 40.49 at BN:
    http://search.barnesandnoble.com/booksearch/isbnIn quiry.asp?userid=ao05LCTCMJ&isbn=1590594444&itm=3 [barnesandnoble.com]


    But of course BN is linked in this review.
    • Another book with the same title (ISBN 0072254971) goes for $2.09 at eBay (item 4585793995). Wait a week or so and you get the book by M. Chandler for the same price at eBay or half.com (another eBay company). Bids for "Linux All-in-One Desk Reference For Dummies" starts at $1.73, again at eBay.

  • Part of a "series"? (Score:2, Informative)

    by DaveK08054 ( 801355 )
    The reviewer writes:
    There is no coverage for a web server, such as Apache

    It looks like the publisher already has a book out called "Hardening Apache".
  • Just show it a female penguin dressed to kill.

  • Sendmail? In a secure system (Score:4, Interesting)

    by Animats ( 122034 ) on Friday November 11, 2005 @02:39PM (#14010136) Homepage
    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?

    • Umm, yah, soooo, don't use sendmail?

      *ducks* :)
    • Yes, in a secure system!

      Sendmail has as much place on a secure system as Postfix or Qmail. If either of those MTAs had been around as long as sendmail (22+ years) they would probably have as sordid a security history. The thing to remember is that those holes have been patched, some as much as ten years, or more, ago. No software is going to be bug or security hole free. (OpenBSD doesn't even have a pristine security history for all of its code audits.) Like any MTA software, sendmail can be configured to b
      • > Otherwise it will continue to stand to reason that sendmail has just as much place in a secure system today as Qmail.

        Compare the security history since both qmail and postfix were released, lets choose January 2003, against sendmail.

        CERT Vulnerability note search.

        Sendmail 6 vulnerabilities including 4 buffer overflow vulnerabilities, at least one risks a remote root exploit, one was IBM specific and just silly IBM. Many prior ignored.

        Postfix one DoS in 2003.

        Qmail no hits.

        Patching complex systems doesn'
    • Comment removed based on user account deletion
    • Linux? In a secure system

      As Google puts it,

      Results 1 - 10 of about 935,000 for 'linux "security hole"'
      Results 1 - 10 of about 46,300,000 for 'linux bug'


      Any questions?

  • harden your computer using one of these kits:
    http://www.bondo-online.com/catalog_item.asp?itemN br=315 [bondo-online.com]
    it works with both Linux (TM) and Windows (TM).

  • It's easy! (Score:4, Funny)

    by kuzb ( 724081 ) on Friday November 11, 2005 @02:54PM (#14010262)
    #include <viagra.h>
  • Hardening Linux with concepts from the 60's is like hardening cheese with milk from the 60's.
  • 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 access

    • Physical access == root access? Then put a password on it.

      Yes, and buy a server that stores the BIOS password in NVRAM and not CMOS, so it can't simply be cleared by removing the battery...

  • For those interested, I put together a relatively comprehensive list of resources that deal with hardening linux at the kaos.theory blog [theory.kaos.to].

    "Bearing in mind that there are probably several hundreds of websites and whitepapers that talk to this topic, I've tried my best to filter the wheat from the chaff, leaving only those resources that I believe are valuable and offer some unique insight, perspective or technique..."

    The full list is here [theory.kaos.to].

  • Protecting against seizure of the hardware (Score:1, Interesting)

    by 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?
  • I don't need a 584 page book to tell me how to harden linux. Just run bastille: http://www.bastille-linux.org/ [bastille-linux.org]
  • 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.

    chmod 500 /usr/bin/wget

    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
  • 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"
  • How much of a problem is it to allow root logins?

Slashdot Top Deals

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Close