Server hardening: a complete checklist

01The mindset: layers and least privilege

Hardening follows two principles. Defence in depth: assume any single layer can fail, so stack several (edge WAF, firewall, SSH policy, app permissions, backups). Least privilege: every user, process and key gets only the access it needs, so a compromise stays small. Work in a safe order, because the classic hardening accident is locking yourself out. Create your own user and key first, confirm you can log in with it in a second terminal, and only then disable root and passwords. Allow SSH in the firewall before enabling it. Keep the provider's web console as an emergency door. Write each step into a short runbook or script, so the next server gets exactly the same treatment and you can prove to a client what was done.

• Reduce attack surface: fewer open ports, services and packages.
• Limit blast radius: separate users, private networks, scoped credentials.
• Assume breach: backups off-site, logs and alerts you will actually read.

021. Users and SSH: keys only, no root

Create a personal admin user with sudo and install your public key (an Ed25519 key is the modern default). Then disable root login and password authentication with a drop-in file in /etc/ssh/sshd_config.d/, which survives package updates better than editing the main file. On Ubuntu the service is called ssh. Validate the config with sshd -t before reloading, and keep your current session open while you test a new login in another terminal. Changing the SSH port only reduces log noise; it is not a security control, so do it only if you want quieter logs. For teams, give each person their own user and key so access can be revoked individually, and remove keys of people who leave.

1# On the server, as root (one time)
2adduser your_user
3usermod -aG sudo your_user
4# From your laptop
5ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
6 
7# /etc/ssh/sshd_config.d/99-hardening.conf
8PermitRootLogin no
9PasswordAuthentication no
10KbdInteractiveAuthentication no
11PubkeyAuthentication yes
12MaxAuthTries 3
13AllowUsers your_user
14 
15# Validate, then reload (keep the current session open!)
16sudo sshd -t && sudo systemctl reload ssh

032. Firewall, updates and fail2ban

Deny all incoming traffic by default and open only what the server serves: SSH, HTTP and HTTPS. Mirror the same rules in your cloud provider's firewall, so traffic is filtered before it even reaches the machine. One important trap: Docker publishes container ports by writing its own iptables rules, which bypass ufw. Bind published ports to 127.0.0.1 in Compose files unless they truly must be public. Next, enable unattended-upgrades for security patches; most kernel updates still need a reboot, so schedule a maintenance window or allow automatic reboots at a quiet hour. Install fail2ban to ban brute-force sources. Finally, remove services you do not use: every listening daemon is one more thing to patch.

1sudo ufw default deny incoming
2sudo ufw default allow outgoing
3sudo ufw allow OpenSSH
4sudo ufw allow 80/tcp
5sudo ufw allow 443/tcp
6sudo ufw enable
7sudo ufw status verbose
8 
9sudo apt update && sudo apt install -y unattended-upgrades fail2ban
10sudo dpkg-reconfigure -plow unattended-upgrades
11# Optional: /etc/apt/apt.conf.d/50unattended-upgrades
12#   Unattended-Upgrade::Automatic-Reboot "true";
13#   Unattended-Upgrade::Automatic-Reboot-Time "04:00";
14 
15sudo ss -tulpn   # everything listening; nothing unexpected on 0.0.0.0

043. Apps: separate users, permissions, private databases, secrets

Run each site or app as its own system user with its own PHP-FPM pool or process manager entry. If one app is compromised, it cannot read another app's code, uploads or environment file. Code should be owned by the deploy user and not writable by the web process; only folders that must change at runtime (Laravel's storage and bootstrap/cache, upload folders) are writable. Environment files are readable only by the app user. Databases and Redis listen on localhost or a private network and every app has its own least-privilege database user. Secrets live in environment files on the server or in a secrets manager, never in Git, and are rotated when someone leaves or a leak is suspected. Run a secret scanner on the repository, because leaked keys in old commits are a common source of breaches.

