A beginner's guide to securing your VPS

A new VPS is on the internet from the minute it starts, and automated scanners will find it within hours. Most of them are not after you in particular. They try common passwords, look for old software and probe for services left open. If your server has no easy openings, they move on.

This guide explains how to close those openings, in order of how much each step matters. It covers SSH, updates, the firewall, services that should not be public, apps, secrets, backups and a simple routine to keep it all in shape. It assumes Ubuntu or Debian, but the ideas apply to any Linux server. It will not make a server unbreakable. Nothing does. It will make yours a much harder target than most.

What is in this guide

• A few words you will see
• How small servers get broken into
• The priorities at a glance
• 1. Protect your accounts
• 2. Lock down SSH
• 3. Keep everything updated
• 4. Turn on a firewall
• 5. Check what is exposed
• 6. Secure your apps
• 7. Look after secrets
• 8. If you use Docker
• 9. Keep backups the server cannot delete
• 10. Watch for trouble
• A simple routine
• Limits
• When to step up

A few words you will see

Term	What it means
Attack surface	Everything on your server that someone on the internet can reach and try to break.
SSH	The secure way to log in to a Linux server and run commands.
SSH key	A pair of files used to log in instead of a password. Much harder to guess.
Root	The all-powerful admin account on Linux.
sudo	A command that lets a normal user run one admin command at a time.
Port	A numbered door on the server that a service listens on, such as 22 for SSH or 443 for HTTPS.
Firewall	Rules that decide which ports can be reached from the internet.
Bind	Choose which address a service listens on. 127.0.0.1 means "only this server".

How small servers get broken into

Almost every break-in on a small VPS comes through one of a few doors:

• A guessed password, usually for SSH or a web app's admin login.
• Old software with a known security hole, most often a web app plugin or theme.
• A service left open with no password, such as a database, cache, dashboard or the Docker API.
• A leaked secret, such as an API key committed to a public code repository.
• Something untrusted that you installed, such as a script or container image from an unknown source.

Every step in this guide closes one or more of those doors.

The priorities at a glance

Step	Effort	Protects against
SSH keys only, no passwords	15 minutes	Guessed passwords, the most common attack
Automatic security updates	5 minutes	Known holes in system software
Firewall with only needed ports open	5 minutes	Services you forgot were listening
Bind internal services to 127.0.0.1	Per service	Open databases, caches and dashboards
Keep apps and plugins updated	Ongoing	Web app break-ins
Backups kept off the server	An hour	Losing everything when something goes wrong

If you only have half an hour, do the first three. If you have just bought a server, your first hour on a new RackNerd VPS walks through them step by step. This guide explains why each matters and adds the rest.

1. Protect your accounts

Your server is only as safe as the accounts that control it.

• Your RackNerd client area can reinstall or cancel the server. Give it a long, unique password, stored in a password manager, and turn on two-factor login if it is offered.
• The VPS control panel can reboot the server and open a console. Change its password from the one in the welcome email.
• Your email account can reset all of these. Protect it with two-factor login too.
• Your domain registrar controls where your website points. Protect it the same way. See domains and DNS explained.

2. Lock down SSH

SSH is the main door into your server, and bots try it constantly. Three changes close it to almost all of them.

1. Use SSH keys. A key cannot be guessed the way a password can. How to connect with SSH and set up SSH keys shows how on Windows, macOS and Linux.
2. Use a normal user with sudo, not root, for everyday work.
3. Turn off password login and direct root login, once key login works.

A tidy way to make the last change is a small settings file of your own, rather than editing the main one. Create it:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Put these lines in it:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
MaxAuthTries 3

The name starts with 00 on purpose. SSH uses the first value it reads for each setting, and reads these files in name order. Some server images include a file in the same folder that turns password login back on, and an early name makes sure yours wins.

Check the settings, confirm what SSH will actually use, and restart it:

sudo sshd -t
sudo sshd -T | grep -E "passwordauthentication|permitrootlogin"
sudo systemctl restart ssh

The middle command should show passwordauthentication no and permitrootlogin no. On some systems the service is called sshd instead of ssh. Keep your current session open, and test a new login in a second window before closing it. If you get locked out, the console in the VPS control panel still works.

Should you change the SSH port? Moving SSH from port 22 to another number cuts down log noise from bots, but it is not real protection. Keys and no passwords are what matter. If you do change it, open the new port in the firewall before you restart SSH.

3. Keep everything updated

Security fixes come out all the time. On Ubuntu and Debian, the unattended-upgrades package installs security updates automatically:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Choose Yes when asked. Then, every week or two, log in and run a full update yourself:

sudo apt update && sudo apt upgrade

Some updates, especially to the kernel, only take effect after a reboot. If the file /var/run/reboot-required exists, reboot at a quiet time.

System updates do not cover everything. Web apps such as WordPress, their plugins and themes, and Docker images all need updating separately. That is covered in steps 6 and 8.

When your Ubuntu version itself nears the end of its support, plan an upgrade. Upgrading an Ubuntu server explains how.

4. Turn on a firewall

A firewall blocks every port you have not chosen to open. That protects you from services you forgot about, or that opened a port without telling you. UFW is the simplest firewall on Ubuntu, and can be installed on Debian:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Always allow SSH before you enable the firewall. Then open only what you need:

Service	Command
A website	sudo ufw allow 80,443/tcp
A WireGuard VPN	sudo ufw allow 51820/udp
A game server	The game's port, from its own documentation

