Slashdot Mirror


Hardening Linux

davidmwilliams writes "Out of the box, many Linux systems are insecure with open ports and unpatched vulnerabilities. Read about the essential steps to secure your server as well as how to solve them manually and via automated tools like Bastille."

6 of 204 comments (clear)

  1. AppArmour by Shuntros · · Score: 3, Interesting

    I know people seem to find it all trendy to bash Novell these days, but AppArmour is a a pretty damn good tool for containing the behaviour of applications. Use a handy little utility to monitor your application (apache, bind, postfix, anything else..) being used in a controlled environment, then apply that ruleset at kernel level and if access isn't defined in the AppArmour profile, it ain't happening.

  2. Per-distro comparisons? by delire · · Score: 4, Interesting

    In this regard I'm very impressed with the work the Ubuntu developers have done: a netstat -tupa post-install reveals a very small attack-surface where ports are concerned. That said, it would certainly be interesting to see a per-distro comparison at some point.

    Anyone know of such a project - even if just comparing a few top-tier distributions?

  3. Hardened Linux From Scratch by owlman17 · · Score: 2, Interesting

    This is mainly for those who roll their own using LFS, but Hardened Linux From Scratch should give some tips, and practical advice, which critical areas need patching, plus proper practices.

  4. That's a good point. Thanks. by khasim · · Score: 4, Interesting

    It is often useful to run it locally, anyway, so that you can compare the output of `nmap localhost` and `nmap 0.0.0.0`, as often a machine will have services running that are only accessible locally.

    Yep. That's why I prefer hitting it from a different machine. Multiple machines if possible. One on the same LAN segment and one from somewhere on the Internet.

    That way you'll see what a would-be-attacker will see.

    Sure, I might be running SMTP on port 25, but bound to 127.0.0.1 instead of eth0. An attacker would have to FIRST gain access to my machine through some other means to be able to attack my SMTP service.

    Sure, that first hurdle might be set very, Very, VERY, VERY high, but if someone can get over it ... that's why patching is still important. But that's also why patching cannot be your only "defense". You will not know what vulnerabilities the bad guys have found that are not patched yet. Defense in depth.

    And that's what "security" is all about to me. It's the PROCESS of evaluating threats and reducing their effectiveness.
  5. newbie article by NynexNinja · · Score: 2, Interesting

    The obvious problem with this article is they mention using "Bastille" and forget to mention grsec. I don't really care about Bastille, but I do care about using grsec. Just because you turn off some services doesnt mean someone is not going to pop an xterm off your apache web server from some random cgi vulnerability... At least when someone compromises your web server in this way (which is probably how most linux web servers get compromised these days anyway), the attacker wont be able to do anything besides navigate the directory tree maybe. The attacker wont be able to view processes that are outside their own uid. The attacker wont be able to execute binaries outside of the standard bin directories (so custom scripts/binaries wont execute), and stack overflows do not allow execution of arbitrary code.. Its not a very fun environment to work in, most attackers will just look around and exit when confined to this type of environment...

  6. Re:Hardened? Hardly. by Anonymous Coward · · Score: 1, Interesting

    I used that patch for many years to secure Debian web/ftp/mail/shell servers. I also took great care to run only the safest possible daemons (e.g., qmail) and adopted a default-deny approach in general. Those systems never got cracked.
    After a few years of that, I ended up moving to OpenBSD, because I got tired of managing all the security aspects of the OS myself. It's a matter of convenience and especially time... though I also happened to also be pulled-in by excellent OBSD documentation and all-around integration that Linux "distros" lack.