Linux Server Hardening: The 20% That Stops 80% of Attacks
Effective Linux hardening isn't a security checklist that makes the machine unusable. It's SSH config, patching, least privilege, and logging.
Most Linux server compromise stories read the same: default SSH credentials, an open firewall, an unpinned package, and a year of no patches. Here is the hardening that stops the common paths — in order of impact.
1. Lock down SSH
SSH is the front door, and attackers know it.
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers deploy admin
MaxAuthTries 3
LoginGraceTime 30
Disable root login before you remove password auth, or you can lock yourself out. Generate a key locally, ssh-copy-id, verify it, then disable passwords. Add UseDNS no and a non-standard but not-obscure port if you want quieter logs.
2. Patch. Promptly. Automatically.
Unpatched software is the #1 root cause in breach reports. On Ubuntu, unattended-upgrades for security classes, with a daily check and notification. On enterprise hosts, feed your vulnerability scanner into a ticketing queue.
apt-get update && apt-get upgrade -y
apt autoremove -y
A server that can't be patched is a server you don't own.
3. Least privilege everywhere
- Root only via
sudo, with a separate admin group, andsudofailures logged. - Services run as their own users, not
nobody, not root. - Database and app users get the minimum grants. Service accounts rotate.
chmodaggressively on config files containing secrets;chmod 600on SSH keys.
useradd -r -m -s /usr/sbin/nologin website
chown -R website:website /srv/website
4. The firewall that's actually enabled
Install ufw, set defaults to deny, and allow only what's needed:
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # your ssh (or custom port)
ufw allow 80,443/tcp
ufw enable
ufw status verbose
Review the rule set with nam:** list ports with ss -tlnp and match them against the firewall. Any listening port not in the firewall is a finding.
5. FailurePoint: watch the logs
Fail2ban for SSH brute force, and ship the logs somewhere off-box:
apt install fail2ban
systemctl enable --now fail2ban
Syslog/journald → centralized log destination (Loki, Elasticsearch...) instead of local-only disks that silently fill up. Logging is next useless if the box is dead.
The 20% checklist
- Password auth disabled, root login disabled
- Security updates automated
- Services running as dedicated unprivileged users
- Deny-by-default firewall, verified with
ss -tlnp - Fail2ban + centralized logs
What to skip (mostly)
Mandatory full-disk encryption on cloud images, SELinux lockdowns on every box, and "hardening scanners" with 200 findings that nobody actioned. Start with the five items above; everything else is refinement on top of a sane base.
Summary
Attackers mostly knock on the door, not through the wall. Disable password login, patch promptly, run services unprivileged, deny by default at the firewall, and watch the logs. That's the 20% that stops 80% of the attacks.