Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've been doing "extensive" research on securing a linux web server. On top of what is considered the "basics" (removing unused services, hardening ssh, iptables, etc.) is it wise to include anti-rootkits (Tripwire) and an anti-virus (ClamAV)? Are these just overkill for a web server? I know this is a very vague question, but I'm curious on others opinions.

My future environment: - ubuntu 10.04 - fail2ban - nginx 0.8.x - php 5.3.x (suhosin, apc, memcached) - mongodb 1.6.x

Possible applications: - web services - web apps with user uploads (pictures, pdfs, etc.) - typical websites (forms, etc.)

If you have any other tips, please feel free to add!

Thanks

share|improve this question

5 Answers 5

"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.

share|improve this answer
    
Good to know... Considering I have no intention of taking the apache route, I'll stick to whatever security aspects I can find for nginx. I will probably end up taking the clamscan / rkhunter route, as well. Thanks for the tips! –  Aaron Nov 16 '10 at 16:32

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

share|improve this answer

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.

share|improve this answer
    
1) I was under the impression that ModSecurity could only be packaged with Apache (I'm using nginx). But apparently it can run standalone? I'll have to look into this thanks! I've followed calomel.org/nginx.html for a few features. –  Aaron Nov 16 '10 at 10:03
    
4) I use iptables to block all incoming and outgoing traffic unless it is my ssh port, https, or https (incoming, outgoing). I'll open more up as I go along. Port knocking is an interesting addition for ssh, though! Thanks again!. –  Aaron Nov 16 '10 at 10:26
    
@Aaron i'm not sure why you'd use nginx. You can use apache+mod_security as a proxy with whatever strange and featureless httpd you demand using. –  Rook Nov 16 '10 at 16:22

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.

share|improve this answer

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.

share|improve this answer
1  
Don't forget LMD (Linux Malware Detection), rfxn.com/projects/linux-malware-detect - this scans for the sort of malware that infects web applications (HTML, PHP, JavaScript file changes) in order to use your site for SEO spamming, phishing, infection of visitors' PCs, etc. –  RichVel Jun 20 '12 at 8:23

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.