On a VPS, you are compressing your entire network architecture down to a single OS instance. Still, the basic rules apply: - Do not run unnecessary services. Y

On a VPS, you are compressing your entire network architecture down to a single OS instance. Still, the basic rules apply: - Do not run unnecessary services. You probably don't need to run ntpd, for example. - Choose your necessary service packages carefully, and learn how to configure them securely. qmail or Postfix over sendmail. - Bind all non-public services to internal addresses or sockets only. - Enable your host packet filter, write good rules. - Separate services as much as practical. Jails, zones, etc, whatever your OS provides. - Configure sshd properly. Consider blocking connections from untrusted IP addresses. Consider port knocking. - Minimize user accounts. - Follow security announce lists for the few public-facing servers you run. - If you're running your own software (web app or whatever), make sure you learn how to avoid common mistakes. - If you find you must run something with a poor security history, do it on a sacrificial host/jail/zone/etc that can be recreated with minimal effort. Make the public facing server a content-clone of some other protected instance. That's pretty much the minimum for a standard random-acts-of-violence threat model, in my estimation. If you have more pernicious attackers, this will not be adequate. If it sounds like too much work, keep good backups and hope for the best -- but remember, recovering from a breach is a heck of a lot of work too. Time spent now saves multiples later. If you're handling sensitive user data, hire someone who can do all of the above in his or her sleep. Or reconsider your choice to handle sensitive user data. There is always a balance to be struck, but this is the baseline because it accomplishes two things: it prevents all known and most expected vectors of attack, and it contains the damage if you are ever surprised.