VPS Security: Pick a good provider. For all intents, he’s got root to your system, and potentially your data is only a simple vzctl command away. Consider that vps provider is protecting the console for your system.
VPS Security – Protect Login Details
Protect your billing login. If you have a WHMCS account and someone hacks it, they can easily hack your system, not to mention having all your personal info. Pick a good password and use 2FA if possible.
Protect your email login. OK, we’re getting more theoretical but if your email is hacked then so is everything else due to recovery procedures. make sure to use 2FA on you’re email.
Pick good passwords. Really. And unique ones ideally.
Even better, don’t use passwords. Generate ssh keys and login that way. Note that I didn’t say “passwordless ssh to root”. Passphrase-protected ssh keys are two-factor (something you know, something you have)… if you make them passwordless, you’re back to one factor and it’s potentially the least secure of the two. Of course, you might automate some things with passwordless ssh…
VPS Security – Important configurations
Get familiar with sshd_config. Think from a “least privilege needed” perspective. If you have someone/something that needs to come in over ssh, would sftp work? Because then you can lock that user down to only sftp (no chance to execute anything). Can you chroot the user? If not, how much work to change that, because otherwise you’re giving them wide range. Etc.
Consider disallowing root login. It’s not right in every scenario but usually it is.
Update your system regularly. This is obvious.
Subscribe to security alert emails for your OS/distro and major software. The big Heartbleeds always make the news but a lot of important fixes and problems don’t.
Turn stuff off. You should only run services you need. Just because the OS ships with things turned on doesn’t mean you have to leave them that way.
Scan yourself. Run nmap on your public IP. Sometimes you’ll be surprised to find something’s running.
Use a Firewall
Use a firewall for access control. You need to connect to your box – sure. But from everywhere on the planet? Here are some simple controls:
- Only allow ssh from certain other boxes (obviously, at least two in case one is down).
- Require a knock – e.g., the client has to connect to some port first, then the ssh port is unlocked on the firewall.
- Use an active firewall to filter out countries where you are not – e.g., if you’re the US, you might allow web from all over the world, but there’s no reason someone should be trying sftp from South America or Australia, so you could filter those.
Use an active firewall/fail2ban. This is really important if you have externally facing login systems like mail. fail2ban, CSF/lfd, etc. will watch logs and if someone repeatedly fails to login, a temporary firewall rule will block that IP. Many options, and particularly if you’re not a security ninja and don’t want to become one, the simplification of options is helpful.
Use a firewall as a firewall. Even if I’m only running ssh, I still keep a firewall up. Too easy for a package dependency to install something new, or for a bug in something (often my code!) to turn something on.
Does everyone need to be able to get to wp-admin.php . Think about some of the apps you use and see if at least http basic authentication wouldn’t make them more secure.
Keep versioned backups. If your only backup is a nightly rsync at 2am and you get hacked at 1am…when you get up in the morning, you’re going to be frowny faced. You should have regular restore points – whether that’s applying a weekend full and rolling forward incrementals, or you do a full every night, etc.
Don’t use default SSH Port
Change the ssh port. This is controversial but I do it, chiefly because it immediately filters out a vast array of skiddies who check port 22 and move on if it’s closed. Obviously a more serious attacker would do a full port scan and it would be easy to discover if you’re running ssh on a different port.
Some people say it’s the false security by obscurity, but as long as you understand it, there really is no harm and a small benefit. One consideration sometime raised is that if you run sshd on a high point (>1024), non-root users on the system could conflict or masquerade.
If that is a potential problem, there are plenty of unused ports below 1024 that only root can open. Look in /etc/services and find an unused one. Or a used one that you won’t be using.
Email on login. If you or a small group are the only people who should be on a server, why not get an alert whenever it’s accessed? There are several methods.
