Server Hardening Checklist
Interactive security checklist with step-by-step commands to harden your Linux server. Track progress, filter by severity, and export your results.
What is server hardening?
Server hardening is the process of reducing a Linux server's attack surface: closing unused ports, disabling unnecessary services, tightening SSH access, enforcing strong authentication, and applying kernel-level security parameters via sysctl. A freshly provisioned VPS starts receiving automated brute-force attempts within minutes of getting a public IP, so hardening is not optional polish β it is the first task after provisioning any internet-facing machine, before the application ever goes live.
How does this checklist work?
The checklist contains 60+ security tasks organized into categories β user and authentication, SSH hardening, firewall and network, system updates, kernel parameters, file permissions, logging and auditing, SSL/TLS, and backups. Every item ships with the exact commands to run, is rated Critical, High, Medium, or Low, and can be checked off as you go. You can filter by severity or search, track your completion percentage, and export your results to document the work.
What should I harden first on a new Linux server?
Start with the Critical items: create a non-root sudo user, switch SSH to key-based authentication (ssh-keygen -t ed25519, then ssh-copy-id), set PermitRootLogin no and PasswordAuthentication no in /etc/ssh/sshd_config, enable a default-deny firewall with ufw or iptables, and turn on automatic security updates. Those five steps alone block the vast majority of opportunistic attacks. Then layer on fail2ban, sysctl network hardening, and audit logging.
What does CIS hardening mean?
CIS Benchmarks are consensus security baselines published by the Center for Internet Security for Ubuntu, RHEL, Debian, and most other distributions. Level 1 covers low-risk essentials; Level 2 is stricter and may break functionality. This checklist covers the practical core that overlaps with CIS Level 1 β SSH policy, firewall defaults, password policy, file permissions, and auditing β without requiring a full compliance toolchain like OpenSCAP. It is a working baseline, not a formal certification.
How do I audit a Linux server for security issues?
Pair this checklist with automated scanning. Run lynis audit system for a scored report with remediation hints, ss -tlnp to see every listening port and the process behind it, last and lastb to review login history, and find / -perm -4000 -type f to list SUID binaries. Re-audit on a schedule β configuration drifts as packages get installed and teammates make quick fixes, so hardening done once in January rarely survives to December.
Will hardening break my server or lock me out?
The classic mistake is enabling a default-deny firewall before allowing your SSH port, or restarting sshd with a typo in the config. Always keep your current SSH session open while testing a second connection, run sshd -t to validate sshd_config before restarting, and add your SSH allow rule before setting ufw default deny incoming. If you change the SSH port, update the firewall and any fail2ban jail in the same session.
Is my checklist progress saved?
Yes β progress is stored in your browser's local storage, entirely client-side. Nothing you check off is sent to a server, so it is safe to use this page while working on production infrastructure. Progress persists across visits on the same browser; use the export feature to keep a permanent record, share evidence of completed hardening with your team, or attach the results to a compliance ticket.