Security a Linux VPS: is the "standard advice" enough?

Question

Like so many others, I'm an intermediate web developer who is starting to get into the security side of things and I'm looking to start running a Linux VPS (Debian). For years, I've resisted the move to VPSs because of the security implications. There are many, many guides available on the internet and even questions on this StackExchange.

However, I'm still uncertain if what these guides recommend is sufficient. To be clear, here is what I consider as "standard advice":

1. Regular system updates
2. Regular backups
3. Disabling root access, create limited user account (with sudo privileges)
4. Harden SSH access (use key files, disable root logins, change port, listen on only one inet protocol
5. Use Fail2Ban
6. Remove unused network-facing services (ex: samba, lp, Xserver)
7. Configure a firewall
8. Configure an intrusion detection system (ex: OSSEC, Tripwire)
9. Run regular malware checks (maldet, ClamAV, rkhunter)
10. Disable IPv6 (I'm not sure about this one)
11. Make /boot read-only (I'm not sure about this one either)

For further information, my use case is the following: a server that holds very sensitive personal information and messages and would be a potentially desirable target for attacks. In this case, is the "standard advice" enough?

P.S. I'm aware that the best thing to do would probably be to hire a security expert, but I'm working pro-bono for a non-profit and they don't have the budget for it.

Answer 1

For further information, my use case is the following: a server that holds very sensitive personal information and messages and would be a potentially desirable target for attacks. In this case, is the "standard advice" enough?

I would rather say it's the minimum. But some of the advice is questionable though. Since you mention 'very sensitive personal information' the bar has to be even higher than that.

If you have very sensitive personal information, you need to think about the potential damage and also your legal liability. Working pro bono does not mean you cannot get sued if things go wrong. Even if you escape legal repercussions your reputation could take a hit. If you are in the EU or under EU jurisdiction, GDPR applies and there are steep fines for failure to protect personal data. Other countries/states may have similar provisions.

Maybe it would be a good idea to request a professional penetration test to validate your setup. If the non-profit you are looking for doesn't have the budget now, will they have the budget to handle the fallout when things go wrong ?

I am a firm believer in Murphy's law: Anything that can go wrong will go wrong.

Even if your VPS is extremely well-secured, The webhost could get hacked. If a hacker gains access to the hypervisor systems, he will have access to the VPSes. Someone who is after valuable data is going to find workarounds, find a weak spot somewhere. If you have a domain name, the hacker could hijack it by taking over your registrar account. So you always depend on third party providers.

Probably you are going to be hosting some application along with the data. Do you know the inside out of it ? Maybe it is full of bugs and riddled with vulnerabilities like SQL injections. Then even a well-secured server will not help. The application has to be evaluated and audited as well.

Advice: think twice before accepting an assignment where you have nothing to gain and much to lose, especially if you think you lack the practical experience. This 'client' does not look like one that can be used as a guinea pig or training platform. You have no obligation to take on this job, and you don't want to be the lonely guy taking all the blame.

Answer 2

The answer is simple: no. You can do all sorts of things on your server to make it more secure, give less access et cetera, but at some point in time, there will be vulnerabilities. Regular system updates will protect you against them if you apply them very regular, but even then, they will always be a bit behind.

It means that you will need to create an environment where the server itself is less exposed. If the server holds holds very sensitive personal information, you would be a fool if you expose this directly to the Internet. If you put your server behind a dedicated firewall and make it accessible via a VPN tunnel with two factor authentication on the firewall, then your server is a lot safer. But it depends on your use.

The point is, that just throwing standard security measures at a server without understanding the risks that you run, creates a lot of work which may be partially pointless. You need to understand how the server us used, how it should be accessed and what are the risks that it is accessed wrongly.

And some of the advice is a bit outdated or open for discussion. For example: changing the ssh-port is not really a security measure anymore. And instead of key-files, two factor authentication may be sufficient too. Oh, and why should anyone log into the system (except for emergencies) other that via the application anyway?

What is missing from the list is monitoring and follow-up. Read the access-logs. an IDS is nice, but if you don't follow-up on the alerts, it is pointless.

And then the application. That is used to access the data. If your application has vulnerabilities, then all your OS-level measures are of little use.

So do a threat analysis. Understand why you want to take certain measures, which threat they mittigated. Take measures in you network too. Create an environment where you don't have to log in every time (central log collection, automatic patching etc.)