Web Server Security Overkill?

For a public facing server, I would say installing something like tripwire is not overkill.

ClamAV is a different matter. I would consider setting that up that if your visitors will be sharing files by uploading to, and downloading from, your website. PDFs can contain exploits.

On public facing servers, I have SSH not allow password authentication, only public-key authentication. If SSH is only possible from an internal LAN then you might relax this.

Where possible I'd place the server on a DMZ so that it cannot originate connections to any other computers on your internal LANs.

Nope, you didn't go far enough.

1)You need a web application firewall like mod_security and make sure its configured to block attacks, not just log them.

2)Lock down php with phpsecinfo.

3)Lock down your web application's MySQL account, make sure your application doesn't have FILE privileges, its by far the most dangerous one in MySQL.

4)Firewall off all UDP, and all TCP that you don't need. Consider using port knocking for ssh. Fail to ban isn't nearly as good as getting zero attempts.

You can probably safely install AIDE on a web server - adding and removing customers doesn't change too many configuration files, and you could probably filter out the normal chatter pretty easily.

But something that a lot of web server security guides don't mention is that you should turn noexec on on your /tmp partition in /etc/fstab. If you're offering hosting to the public, a good many people will install insecure web applications without your knowledge (and not have the knowledge themselves to keep their applications up to date), and you're basically chasing these bugs down forever. If you make sure that the only place an attacker can save software is the customer's home directory and the /tmp directory, then the attacker runs the risk of showing you where they're breaking in if they can't use the /tmp directory. They don't like doing that.

Doing this has solved the vast majority of the security problems on our web hosting server.

"Welcome aboard! On board of our new airliner you can enjoy restaurant, cinema, gym, sauna and swimming pool. Now fasten your seat belts, our captain is going to try to get all this shit airborne."

1. mod_security is a pain for both you and server. It's resources hungry and its rules need serious maintaining and it's going to be a neverending task. And no, it doesn't work standalone or with Nginx. If you feel like you really need it, setup a separate proxy server (Apache, mod_proxy, mod_security). It also works as DMZ, your real servers can be closed to the outer world completely, and if the proxy is breached, there is nothing anyway.

2. ClamAV is very heavy, too, if run as a daemon. It's better to run clamscan periodically during non-active hours from Cron.

3. Tripwire is overkill, IMHO. But something able to hunt down rootkits would be useful, there are plenty of scripts (rkhunter, chkrootkit).

4. I believe at least 90% of rootkits etc. get to servers via uploads from devs Windows machines. There's no really good way to prevent this except maybe forcing devs to never use Windows. Most of trojans search for FTP credentials, so never use FTP.

Is using captcha form protection in popular CMS engine (Wordpress, Jomlaa, Drupal) considered as security practices? If yes, then you can use these:

• Mollom
• Aksimet
• Defensio