Linux Server Hardening Checklist
A Linux server hardening checklist for Ubuntu, Debian and RHEL-family hosts: SSH, users, firewall, updates, services, logging and backups before going live.
- Typical schedule per new server
- The checklist 5 sections, 23 items
- Variables
{{hostname}}
Use this checklist when you set up a new Linux server, before it is exposed to the internet or holds real data. It covers the practical baseline for Ubuntu, Debian and RHEL-family systems (e.g. Rocky, AlmaLinux). It is not a full benchmark such as the CIS Benchmarks, but it closes the gaps that attackers scan for first. If you build servers from code (e.g. Ansible, cloud-init, Packer), use it to review your image once, then run it on a sample of new servers.
Who owns it
The engineer who builds the server owns the run. A second person spot-checks the result, ideally by trying to log in the ways that should no longer work. Re-run it when a server is rebuilt or changes role.
Common pitfalls
- Locking yourself out. Keep a second SSH session open while you change SSH or firewall settings, and test a new login before closing it. Know how to reach the provider's console.
- Firewall on, but Docker bypasses it. Docker writes its own iptables rules, so published container ports can be reachable despite ufw or firewalld. Bind them to localhost or filter them explicitly.
- Hardening once, drifting forever. Manual changes undo the baseline over time. Put the settings in configuration management where you can.
- Logs only on the box. An attacker with root can delete local logs. Ship them elsewhere.
Each run in Runbook records who hardened which host and when, which is useful evidence during a security review.
The checklist: Harden Linux server {{hostname}}
Accounts and SSH
-
Named user accounts created for each admin, with no shared logins
-
SSH key authentication works for every admin account
-
SSH password authentication disabled
In sshd_config: PasswordAuthentication no and KbdInteractiveAuthentication no. Check files in /etc/ssh/sshd_config.d/ too, since cloud images often re-enable passwords there. Verify with sshd -T, and test a new session before closing the old one.
-
Direct root login over SSH disabled (PermitRootLogin no)
-
Sudo access limited to the people who need it
-
SSH restricted to a VPN, bastion or known IP ranges optional
Network
-
Host firewall enabled with default deny for inbound traffic (e.g. ufw, firewalld, nftables)
-
Only required ports open, and checked from outside with a port scan
Compare with ss -tlnp on the server. Anything listening on 0.0.0.0 that you did not expect needs a reason.
-
Container-published ports bound to localhost or filtered explicitly optional
-
Brute-force protection on exposed services, e.g. fail2ban or provider-level rate limiting optional
Updates and software
-
All packages updated and the server rebooted on the current kernel
-
Automatic security updates enabled (e.g. unattended-upgrades, dnf-automatic)
-
Unneeded services and packages disabled or removed
-
Only trusted package repositories configured
System settings
-
Time synchronisation enabled and the time zone set
-
File permissions on sensitive files checked: SSH keys, application secrets, /etc/shadow
-
Mandatory access control left enabled: AppArmor on Ubuntu/Debian, SELinux enforcing on RHEL-family
-
Disk encryption enabled for servers holding sensitive data optional
Logging, monitoring and backup
-
Logs shipped to a central location outside the server
-
Authentication logs checked for failed and successful logins after setup
-
Server added to monitoring and alerting
-
Backups configured for data and configuration, and one restore tested
-
Server recorded in the inventory with owner and purpose
Checklist as Markdown
Frequently asked questions
What is server hardening?
Server hardening means reducing the ways a server can be attacked: removing what is not needed, locking down access, keeping software updated and making sure you would notice an intrusion. It is a baseline that lowers risk rather than removing it, and it needs to be maintained after setup.
Does this checklist work for Ubuntu?
Yes. The items apply to Ubuntu, Debian and RHEL-family distributions. Only the tools differ, for example ufw and AppArmor on Ubuntu versus firewalld and SELinux on Rocky Linux or AlmaLinux. Add the exact commands your team uses as notes in the template.
Should I use the CIS Benchmarks instead?
The CIS Benchmarks are detailed, widely used hardening guides and are worth using if you need a formal baseline or an audit trail against a published standard. This checklist covers the practical essentials for small teams. Many teams start here and adopt a benchmark, often with an automated scanner, as they grow.
Updated