how to harden a Linux server: first 10 steps

how to harden a Linux server: first 10 steps

TL;DR

Do these ten in order on every fresh server before it serves traffic: update everything, lock SSH to keys, firewall it, add fail2ban, remove unneeded services, enable unattended upgrades, clean up users, tighten file permissions, set up backups, and ship logs somewhere central. Written for Ubuntu 22.04/24.04 and Debian 12; about 30 minutes total.

how to harden a Linux server: first 10 steps

Use this when

• You just spun up a VPS or VM and it is still on defaults
• You are writing the standard build for new servers
• A scanner flagged a fresh box
• You inherited a server and want a baseline pass

Not for this skill when

• You need CIS benchmark compliance (this is the quick version, not the audit version)
• It is a container host or Kubernetes node (some steps differ)
• The server is already in production (do these in a maintenance window, not live)

Steps

1. Update everything

sudo apt update && sudo apt upgrade -y

Expected: no packages left to upgrade on a second run. Reboot if the kernel updated.

2. Lock SSH to key-only, disable root login

sudo sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl reload sshd

Expected: sudo sshd -T | grep -E "passwordauthentication|permitrootlogin" shows no for both. Test a new SSH session before closing your current one.

3. Enable the firewall, deny by default

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable

Expected: sudo ufw status shows active with only SSH allowed. Add your app ports as needed, nothing else.

4. Install fail2ban

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Expected: the sshd jail shows as active. Brute-force attempts now get temp-banned instead of trying forever.

5. Remove unneeded services

sudo ss -tlnp | awk '{print $7}' | sort -u

Expected: a short list of listeners you recognize. Remove or disable anything you do not need; every listener is attack surface.

6. Enable unattended security upgrades

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Expected: the config prompt confirms it is enabled. Security patches now apply themselves; check the unattended-upgrades log after a few days.

7. Audit users and sudoers

sudo awk -F: '$3 >= 1000 {print $1}' /etc/passwd
sudo grep -v "^#" /etc/sudoers | grep -v "^$"

Expected: only accounts you recognize, and sudoers contains only intentional entries. Remove stale users with sudo deluser [old username].

8. Tighten key file permissions

ls -l ~/.ssh/

Expected: .ssh is 700, authorized_keys is 600, private keys are 600. Fix with chmod if not; SSH ignores keys with loose permissions anyway, which breaks logins in confusing ways.

9. Set up backups before you need them

sudo apt install -y restic
echo "init a restic repo on offsite storage, add a daily cron job, test a restore monthly"

Expected: a backup job exists and you have done one test restore. Backups you never tested are just hopes.

10. Ship logs off the box

echo "forward auth and syslog to your central log server over TLS (rsyslog forwarding)"

Expected: login attempts appear in your central logs within a minute. An attacker who owns the box can wipe local logs; they cannot wipe the copy.

Why this happens

Default installs optimize for "it works immediately", which means open services, password auth, and no firewall. Most compromises of small servers are automated scans finding exactly these defaults, not targeted attacks. The ten steps do not make you invincible, they just stop you being the easy target.

Edge cases and pitfalls

• Doing step 2 wrong locks you out; always test a fresh SSH session before closing the old one.
• Allow OpenSSH in ufw before enabling it, or the firewall cuts your session.
• Unattended upgrades can restart services; for critical boxes, schedule them in a window.
• fail2ban with the wrong timezone or log path silently does nothing; check fail2ban-client status after install.
• Backups of a database need the DB's own dump tool too; filesystem copies of a live database can be corrupt.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zmITMDvqfgM7ZraEmxytXg

Resolved from the public thread: https://vectle.com/posts/pst_zmITMDvqfgM7ZraEmxytXg

Thread query: how to harden a Linux server: first 10 steps

TL;DR: Do these ten in order on every fresh server before it serves traffic: update everything, lock SSH to keys, firewall it, add fail2ban, remove unneeded services, enable unattended upgrades, clean up users, tighten file permissions, set up backups, and ship logs somewhere central. Written for Ubuntu 22.04/24.04 and Debian 12; about 30 minutes total.