How to protect a server (VPS/VDS) from unauthorised access

Let's get started with protection

Protecting a server – not “setting up a thousand rules”, but closing the most common holes: weak passwords, open ports and outdated software. Most hacks happen exactly this way – a bot scans the internet, finds open SSH/RDP, brute-forces passwords or logs in with leaked credentials, after which it gains a foothold (adds keys, users, jobs) and starts using the server for its own purposes.

Below – practical measures that give the maximum effect with minimal complexity.

Where to start: access to the server and credentials

The first thing you need to do – protect access to the control panel and to the server itself. If two-factor authentication is available in the panel, enable it. The panel password should be unique and long, and it is best kept in a password manager.

On the server, the key goal – to make “password guessing” useless. For Linux, this means switching to SSH keys and disabling password login. For Windows – using a strong administrator password and restricting RDP so that it is not accessible “to everyone on the internet”.

Passwords: what length and format are considered the norm

For the panel, root/Administrator, databases and any admin panels, we recommend:

• at least 16 characters, preferably 20–24+
• the preferred format – a long passphrase (4–6 random words + separators), or a completely random string from a password manager
• a unique password for each service (do not use the same one)
• if a service requires “complexity” (letters/digits/symbols) – add 1–2 characters, but do not reduce the length

Example of a secure phrase: Kr0na$7&7@Riv@e#r (an example, do not use it literally).

How to set up SSH properly on Linux (without overcomplicating things)

The most reliable basic setup is this: you create a separate user, log in with an SSH key and perform administrative actions via sudo. You do not use direct root login, and you disable password login. Then, even if someone keeps “knocking” on SSH around the clock, they will run up against the complete absence of passwords.

In addition, it makes sense to restrict SSH access to your IP (for example, your home IP or office IP) or to connect to the server only through your VPN. This is a simple measure that sharply reduces noise in the logs and the risk of attacks.

1) Create a user and give them sudo

adduser admin
usermod -aG sudo admin

2) Generate an SSH key on your PC (ed25519 is recommended)

ssh-keygen -t ed25519 -a 64

3) Copy the key to your server

ssh-copy-id admin@SERVER_IP

4) Disable password login and prohibit root login

Open the SSH config:

sudo nano /etc/ssh/sshd_config

Make sure the following is set:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Restart SSH:

sudo systemctl restart ssh

Important: before disabling the password, be sure to check that key login works in a second session (just start another connection to the server in a different terminal or a new termius).

Close unnecessary ports: why a firewall matters more than “smart” settings

The second most important thing after keys – a firewall. The logic is simple: only the services that are actually used should face the outside. If you have a website – 80/443 is enough. If only a VPN – only the VPN port. If you do not serve anything externally – close everything except administrator access (SSH/RDP), and even that preferably by IP.

This is not about “paranoia” – it is about reducing the attack surface. The fewer ports stick out to the internet, the lower the chance that you will be hit by a vulnerability exploit at all.

Option A – UFW (Ubuntu/Debian)

Install and enable:

sudo apt update
sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing

Open SSH only from your IP (recommended):

sudo ufw allow from YOUR_IP_HERE to any port 22 proto tcp

If you need a website:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Enable:

sudo ufw enable
sudo ufw status verbose

Option B – firewalld (AlmaLinux/Rocky/CentOS Stream)

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld

Open SSH only from your IP:

sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="YOUR_IP_HERE" port port="22" protocol="tcp" accept'
sudo firewall-cmd --reload

Open web (if needed):

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Security updates: why they are critical

Even perfectly configured access will not save you if the server runs old software with known vulnerabilities. That is why the server should receive security updates regularly. The minimum – updates to the OS and critical packages. If you use control panels, CMS or web applications, they must be updated too, otherwise the risk of a hack grows many times over.

Protection against brute force and “noise” in the logs

Even with key-based login, it is useful to enable brute-force protection (for example, fail2ban or an equivalent). It is not “magic armour”, but good hygiene: it automatically blocks IPs that try to force their way into SSH/RDP/web authentication. As a result, there is less junk in the logs, fewer attempts to guess anything, and it is easier to spot a real problem.

Ubuntu/Debian

sudo apt update
sudo apt install -y fail2ban

Create a local config:

sudo nano /etc/fail2ban/jail.local

Minimal example:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime  = 1h

Start:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Backups: what to do if access is lost after all

Backups – insurance for when everything else has failed. It is important that the copies are not stored on the same server (otherwise an attacker can delete them along with everything else). Normal practice – to keep backups separately and test restoring them from time to time, otherwise at a critical moment it may turn out that “the backup is there, but it does not work”.

Minimal summary: what gives the maximum effect

If you do only three things, choose these: key-based login and disabling passwords (or strict RDP protection), closing unnecessary ports with a firewall, and regular security updates. This is the foundation that blocks the largest share of real attacks.