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.

After nearly a decade (yikes) of hosting my personal websites and applications with a decent shared web hosting provider (the one in pittsburgh) I've decided its time to venture out on my own and try a virtual private server.

The one thing that's been holding me back is I know my shared web host has a number of custom built security/instruction-detection systems setup to deal with problems common to hosting clients who want to run PHP applications. I'm loath to give up that peace of mind, but the extend of my admin skills are doing cause/effect style exploration with configurations, and parsing through logs to see "oh, that's how they f---ed us".

That context set, if I was going to setup an account with a linux based VPS for Apache web hosting

  1. What steps would I take to secure the machine?

  2. What additional monitoring packages could/should I install?

share|improve this question

3 Answers 3

up vote 2 down vote accepted

This is what I typically do:

  • Install a good firewall. Egress filtering is just as important as ingress. If someone manages to get an IRC bouncer running on your VPS, it would be nice if it could not talk to the outside world. APF is pretty decent for this and is easy to configure.
  • Install mod_security quickly. You can get some really comprehensive rules that are updated rather frequently from the guys at Gotroot. Disclaimer, one of them is a friend of mine.
  • Configure PHP with suexec, make sure your PHP scripts run as the user who owns them. Additionally, configure PHP with only what you need.
  • Don't weaken your PHP configuration just to run some script you find. In other words, don't turn on register_globals just so some antiquated shopping cart works.
  • Remote syslog servers are always good. Perhaps get two VPS servers, use one to store backups and handle logging.
  • Run daily rootkit checks. Run the first one immediately after you set up your server, before you put it in production. These work by storing hashes of system executables and detecting when things change, as well as looking for signatures of common exploits.
  • If on a VPS where the host controls your kernel, insist that they keep it up to date. For instance, a weakness in the linux vmsplice allowed ordinary users to easily become root. Make sure your provider does their diligence in matters out of your control.
  • Make some friends on various hosting related forums, search them as well as SF for answers and tips. This type of question is quite common on those forums.

These are in addition to items that others have suggested. Many more advanced tools exist, such as snort - I recommend that you look into them. However, this checklist should be good to get you going on a VPS.

share|improve this answer
    
What's the use of suexec when you are the only user? –  Gleb Oct 1 '09 at 1:29
    
@gleb It was assuming that each hosted domain would have its own user, home directory, etc (which is a good idea for various reasons). What you don't want are files in /tmp owned by 'nobody' or 'www-data', depending. –  Tim Post Oct 1 '09 at 1:55

Step 1: Update your software as patches come out. If patches don't come out regularly for the projects you use, it's time to find alternatives that do.

Step 2: Offsite logging. Attackers may compromise a machine with PHP, but if you export the logs over the network to a stronger server, it's that much harder to cover tracks.

Step 3: Secure SSH logins. Run SSH on a nonstandard port. Require strong passwords, or even restrict logins to SSH keys. Install fail2ban or some other brute force detection tool to prevent being overwhelmed. Disable root access if your distro is silly enough to allow it.

Step 4: Update your software. It bears repeating. PHP is notoriously bad, and shared hosting can make it a massive pita to update, ingraining bad behavior. Projects like Debian package stuff you might find in PEAR and update. Subscribe to mailing lists and schedule time daily or weekly to address patching.

Step 5: Backups. When you do get hacked, it's safest to restore from a known good system. Incremental backups can help you with this.

There's tons of Intrusion Detection packages, like snort, aide, and acidbase. There's also pentesting tools like nessus/openvas.

I also like directing a simple uptime tool at VPS's, to document outages in case a refund is in order.

share|improve this answer

jldugger offers many great ideas - I'd add on to that that you'll probably want to look into apache's mod_security as well as suexec. Mod_security comes with a bunch of pre-made filters that inspect http calls to your server and reject them if it sees something fishy. Suexec lets you run php/perl/etc scripts as the user that owns them as opposed to them all being run under the www-data user.

share|improve this answer
    
Something I've wondered about Suexec and it's ilk for decades ... I see the value of having the scripts run as "me" instead of nobody/the apache user in a shared setup (no 666/777 permissions hanging around) However, I was always taught if I was the only one on the box is was "better" to have scripts/apache running as a non privlaged user so that if someone was compromised the attacker would have a limited number of things they could do on the system. Since you seem to know what you're talking about, do you have any insight on that thought? –  Alan Storm Oct 1 '09 at 4:31
    
If you're the only person on the server, then I guess there's not a whole lot of utility in running suexec. If you ever anticipate hosting for friends or whatever, it might be worth getting it set up now so that it's easy to spin up accounts for them in the future. If that's not a possibility, though, then you'll probably be fine without suexec. –  EEAA Oct 1 '09 at 14:59

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.