Server security: the basic steps to take on day one

A new server starts receiving automated scanning traffic the moment it is set up. This guide gives, in order, the steps that close most of the attack surface when they are done on the first day — none of them is complicated, and all of them get skipped.

1. Use SSH with a key and turn the password off

This is the single highest-return step. An open port 22 with password login means a door that is being tried continuously. Moving to a key makes all of that traffic useless.

The steps, and how to apply them without losing access: connecting to a server over SSH

2. Open only the ports you need

The default approach should be "close everything, open what is needed":

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 30120        # your game port
ufw enable

A critical warning if you use Docker: because the ports Docker publishes are routed through nat/PREROUTING, they bypass the host INPUT rules. So ufw enable on its own does not close a Docker port; you have to write a rule in the DOCKER-USER chain. This is one of the most common reasons for believing you are safe when you are not.

3. Do NOT open the database port to the outside

MySQL (3306), MSSQL (1433), PostgreSQL (5432) and Redis (6379) should accept local connections only. An open database port means all of your data is exposed.

In MySQL:

bind-address = 127.0.0.1

If your application is on another server, use a private network; do not open the port to the internet.

4. Restrict management panels

txAdmin (40120), RCON (28016), Plesk, phpMyAdmin — all of these are full control of your server. A management panel left open to everyone is an unnecessary risk no matter how strong the password is. Allow only your own IP address.

5. Apply updates

apt update && apt upgrade

Installing automatic security updates (unattended-upgrades) is better than a known vulnerability left open for months. But kernel updates require a restart; on a game server, do that in a planned window.

6. A separate user — do not run as root

Running the game server as root is common and unnecessary. If there is a vulnerability in the application, running as root means the whole machine is taken over, while running as a separate user means only that directory is affected:

adduser --disabled-password --gecos "" fivem

7. Install Fail2ban

It temporarily blocks IP addresses that keep failing login attempts. If you use keys it becomes unnecessary for SSH, but it is still useful for other services (a web panel, FTP).

8. Backups — the last link in security

Ransomware and accidental deletion are two scenarios a firewall cannot solve. A remote backup whose restore has been tested is the only thing you have in those two cases: server backup strategy

Checklist

Verify these one by one after the installation:

ss -tulpn                  # which ports are listening
ufw status verbose         # firewall rules
iptables -S DOCKER-USER    # if Docker is present
last -n 20                 # recent logins

In the ss -tulpn output, every service listening on 0.0.0.0 that should not be exposed is a finding.

DDoS is a separate subject

The steps above are against unauthorised access. Volumetric attacks cannot be solved inside the server; filtering at the network layer is required: what is DDoS protection?