earlier this week we bought a virtual private server (vps) with 34sp.com with the view of moving me and lou’s domains to it (our friends have been kindly hosting both). i thought it would be a good idea to keep a log of how we did it. now, normally this would be a very boring log, but almost immediately after firing up the vps i was shocked by how quickly the hackers started calling around. so instead of this log being used to track software installs, it will have a security twist to it.

in an impossibly perfect world, you’d stick a static content webserver in the dmz i.e. no cgi and push updates from production to it. but this ain’t, and i need to keep all my eggs in the one basket! so i’m going to try my best to keep the script kiddies out and make it worthless for the more seasoned hackers to do any poking around. seriously dudes, there won’t be financial or customer data on this server, it’s just a blog site!

so far i’ve achieved the following:

• lock down ssh:
  • disable root login (requires a non-root account to be used instead)
  • disable password auth (pub key only)
  • enable denyhost (becareful not to lock yourself out!)
  • move off port 22 (security through obscurity, but will stop most script kiddies)
• lock down mysql:
  • listen only locally (don’t switch to local socket files because tunneling a mysql connection won’t work)
• security auditing:
  • run scripts against secure and lastb logs (looking for suspect logins)
  • run chkrootkit nightly (checking for rootkit, would’ve its support bins were in a read-only environment so my rootkit doesn’t get patched by an anti-rootkit-script)