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."
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.
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?
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.
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
And that's what "security" is all about to me. It's the PROCESS of evaluating threats and reducing their effectiveness.
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...
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.