5 Simple Steps to Secure Your VPS
A VPS offers complete freedom. You have full control over your server and are free to install any services and configure the infrastructure to suit your needs. But with this freedom comes great responsibility, since no one but you is responsible for your server’s security.
And the problem is that the vast majority of cyberattacks aren’t sophisticated hacking operations, but rather mundane scans and automated bots that search for open ports, check hosts for weak passwords, and look for missed updates. And if your server is “glowing” on the network like a Christmas tree, sooner or later someone will try to break into it. And most likely, it will happen pretty quickly. Someday, just for fun, monitor your server logs in real time, and you’ll be surprised at how quickly and intensely various scripts from the internet start probing it.
There is some good news, though: you don’t need to build a complex system out of dozens of tools for basic server protection. Just a few simple steps are enough to cover about 80% of all risks related to your server being compromised.
Let’s take a closer look at them.
1. Close all unnecessary ports
The first rule of security is: Never leave open what should not be accessible.
It often happens that administrators set up a VPS, install Nginx, PostgreSQL, Redis, and Docker on it, and forget to check what’s exposed to the outside. As a result, the database is listening on an external interface, Redis is accessible without a password, and the Docker API is wide open.
Unfortunately, this is not at all uncommon; it’s more the norm among beginners—and not just beginners, since even an experienced administrator can simply overlook one service or another.
Therefore, if your server, for example, acts as a web server for your site, the first thing you need to do is: These steps should be, as they say, “second nature” to every administrator. The first thing you do on a new server is install any firewall and configure it, leaving only what you’ll need for immediate operations and closing everything else. This is just the first step, but it can already significantly reduce the risk of being hacked. You can think of it as an analogy to the front door of your house: if you leave it open, anyone who feels like it will walk right in, just out of curiosity. But if you close it, then no one will take an interest in your home except actual intruders.
Leave only the necessary ports open, usually 22, 80, and 443;
Close ALL other ports using a firewall;
Make sure that internal services listen on the internal address 127.0.0.1, and do not expose themselves to the outside world as 0.0.0.0.
2. SSH access via key only
Accessing your server via SSH using a password is another “red flag,” as they say these days. After all, even the simplest script can brute-force hundreds or thousands of username and password combinations in a short amount of time, which will eventually lead to the server being compromised. Especially if the password isn’t strong enough.
So if you’re still using a password, you need to fix this immediately. Of course, don’t forget to upload your key to the server first so you don’t lock yourself out. Then open the /etc/sshd_config file and make sure it contains the following:Port 53522PermitRootLogin noPubkeyAuthentication yesPasswordAuthentication no
As you can see, we also recommend changing the port number to a non-standard one, which will significantly reduce the number of login attempts, since most scanners target the standard port 22.
After that, even if a bot finds your server, it will hit a wall, since it will be impossible to access the server without the private key.
3. Installing Updates
For some reason, many people view updates as optional tasks, thinking, “I’ll update when I have time.” But this is a critical mistake.
The fact is that vulnerabilities—both in the OS itself and in popular services like Nginx, PHP, OpenSSL, and other components—are discovered with alarming regularity. Therefore, as soon as information about a particular vulnerability becomes public and a CVE is released, exploits appear within a couple of hours, and within a day, mass scanning of hosts on the internet for that very vulnerability begins.
Therefore, if your server is not updated, it is highly likely to become an easy target for an attack.
Given this, it is very important to regularly update the system (apt update && apt upgrade), monitor the status of critical packages, and enable automatic security updates if necessary.
4. Protection with Fail2ban
Even if you use SSH keys, bots will still try to connect to your server. This creates unnecessary load on the server and clogs up the system logs.
But to solve this (and other) problems, there is an old but well-proven tool: Fail2ban. It analyzes various logs and uses the system firewall to block, either temporarily or permanently, IP addresses that behave suspiciously—for example, by making dozens of failed login attempts. Fail2ban has a vast number of use cases, but in our opinion, the minimum configuration should include: However, it’s important to understand one thing: if your server is behind a CDN (such as Cloudflare), standard blocking at the iptables level isn’t always effective. In such cases, blocking should be moved to the WAF or provider API level as we wrote about in one of our blog posts.
SSH protection
web authorization protection (e.g., WordPress or admin panels)
reasonable values for maxretry, findtime, bantime, which are selected individually and can be adjusted later
But even in its basic configuration, Fail2ban significantly reduces “noise” and blocks primitive attacks.
5. The Principle of Least Privilege
One of the most common and dangerous habits is doing everything as root. Of course, it’s faster, easier, and you don’t have to think about permissions. But this is precisely what most often plays a cruel trick.
The problem is that root grants full access to everything, so if someone gains access to such an account, they don’t just log in to the server—they effectively become the server itself. No restrictions, no barriers, right up to completely wiping the disk, along with the entire system.
It’s much safer when there are boundaries: a regular user for day-to-day work, sudo—only when it’s truly necessary—and services that have exactly the privileges they need, and no more.
In this case, even if an application were compromised and an attacker gained certain privileges, those privileges would not extend to the rest of the system, preventing the hacker from escalating privileges and keeping them “trapped” within the application.
Conclusions
So, we’ve established that your server’s security can and should be ensured without complex schemes or paid services. It’s enough to understand basic security principles and have a bit of discipline to protect yourself from most online threats.
Most hacks occur not because someone used a unique technique, but because the server was configured with “default” settings, leaving open ports, weak configurations, and a complete lack of updates.
Therefore, if you close obvious vulnerabilities, your server will no longer be an easy target, and that’s already half the battle. After all, it’s easier for a hacker to keep scanning and find an easy target than to try to hack your server, especially if you don’t represent some large corporation but have simply set up your blog online.
