The first 30 minutes decide whether your root server is a secure system or an open target: install updates, switch SSH to keys, create your own user, enable the firewall, install Fail2ban and set up automatic backups. All of it together takes less than half an hour.
Why the first minutes count
A freshly installed server is found by automated scanners within minutes. They try default passwords, known vulnerabilities and open ports, around the clock. Not because someone means you personally, but because every IP address on the internet gets probed. The following steps close the doors these scanners look for.
Step 1: install updates
Before anything else, bring the system up to date. On Debian and Ubuntu these are two commands: "apt update" and "apt upgrade". Then enable automatic security updates, on Debian and Ubuntu with the "unattended-upgrades" package. From then on the system closes critical vulnerabilities without you having to remember.
Step 2: switch SSH to keys
Passwords are the main entry point. Generate a key pair on your computer, copy the public key to the server and disable password login in the SSH configuration. Before that, create your own user with sudo rights and forbid direct login as root.
- "ssh-keygen -t ed25519" generates a modern, short key.
- "ssh-copy-id user@server" installs the public key.
- In /etc/ssh/sshd_config: PasswordAuthentication no and PermitRootLogin no.
- First test that key login works, then close the old session.
Step 3: firewall and Fail2ban
Only allow the ports your server really needs. With "ufw" this is done in a few commands on Ubuntu and Debian: allow SSH, HTTP and HTTPS, block everything else incoming. Fail2ban then automatically bans IP addresses that repeatedly fail to log in for a while.
| Service | Port | Allow? |
|---|---|---|
| SSH | 22 (or a custom port) | Yes, ideally only for your IP |
| HTTP / HTTPS | 80 / 443 | Only if a web server runs |
| Database | 3306 / 5432 | No, keep it local only |
| Game server / TeamSpeak | Depends on the application | Only the documented ports |
Step 4: backups before you need them
A backup that sits on the same server is not a backup. Regularly back up configuration, databases and user data to a second system, such as FameSystems cloud storage, and check once whether the backup can actually be restored. A cron job with rsync or restic is enough to start with.
The checklist to tick off
- System updated, automatic security updates active
- Own user with sudo, root login via SSH disabled
- SSH with keys only, password login off
- Firewall active, only required ports open
- Fail2ban installed and enabled for SSH
- Backup to a second system set up and tested once
Root server with AMD EPYC and NVMe
Dedicated resources, free choice of operating system, ready in minutes. Cloud storage as a backup target is bookable in the same customer area.