1# One system user per app, no login shell
2sudo adduser --system --group --home /var/www/shop --shell /usr/sbin/nologin shop
3 
4# Code: owned by the deploy user, readable by the app group
5sudo chown -R deploy:shop /var/www/shop
6sudo find /var/www/shop -type d -exec chmod 750 {} +
7sudo find /var/www/shop -type f -exec chmod 640 {} +
8 
9# Only runtime folders are writable by the app
10sudo chmod -R 770 /var/www/shop/storage /var/www/shop/bootstrap/cache
11 
12# Secrets: readable by the app only
13sudo chown deploy:shop /var/www/shop/.env && sudo chmod 640 /var/www/shop/.env

054. HTTPS everywhere and a WAF in front

Every site gets a certificate, usually from Let's Encrypt through certbot, with automatic renewal (certbot installs a systemd timer; check it with a dry run). Redirect HTTP to HTTPS, use TLS 1.2 and 1.3 only, and add HSTS once you are sure every subdomain works over HTTPS. Putting Cloudflare or a similar CDN/WAF in front hides the origin IP, absorbs basic DDoS traffic, and lets you block bad bots and apply rate limits at the edge. Use the SSL mode Full (strict), so the connection from Cloudflare to your server is encrypted and the certificate is validated; Flexible sends traffic unencrypted to the origin. For extra protection, allow 80 and 443 only from Cloudflare's IP ranges or use a tunnel, so attackers cannot bypass the edge by hitting the origin IP directly.

1sudo apt install -y certbot python3-certbot-nginx
2sudo certbot --nginx -d example.com -d www.example.com
3sudo certbot renew --dry-run
4systemctl list-timers | grep certbot
5 
6# nginx: modern TLS and HSTS (add HSTS only when all subdomains use HTTPS)
7ssl_protocols TLSv1.2 TLSv1.3;
8add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
9add_header X-Content-Type-Options "nosniff" always;
10add_header Referrer-Policy "strict-origin-when-cross-origin" always;
11server_tokens off;

065. Backups, monitoring and audits

