DevTools Hub

Search tools

Search for a developer tool

Linux Security

Linux Hardening Checklist Generator

Generate a downloadable Linux server hardening checklist — SSH, firewall, permissions, logging — for Ubuntu, Debian, Fedora, or RHEL.

Part of the Linux Security Toolkit

What this does

Generates a complete, downloadable Markdown checklist for hardening a fresh Linux server — Ubuntu, Debian, Fedora, or RHEL — covering system updates, SSH hardening, firewall setup, user and permissions review, and logging and auditing. Every command is specific to the distribution you pick: apt vs dnf, UFW vs firewalld, AppArmor vs SELinux, and the correspondingly different package names for the audit daemon and automatic-update tooling.

Why a checklist instead of a single script

A script that runs unattended on a server you haven't reviewed is its own risk — it might disable password authentication before you've confirmed a working key, or open a firewall port you didn't mean to. This generates a checklist with the exact commands next to each item instead, so you review, understand, and apply each change deliberately rather than running something you can't easily undo.

What's in the checklist

FAQ

Is this checklist enough to pass a security audit or compliance framework?

No — it covers the fundamentals every server should have regardless of industry, not the specific controls a framework like PCI-DSS, HIPAA, SOC 2, or the CIS Benchmarks requires. Use it as a baseline and layer your framework's specific requirements on top.

Why does the firewall section differ between distributions?

Ubuntu and Debian ship UFW as the standard friendly frontend to iptables/nftables; Fedora and RHEL use firewalld by default instead. Both accomplish the same default-deny-then-allow approach, just with different command syntax.

Why SELinux on some distros and AppArmor on others?

Fedora and RHEL enable SELinux, enforcing by default; Ubuntu enables AppArmor by default, and Debian supports it too though less uniformly pre-enabled across every package. Both are mandatory access control systems that confine what a compromised process can do beyond standard file permissions — pick whichever your distro ships rather than trying to run both.

Can I run these commands directly, or should I review them first?

Review them first, especially the SSH hardening section — disabling password authentication before you've confirmed key-based login actually works can lock you out of a remote server with no other access path. Keep a second session open while testing any SSH or firewall change.

Does this checklist cover container or cloud-specific hardening?

No — this is for a traditional Linux server (bare metal or a VM) you administer directly. Container images, Kubernetes clusters, and managed cloud services each have their own hardening concerns this checklist doesn't attempt to cover.

Try it yourself

For the full reasoning behind each item here — not just the commands — see the pillar guide Linux Server Hardening Checklist.

Related tools