

Ask HN: SaaS/VPS server security - tonteldoos

Good day all,<p>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:<p>What process do you follow to secure your servers (regardless of OS), and how much effort do you invest in this (think 80&#x2F;20, not &#x27;how little can I get away with&#x27;)?<p>Some more comments:
- It would appear that everyone and their dog nowadays has at least one VPS being hosted somewhere.  Based on DigitalOcean&#x27;s online security docs, it also appears that the default images available are not &#x27;secure&#x27; - why not?<p>- 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&#x27;re running a VPS to play with, vs hosting a service used by other people.<p>- 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.<p>- 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).<p>- 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).<p>- 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.<p>Kind regards,
======
quesera
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
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)?

------
cweagans
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
CSF,
[http://configserver.com/cp/csf.html](http://configserver.com/cp/csf.html)

