A fresh VPS is exposed to the internet from the second it boots, and automated bots start probing it within minutes. Here is a practical, day-one Linux VPS security checklist that closes the doors attackers actually use - no deep Linux expertise required.
Quick answer
To secure a new Linux VPS, install all updates, create a non-root user with sudo, switch SSH to key-based login and disable password and root logins, enable a firewall that allows only the ports you use, add fail2ban, turn on automatic security updates and set up off-site backups.
1. Update everything first
Before anything else, apply all available updates. A freshly-provisioned image is often weeks or months old and may already be missing security patches. Then enable automatic security updates so you are not relying on memory.
2. Create a non-root user
Never do day-to-day work as root. Create a normal user, give it sudo for when you need elevation, and use that. If something goes wrong or an account is phished, you have not handed over the whole machine. (If sudo is not set up yet, see user not in sudoers.)
3. Lock down SSH
SSH is the front door, and brute-force bots hammer it constantly. The essentials: use key-based login, disable password auth, disable direct root login, and add brute-force protection. This matters enough to have its own guide - how to harden SSH. If you lose access while tightening things, SSH permission denied (publickey) covers the most common cause.
4. Turn on a firewall
Default-deny is the goal: block everything, then allow only the ports you actually use (SSH and your game or app ports). A simple firewall (ufw or firewalld) takes minutes and instantly shrinks your attack surface - see how to set up a firewall with ufw. If you cannot reach a service afterwards, you probably have not opened its port; port already in use / bind failed covers a related but different problem.
5. Run only what you need
Every running service is another potential way in. List what is listening on the network and switch off anything you are not using - old databases, test servers, default web apps. The smaller the surface, the fewer vulnerabilities can ever apply to you.
6. Add brute-force protection
Tools like fail2ban watch your logs and automatically ban IPs that fail to log in too many times - see how to install and use fail2ban. It will not stop a determined targeted attacker, but it makes your server invisible to the constant background noise of credential-guessing bots.
7. Apply least privilege
Give every user, service and database account the minimum rights it needs - no more. If one is ever compromised, least privilege is what stops a small breach becoming a total one. It applies to file permissions, database users and app accounts alike - permission denied on Linux is a good sign your permissions are at least being enforced.
8. Back up off the server
Security is not only about keeping attackers out - it is about recovering fast when something goes wrong. Keep automated backups, store at least one copy off the server, and test a restore occasionally. A good backup is what turns a compromise from a disaster into an afternoon.
9. Watch resource usage, not just security logs
A quiet compromise often shows up first as unexplained CPU, RAM or disk activity rather than a login alert. Get comfortable with checking CPU, RAM and disk usage on Linux so an unfamiliar spike - a crypto-miner, a runaway process, a filling disk - catches your eye early. It also saves you from unrelated but common headaches like no space left on device or the OOM killer.
You do not need to be a security expert - doing the basics above puts you ahead of the overwhelming majority of servers that get breached.
The quick checklist
- Fully updated, with automatic security updates on.
- A non-root sudo user for daily work.
- Key-only SSH, no root login, brute-force protection.
- A default-deny firewall, only needed ports open.
- Only the services you actually use, running.
- Least privilege for users, services and databases.
- Automated, tested, off-server backups.
- A habit of checking CPU/RAM/disk usage for anomalies.
Do these once on day one and revisit them whenever you add something new. For the game-server-specific layer on top, see our game server security checklist.