Why this matters
Any public VPS gets brute-forced and scanned 24/7, starting minutes after you spin it up. Default settings, password login and working as root turn a single hole into a full takeover: miners, spam, botnets, data theft and deleted backups.
Real-world scenario. A server goes up with SSH on port 22, password login, root account. Overnight the bots guess the weak password, log in as root, install a miner and wipe the logs. CPU pinned, the server blacklisted, recovery from scratch. Five minutes of basic setup would have prevented it.
What to do (step by step)
- A separate sudo user instead of working as root:
adduser deploy && usermod -aG sudo deploy
- SSH key login, passwords disabled:
ssh-copy-id deploy@SERVER # upload your key first
# in /etc/ssh/sshd_config:
# PasswordAuthentication no
# PermitRootLogin no
sudo systemctl restart ssh
- Firewall: close everything, open only what's needed:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH # 22
sudo ufw allow 80,443/tcp # web
sudo ufw enable
- fail2ban against brute force:
sudo apt install fail2ban -y && sudo systemctl enable --now fail2ban
- Regular security updates (automatic works fine):
sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades -y # automatic security updates
- Databases and admin panels stay off the public IP: listen on
127.0.0.1or a private network, reach them through an SSH tunnel or VPN.
What NOT to do
- Don't work as
rootor run services as root unless you have to. - Don't leave password login and
PermitRootLogin yesin place. - Don't bind PostgreSQL/Redis/Mongo/admin panels to
0.0.0.0with no firewall. - Don't skip updates — an unpatched service gets broken into via a known CVE.
- Don't open ports "just in case" — every open port is attack surface.
Self-check
-
sudo ufw statusshows only the ports I need; everything else is denied. - Password login and root SSH login are disabled; I log in with a key.
- I work as a separate sudo user, not as root.
- fail2ban is running; automatic security updates are on.
- Databases, Redis and admin panels aren't exposed on the public IP (checked with
ss -tlnp).
Tools
- Firewall: ufw, firewalld, nftables.
- Brute-force protection: fail2ban, CrowdSec.
- SSH and access: ed25519 keys, Tailscale/WireGuard for private access to admin panels and databases.
- Auditing: Lynis (hardening scan), ss/nmap to check open ports.
- Automatic updates: unattended-upgrades (Debian/Ubuntu), dnf-automatic (RHEL).