4 ms·

Ask HN: SaaS/VPS server security

17 points by tonteldoos 12y ago

Good day all, I have a question for all the fellow HNers out there who run their own servers on VPSs, or provide early stage SaaS products, or anyone who has actual metal connected to the internet: What process do you follow to secure your servers (regardless of OS), and how much effort do you invest in this (think 80/20, not 'how little can I get away with')? Some more comments: - It would appear that everyone and their dog nowadays has at least one VPS being hosted somewhere. Based on DigitalOcean's online security docs, it also appears that the default images available are not 'secure' - why not? - There are lots of articles on basic security (closing ports, firewalls, logging utilities, security updates, basic pen testing, etc), but what is considered an absolute minimum level of effort to secure your server, and at what point is your effort overkill? Note that this may differ if you're running a VPS to play with, vs hosting a service used by other people. - How do you ensure your efforts are working, assuming you might not have $$$ available to pay a professional firm to monitor it for you (e.g. Kali linux, but again - which tools, how much time,etc). If you have $$$ available, what is an effective level effort someone should be putting into it. - What are the most prevalent attacks being done against servers. About 10 minutes after your IP goes live, you can see it being pinged and portscanned, but to what extent are exploits actually being used, and how concerned should you be (i.e., how carefully should you monitor log files, etc). - Disregarding high profile hacks (ebay, Target, etc), how many people have actually had servers compromised, and what level of damage was done (defacement, exfiltrated data, complete destruction). - If you do comment, information on OS and version used would be interesting - are there distributions that are inherently more secure or easy to secure than others. Kind regards,

quesera 12y ago
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.
- tonteldoos 12y ago
  All very good points - thank you! Do some of them come from hard won experience? With regards to sensitive user data - depending on your point of view, that can be fairly wide (passwords through to, say, medical history). Where would/do you draw the line? Obviously as much as is possible/feasible should be encrypted in some fashion, but at what point does even losing the encrypted data become an issue (assuming it's well encrypted, not just hashed with no salts)?
- huxley 12y ago
  If your server does need to maintain time sync with NTP servers, OpenNTPD Portable is generally considered a secure alternative to ntpd
cweagans 12y ago
Specifically with SSH, I always recommend this: No passwords. Ever. Turn off PasswordAuthentication in sshd_config. Use SSH keys instead. Personally, I think if you're running SSH in this mode, it's safe to run it on the default port and not really worry about locking access down to certain IP addresses/ranges.
shaunpud 12y ago
CSF, http://configserver.com/cp/csf.html http://configserver.com/cp/csf.html

17 points by tonteldoos 12y ago

quesera 12y ago

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.

tonteldoos 12y ago
All very good points - thank you! Do some of them come from hard won experience? With regards to sensitive user data - depending on your point of view, that can be fairly wide (passwords through to, say, medical history). Where would/do you draw the line? Obviously as much as is possible/feasible should be encrypted in some fashion, but at what point does even losing the encrypted data become an issue (assuming it's well encrypted, not just hashed with no salts)?
huxley 12y ago
If your server does need to maintain time sync with NTP servers, OpenNTPD Portable is generally considered a secure alternative to ntpd

cweagans 12y ago

Specifically with SSH, I always recommend this: No passwords. Ever. Turn off PasswordAuthentication in sshd_config. Use SSH keys instead. Personally, I think if you're running SSH in this mode, it's safe to run it on the default port and not really worry about locking access down to certain IP addresses/ranges.

shaunpud 12y ago

CSF, http://configserver.com/cp/csf.html http://configserver.com/cp/csf.html