To allow a port only from your own IP address, which is a good idea for admin tools: sudo ufw allow from YOUR_IP to any port 22 proto tcp.

5. Check what is exposed

Every program that listens on a port is a possible way in. List them:

sudo ss -tulpn

Look at the address column for each line:

• 127.0.0.1 or [::1] means only the server itself can reach it. That is what you want for databases, caches and internal tools.
• 0.0.0.0, * or [::] means it listens on every address, so the firewall is the only thing protecting it.

For anything that does not need to be public, change its settings so it listens on 127.0.0.1 only. Then reach it from your own computer through an SSH tunnel, for example:

ssh -L 8080:127.0.0.1:8080 alex@SERVER_IP

While that session is open, the tool appears on port 8080 of your own computer. For tools you use often, a private VPN is another option. See setting up a WireGuard VPN.

Remove anything you no longer use with sudo apt remove. Fewer programs means fewer doors.

6. Secure your apps

Once SSH is locked down, most break-ins come through web apps. A few habits stop most of them:

• Update apps, plugins and themes. Turn on automatic updates where the app offers them. Old plugins are the most common way into WordPress sites.
• Remove what you do not use. An inactive plugin can still be attacked. So can an old test site.
• Strong admin passwords and two-factor login wherever the app supports them.
• Turn off open sign-up on apps that allow anyone to register, unless you want public users.
• Never put a service online without a login. Some apps start with no password at all. Set one, or keep the app private behind an SSH tunnel or VPN.
• Use HTTPS. Free certificates from tools such as Certbot or a web server like Caddy keep passwords encrypted. See web servers on a VPS.
• Block repeated login attempts. Fail2ban watches logs and blocks addresses that keep failing. See installing fail2ban.
• Install from trusted sources only. Use your package manager, official images or the project's documentation. Avoid running install scripts piped straight from a web page.

7. Look after secrets

Passwords, API keys and tokens are as valuable as your server itself.

• Keep them in env files or config files that only the app's user can read, set with chmod 600.
• Never commit them to Git, even in a private repository. Add env files to .gitignore.
• Never paste them into chats, forums or AI tools.
• Use a separate key for each app and each server, so one leak does not expose everything.
• If a secret may have leaked, revoke it in the service's dashboard and create a new one. Deleting the file is not enough.

8. If you use Docker

Docker is handy, but it has two security surprises for beginners:

• Published ports can bypass UFW. A container port published as 8080:80 can be reachable from the internet even if UFW looks closed. Publish internal services on the local address instead: 127.0.0.1:8080:80.
• The docker group is as powerful as root. Anyone in it can take full control of the server. Only add users you would trust with root.

Use images from official or well-known publishers, update them regularly, and never expose the Docker socket or API to the internet. Installing and using Docker on a VPS covers this in more detail.

9. Keep backups the server cannot delete

Security is also about recovering when something goes wrong. A backup on the same server is not a backup: a hacker, a mistake or a disk failure can take it with everything else.

• Keep copies somewhere else, such as a second server in another location or your own computer.
• Best of all, let the backup server pull copies from your main server. Then someone who breaks into the main server cannot delete the backups.
• Encrypt backups and test a restore now and then.

Using a storage VPS for backups has a full walkthrough.

10. Watch for trouble

You do not need complex tools. A few checks catch most problems early:

Check	Command	What to look for
Recent logins	last -n 20	Logins from places or times you do not recognise
Successful SSH logins	sudo journalctl -u ssh --since "7 days ago" | grep -i accepted	Logins you did not make
What is running	top	Unknown programs using lots of CPU
What is listening	sudo ss -tulpn	New ports you did not open
Disk space	df -h	Disks filling up unexpectedly

An outside uptime check, run from a different server, tells you when a site goes down. If you ever find signs of a break-in, what to do if your VPS is hacked takes you through the response.

A simple routine

How often	What to do
Weekly	Run a full system update. Update web apps and plugins. Glance at recent logins.
Monthly	Check ss -tulpn and ufw status for anything unexpected. Check backups ran, and reboot if updates need it.
Every few months	Test restoring a backup. Remove apps, users and keys you no longer use. Check when your operating system version reaches end of support.
When you add something	Bind it to 127.0.0.1 unless it must be public. Open only its port. Note what you changed.

Limits

• No server is perfectly secure. These steps stop the common automated attacks, not a skilled attacker with time and a reason to target you.
• It is your job. A RackNerd VPS is unmanaged. Nobody else patches it for you.
• Rules still apply. RackNerd's acceptable use policy covers anything your server does, even if an attacker made it do it. Act quickly on any abuse notice.
• Some security tools cost memory. On very small plans, keep to the light essentials in this guide rather than heavy scanners. Swap is a safety net, not extra RAM.
• Data rules may apply. If you store other people's personal or payment data, there may be legal duties beyond this guide.

When to step up

Security is easier when each server does one job. If your server runs a website, a VPN, a database and experiments all at once, one weak app can put everything at risk. Splitting important jobs onto separate small servers keeps problems apart, and a second small VPS makes a good off-site backup target.

If you do not have time to keep a server updated, shared hosting, where the provider maintains the server, can be the safer choice for a simple website. See shared hosting or a VPS.

To compare what is available now, start with the cheapest RackNerd VPS guide and check the sales page.