Hi Joe and everyone,
What do you guys think of server hardening scripts? Have you used any? Some examples would be
bastille-linux www.bastille-linux.org/
http://www.thealders.net/blogs/2007/01/17/server-hardening/
ELS Easy Linux Security
http://www.webhostingtalk.com/showthread.php?t=583865
Articles with interesting security links
http://en.wikipedia.org/wiki/Bastille_Linux
I’ve never been impressed by them.
There’s a lot of fluffy feel good stuff in those scripts that does almost nothing to address the real source of almost all security problems, while they also break quite a lot of functionality in subtle and sometimes difficult to diagnose ways (/tmp usage is a source of many problems with these scripts…though Virtualmin gives each user a private tmp directory, so this wouldn’t strike your users using our Install Scripts…but things that we didn’t install might break).
In short, I don’t recommend them, unless you have a lot of time to kill. Red Hat has more experienced security people on staff, likewise with Debian among their volunteers, than any of these projects have among their ranks. There are probably circumstances where these things might be helpful, but I’m not convinced a hosting server is one of them.
There are some truly interesting security projects in existence. SELinux is the best known among them, and probably the best, but AppArmor also looks pretty good. I think they are worth the effort to implement (particularly on operating systems that include them, by default). We currently disable SELinux on systems that have it…because it introduces a whole new layer of permissions that are not at all understood by the majority of administrators at this point, and permissions problems are the single largest source of trouble on hosting systems. But Virtualmin is already aware of context (to some degree), and it’s possible to run a full-featured Virtualmin on a system with SELinux, as long as the policy has been modified to correctly allow everything to work (this is tricky, and different for every version of Fedora and RHEL and there is no standard way to distribute SELinux policy changes, so we haven’t integrated it yet).
All of that said, there are three things that almost no administrator really does (even many that go to lots of extra trouble installing stuff like Bastille–I’ve seen several compromised Bastille systems, due to the following problems), that can dramatically reduce your risk of security trouble:
Keep your software up to date. Always run the latest versions of everything from your OS provider (and our repos, if running Virtualmin Professional).
Use strong passwords. Eight or more characters, letters and numbers and/or symbols. Change them every year at minimum.
Turn off unneeded services. If you don’t know what it is, Google it. Be sure you understand what your system is doing.
Notice that firewalls aren’t in that list at all. A firewall can do a lot of good in a private network where the boxes inside have no business being spoken to by the world outside. But we’re talking about a public server providing all public services. So, pretty much every active port needs to be open, so it can provide services to the world. And if there is no service listening on a port, it’s better than firewalled–it’s dead, and assuming no huge glaring kernel bugs, it’s completely useless to a cracker.
So, if you’re already doing those three things, you might then consider spending time getting SELinux working. After all of that, if you still don’t feel safe, spend some time with those “hardening” scripts. But pick and choose the techniques. Most of them are so far out of date that it’s laughable that they still exist in these scripts (I’m not familiar with ELS, but I know Bastille pretty well). They address problems that existed in the ancient history of UNIX and have long since been addressed by kernel features in Linux.
That said, this does bring up one nice thing about Bastille: It’s interactive and pretty informative. So, running it and saying “no” to every option can be very educational–though the information is less detailed than I’d like, and more generic than is useful…if you follow up by googling each concept, you can learn a LOT about the history of UNIX security. And that’s a really useful thing to know. How hackers think and how they approach the problem of exploiting machines is more important than any specific exploit, and it can help you be more attuned to keeping things safe and secure. And that’s never a bad thing.
Hi Joe,
Thanks! Sounds like great advise to me. 
The good thing about your three Security Principals is that they are pretty commensensical, not esoteric, and lead you into things you should know anyway as an alledged systems administrator.
For principal One, should I try and do a yum update in an automatic cron job, or should this be done manually once a week?
Principal Three will be kind of fun to investigate too via Google, and then I will experimentally try turning some stuff off (with a cold sweat).
As you suggest, if I run Bastille, I’ll run it in information mode, just to learn some of the history and issues of security.
An optional addendum would be the using the firewall to put a pause into the multiple ssh login attempts talked about elsewhere in this forum.
I will probably adjust my ssh so folks can’t directly login via ssh as root. Does this sound worthwhile?
Hey Rick,
Yep, the ssh delay rule that Leif brought to our attention a while back is very nice. Stateful packet inspection definitely opens up new possibilities for making firewalls more useful, even in cases where services do have to be accessible to the world at large.
Disabling root logins is also a good choice. It’s sort of a balance of convenience vs. security. I usually don’t disable root logins, but have begun to do so more frequently since I use sudo for nearly everything rather than a direct root login (of course, if the user account is ALL sudo capable, it has the same problem as root).
It’s not what you disable… it’s the passwords that make the difference.
A lot of users including server admin use passwords that are easy to hack. If passwords are at least 12 characters and include UPPER and lower letters plus 2 special characters or numbers the passwords become nearly un-hackable even through brute force.
I have a online password generator that will give anyone a un-hackable password. http://ww2.borgnet.us/apgonline/
I heard of one good way of making good passwords you can remember. Invent a sentence that is meaningful to you and just use the first letter of each word.
For instance, if your wife is Jessica you could use:
I Must Take Out The Garbage Every Sunday Or Jessica Gets Mad
imtotgesojgm
You could mix in a couple upper cases and a number to really enhance it.
First letter of each word in a sentence is the method I like, then giving it a ‘l33t’ speak type treatment. So taking the example above, something like ‘1mt0tg3s0Jgm’ – numbers replacing like characters, usually I’ll add an arbitrary couple numbers on the end as well and pick a system for deciding capitals.
I’m curious about point 1 above as well, what is a good practice for streamlining the process of keeping things updated?