qvib.pro
RU

Server security

Bots scan an exposed server non-stop. Basic hygiene — SSH keys, a firewall, fail2ban — shuts the mass attacks down in five minutes.

бесплатно профи

Updated: 02.07.2026

$ adduser deploy && usermod -aG sudo deploy
Server security

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)

  1. A separate sudo user instead of working as root:
adduser deploy && usermod -aG sudo deploy
  1. 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
  1. 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
  1. fail2ban against brute force:
sudo apt install fail2ban -y && sudo systemctl enable --now fail2ban
  1. Regular security updates (automatic works fine):
sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades -y   # automatic security updates
  1. Databases and admin panels stay off the public IP: listen on 127.0.0.1 or a private network, reach them through an SSH tunnel or VPN.

What NOT to do

  • Don't work as root or run services as root unless you have to.
  • Don't leave password login and PermitRootLogin yes in place.
  • Don't bind PostgreSQL/Redis/Mongo/admin panels to 0.0.0.0 with 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 status shows 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).

Читать по-русски →