2

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?

Improve this question

3 Answers 3

Reset to default
2

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.

Improve this answer
2
  • What's the use of suexec when you are the only user?
    – Gleb
    Oct 1, 2009 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, 2009 at 1:55
2

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.

Improve this answer
0

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.

Improve this answer
2
  • 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?
    – Alana Storm
    Oct 1, 2009 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, 2009 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .