You can spin up a new VPS in a couple of minutes. That doesn’t mean it’s ready for your production site.
The moment a server gets a public IP address, bots start knocking. Automated scanners and password-guessing scripts sweep the internet around the clock, and they don’t care that your server is brand new. You won’t make it bulletproof (nobody can), but you can close the obvious doors before anyone tries them.
This guide covers how to secure a Linux VPS running Ubuntu or Debian. Commands differ a little on other distros. If the server already runs something important, go slowly and keep a way back in.
Before you touch anything, make a quick plan
List what the server actually needs to do. A web server probably needs SSH for you and HTTP/HTTPS for visitors. A database server might only need to talk to your app server. If a port is open and you don’t know why, find out before you leave it that way.
And sort out your escape route first. Keep your current SSH session open while you test changes in a second one. Check whether your provider has a web console or recovery mode. Locking yourself out with your own firewall rule is a rite of passage, but it’s one you can skip.
1. Update everything first
Before installing your app, update the operating system. Security patches fix known holes, and a server that falls behind on updates gets harder to defend every week. On Ubuntu or Debian:
sudo apt update
sudo apt upgradeHave a quick read of the package list before you hit “Y”, especially on a live machine. Some updates need a service restart or a reboot. Afterwards, make sure SSH and anything else you’ve installed still works.
Automatic security updates are worth turning on, but set them up with your app in mind. Keep an eye on the update reports and have a plan for testing anything that could break production.
2. Use SSH keys, and set them up carefully
SSH is how you’ll manage the server remotely. Use key-based login for admin access. Generate a key pair on a computer you trust, add the public key to the right account on the server, and test that it works.
Don’t turn off password login until you’ve tested the key in a separate session and you know how you’d get back in if it failed. Put a passphrase on your private key and never send it to anyone. If more than one person manages the server, give each of them their own account and key. Shared logins make it impossible to tell who did what.
3. Stop logging in as root
Logging in as root is convenient. It’s also a bad daily habit. Create a named admin account and give it sudo rights. That way you only use full permissions when you actually need them.
Clean up accounts you no longer use, and check the authorised SSH keys every so often. When a contractor or staff member leaves, removing their access should be part of offboarding, not something you remember six months later.
4. Set the firewall up around what you actually run
Your firewall rules should match the server’s job. For a basic public website, that might mean SSH allowed only from your own IP addresses, plus web traffic on ports 80 and 443. A database port shouldn’t be open to the whole internet if your app can reach it over a private network.
On Ubuntu, UFW is a simple way to manage this. Before you switch it on, allow your current SSH connection and any other services you need. Apply the rules, then test from another session. A firewall that locks out the admin isn’t secure. It’s just broken.
5. Get rid of services you don’t need
Every extra service is one more thing to configure, patch and watch. Check what’s listening on the server and turn off anything that doesn’t belong there. Don’t install a control panel, mail server or database “just in case”. Add them when you need them, and have a plan to maintain them when you do.
6. Don’t forget the website itself
A locked-down operating system won’t save you from an outdated WordPress plugin. Keep your CMS, frameworks, themes, plugins, libraries and web server up to date. Stick to supported versions and remove anything that’s been abandoned by its developer.
Set file permissions so your app can only write where it has to. Use HTTPS, and check that certificate renewal actually works before the cert expires. Keep credentials out of public folders, use unique passwords and switch on two-factor login for your hosting panel and anything else that offers it.
7. Backups are part of security
When an update breaks the site, a file gets deleted or the server gets compromised, backups are what save you. Work out what you’d need to restore: site files, databases, config, uploads and any data you can’t recreate.
Store copies somewhere other than the VPS. If an attacker gets admin access, backups sitting on the same machine are fair game too. Back up as often as the data changes, and actually test a restore on a separate server. A backup job that says “success” isn’t the same as a backup you can recover from.
8. Keep an eye on logs and resources
You don’t need to watch a terminal all day. You do need to know when something looks off. Monitor disk space, CPU, memory, network traffic and whether your key services are up. Set alerts for low disk space and failed services before they turn into an outage.
Check the auth logs for piles of failed logins or access you don’t recognise. Make sure logs rotate so they don’t quietly fill the disk. For anything public-facing, add an outside uptime check as well as monitoring the server itself.
9. Know what DDoS protection does (and doesn’t do)
A DDoS attack tries to flood a service with so much traffic that real users can’t get through. Network-level DDoS protection filters or absorbs a lot of that before it ever reaches your server.
What it won’t do is stop someone guessing a weak password, exploiting an old plugin, stealing an API key or deleting your data. VPSNerds includes DDoS protection across our hosting services, but on a VPS, keeping the operating system and applications secure is still your job. Think of it as one layer of the plan, not the plan.
Pre-launch checklist
- OS and packages are fully updated.
- SSH key login tested, private keys protected.
- Admin work done from named accounts with only the access they need.
- Firewall only allows the ports the server actually uses.
- Unused services removed or disabled.
- Website, control panel, frameworks and plugins kept up to date.
- Backups stored off the server, and a restore has been tested.
- Monitoring and alerts set up for uptime, disk space and resource use.
Security never really ends
There’s no single script or plugin that makes a VPS secure. It comes down to habits: keep things updated, limit who can get in, only expose what you need, and know you can recover when something goes wrong. Go back over the setup whenever the app changes, someone new gets access or you add a service.
VPSNerds Cloud Servers come with full root access and your choice of operating system, so you can set the server up exactly how your workload needs it. Planning a new deployment? Take a look at our Cloud Server options, and make sure you’ve got a plan for who looks after it once it’s live. Questions about your setup? Contact our team or visit our support page.
FAQs
Does a new Linux VPS need a firewall?
Yes, it’s one of the first layers worth adding. Only allow the services the server needs, and make sure your own admin access is allowed before you switch on strict rules.
Should I change the default SSH port?
It cuts down on noise from basic bots, but it isn’t real protection on its own. SSH keys, access restrictions and updates matter far more. Treat a custom port as a nice-to-have.
Does DDoS protection secure my applications?
No. It helps with certain attacks that target availability. App vulnerabilities, stolen passwords, malware and data loss all need their own protection.
