I read a number of individual comments about “server security”, and how individuals focus more on “security” and less on “customer usability”, and it just makes me wonder HOW individuals get away with pulling such ridiculous stunts. Well, here’s a few tips from someone who’s been in the game a while. I’m not going to tell you HOW to do this (I don’t reveal any secrets), but a few good tips should be all it takes.

Firstly, when it comes to a server, you have to ask yourself

What is this going to be used for?

If you’re going to use your server for hosting, then you are going to be going through an uphill battle. Thankfully, this entry will help you at least somewhat keep things stable.
Now that we’ve established what you’re using it for, it’s time to secure the server. Seriously, security MUST be placed on any server, updated, and managed as if it were your own computer (it is, after all, you’re just paying someone to use it).

Step One , the firewall
There are a few schools of thought on this, and none are “wrong” per se, none are correct. You NEED to have a firewall (iptables) interface in your system though if you’re running ANY kind of Linux Server online. The firewall will dictate whom can access which ports, and set the rules forth. This is VERY important! In the web hosting industry, the two more popular ones are APF and CSF. Do your homework on each, especially the authors of each, before you download and install either! I would also (very) strongly suggest that you harden your tcpwrappers, part of which is shown here .

Step Two, the system
Ok, we’ve got a firewall installed, now let’s move on to the system. Here are a few tips and tricks that you might want to use when securing systems
A> Disable compilers for normal users
B> Disable wget, get, lynx, curl for normal users
C> Secure /tmp so that exes can’t be run from it directly (note: this will NOT stop perl exploits!!)
D> Disable ICMP
E> Remove unused stuff (cups, etc)

Step Three, the logs
Your system talks to you on a daily basis, do you know what it’s saying? Better yet, do you know how to interpret what it’s saying?
Have your critical logs forwarded to you. These can be done from logwatch , but that will also ignore day to day things such as alerts from your firewall, etc. Don’t just have them forwarded, but LOOK at them, see what your system is telling you!

Step Four, the software
Update your software, ALWAYS use protective patches like suhosin to secure your software, whenever possible, and whenever it won’t defeat the purpose of your server. Keep your software up to date!
A few things NOT to do (unless you like a lot of headaches, that is):
– Never disable php functionality. It’s there for a reason, and your client needs access to these things. Instead, use something like suhosin to properly secure and harden php!

– Never use phpsuexec/suphp . These are serious deterrents to real php programmers and developers. Why?

1: phpsuexec/suphp don’t like php values in .htaccess files. This means that your advanced programmer (such as myself) who places multiple sites under one directory, and uses htaccess to control each site and directory is screwed. This will also upset and alienate advanced programmers. You ARE running a hosting business, right? Do you WANT individuals complaining about not being able to use software?
2: phpsuexec/suphp HATE symlinks. While this isn’t (usually) going to be a problem, it will if you’re running, say, large media sites that should have data stored on another drive

– Never use grsecurity for your kernel, EVER! The Linux Kernel is the core of the OS, the most important part of the entire beast, yet, the most fragile. Putting something like grsecurity in there is just asking for trouble. Not to mention, it is a beast and a half to configure properly for your users to access.

– Never allow full ssh access, ever. Yes, I stress that, because there is no reason that anyone should ever need ssh access. With advanced, on the fly editors like Ultraedit, changes can be made to websites from within Windows itself, and ftp’ed over to the server. The only reason a user would need “ssh access” is to compile something, to run a program (daemon) on your server, or something else. There are no other reasons, and if they’re doing that, you’d best have some sort of proof that they’re legitimate.

Now, following the above examples is just a start to providing a usable, secured server. Of course, any admin with half their sense to them will tell you anything is hackable, as long as it is online, or has a keyboard input. Them’s the breaks though, really. The difference between MOST and what is recommended here? You’re going to end up with client usability with what is recommended here. With most, you’re seriously cutting off client usability.

As always, questions, thoughts, and ideas are welcomed. Spam is not,

Tom