Hardening also means surviving what you could not prevent. Take provider snapshots and, separately, application-level backups of databases and uploads copied to another account or provider. Test restores on a schedule; an untested backup is a hope, not a plan. Monitor what usually kills small servers: full disks, memory exhaustion, expired certificates and a site that is down. An external uptime checker (Uptime Kuma or the provider's alerts) plus disk and load alerts covers most of it. Keep logs long enough to investigate an incident. Then audit: Lynis scans the system and lists concrete hardening suggestions with a score, which is a good way to catch what a checklist missed. Re-run it after changes and keep the report.

1# Audit the system and read the suggestions
2sudo apt install -y lynis
3sudo lynis audit system
4sudo less /var/log/lynis-report.dat
5 
6# Quick health checks
7df -h                          # disk usage
8free -h                        # memory
9sudo last -n 20                # recent logins
10sudo journalctl -p err -b      # errors since boot
11sudo fail2ban-client status sshd

07SSH internals on modern Ubuntu: socket activation and crypto

Since Ubuntu 24.04, SSH uses systemd socket activation: ssh.socket listens on the port and starts ssh.service on the first connection. A systemd generator reads Port and ListenAddress from sshd_config to build the socket, so changing the port means daemon-reload plus a restart of ssh.socket, not just reloading the service. Many people have locked themselves out by changing Port, reloading ssh, and closing the session while the socket still listened on 22 and the firewall only allowed the new port. On cryptography, current OpenSSH defaults are good: recent releases negotiate a hybrid post-quantum key exchange automatically, and Ed25519 keys are the standard. Do not paste old cipher lists from blog posts; they often weaken modern defaults. sshd -T prints the effective configuration after all drop-ins, and the ssh-audit tool reports weak algorithms. For the highest assurance, use hardware-backed keys (ed25519-sk) on a security key, so a stolen laptop file is useless.

1# /etc/ssh/sshd_config.d/99-hardening.conf
2Port 2222
3 
4# Open the new port first, then rebuild the socket
5sudo ufw allow 2222/tcp
6sudo sshd -t
7sudo systemctl daemon-reload
8sudo systemctl restart ssh.socket
9sudo ss -tlnp | grep -E ':22 |:2222 '
10 
11# Effective settings after all drop-ins
12sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|port'

08Sandboxing services with systemd

A separate Unix user limits which files a compromised app can read, but the process can still see most of the filesystem, write to /tmp, load arbitrary binaries and open any network socket. systemd can confine each service much further with a few lines in a drop-in: a read-only view of the operating system, no access to home directories, a private /tmp, no privilege escalation through setuid binaries, and only the address families it needs. systemd-analyze security scores every unit from 0 (well protected) to 10 (exposed) and lists which options are missing, which makes this measurable. Apply options gradually and test, because an over-tight sandbox shows up as permission errors at runtime. MemoryMax and CPUQuota also stop one runaway process from taking the whole server down. The same ideas exist for containers: run as non-root, read-only root filesystem, dropped capabilities.

1# /etc/systemd/system/web.service.d/hardening.conf
2[Service]
3User=web
4NoNewPrivileges=yes
5ProtectSystem=strict
6ProtectHome=yes
7PrivateTmp=yes
8PrivateDevices=yes
9ReadWritePaths=/var/www/web/shared
10ProtectKernelTunables=yes
11ProtectKernelModules=yes
12ProtectControlGroups=yes
13RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
14CapabilityBoundingSet=
15MemoryMax=1G
16# Then: sudo systemctl daemon-reload && systemd-analyze security web.service

09Kernel and network settings

sysctl settings tune the kernel's behaviour. Ubuntu already ships sensible defaults in /etc/sysctl.d/10-*.conf: SYN cookies, protected symlinks and hardlinks, restricted kernel pointers, and AppArmor restrictions on unprivileged user namespaces since 24.04. A small extra file hardens the network stack further: ignore ICMP redirects and source-routed packets that could reroute traffic, do not send redirects since the server is not a router, and log packets with impossible source addresses. Two cautions. Docker, Kubernetes and VPN servers need net.ipv4.ip_forward = 1, so never disable forwarding blindly on such hosts. And strict reverse-path filtering (rp_filter = 1) can break servers with several interfaces and asymmetric routing; Ubuntu defaults to loose mode (2) for that reason. Apply with sysctl --system and verify that networking and containers still work before rolling out.

1# /etc/sysctl.d/99-hardening.conf
2net.ipv4.conf.all.accept_redirects = 0
3net.ipv6.conf.all.accept_redirects = 0
4net.ipv4.conf.all.send_redirects = 0
5net.ipv4.conf.all.accept_source_route = 0
6net.ipv6.conf.all.accept_source_route = 0
7net.ipv4.conf.all.log_martians = 1
8net.ipv4.tcp_syncookies = 1
9kernel.dmesg_restrict = 1
10kernel.kptr_restrict = 2
11 
12# Apply and check one value
13sudo sysctl --system
14sysctl net.ipv4.conf.all.accept_redirects

10Detection: knowing when a layer failed

Prevention eventually fails, so plan to notice. Ship logs off the server (journald forwarding, Loki, or a hosted service), because an attacker with root edits local logs first. auditd records security-relevant events such as changes to /etc/passwd, sudoers or SSH keys. A file integrity checker such as AIDE builds a database of hashes for system files and reports changes; run it from a timer and keep the baseline database off the host. Patching has a detection side too. unattended-upgrades installs fixes, but running processes keep old libraries in memory until restarted: needrestart lists them, and /var/run/reboot-required tells you a new kernel waits for a reboot. Ubuntu Pro, free for a small number of personal machines, adds Livepatch for kernel fixes without reboots and the Ubuntu Security Guide for automated CIS or DISA-STIG profiles. Alert on new sudo users, new authorized_keys entries and unexpected listening ports.

1# Watch changes to identity and SSH files
2sudo apt install -y auditd
3sudo auditctl -w /etc/passwd -p wa -k identity
4sudo auditctl -w /etc/sudoers.d -p wa -k sudoers
5sudo auditctl -w /home/your_user/.ssh/authorized_keys -p wa -k sshkeys
6sudo ausearch -k sshkeys --start today
7 
8# Services still running old libraries, and pending reboot
9sudo needrestart -r l
10[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs