Security reference · Free to use

Linux server security checklist

25 audits covering 157 checks across your server, databases, web server and Docker. Every check has the exact command to run, the value that passes, and the fix when it does not.

25
audits
4 categories
157
individual checks
named
0
agents installed
read-only

These are not generic recommendations. Every pass, warning and failure threshold is transcribed from the audit script that applies it, and a build check fails if a page and its script ever disagree. Counts here describe the published audit scripts; the CtrlOps desktop app adds its own preflight checks at runtime, so the number it reports for a run is higher.

Four categories

Start with what this server runs

Every host has a server layer. Add the database, web server and Docker categories depending on what else it is running.

VPS & Server

The box itself - access, network, patches and permissions.

7 audits45 checks
  • SSH & Access
  • Services & Processes
  • File System
  • Firewall & Network
  • Application Security
  • System Updates
  • Logging & Monitoring

Start here. Every host has a server layer, whether or not it runs a database, a web server or containers.

Database

MySQL and MariaDB, PostgreSQL, MongoDB and Redis.

6 audits37 checks
  • Authentication
  • Configuration & Hardening
  • Network Isolation
  • Least-Privilege Permissions
  • Transport Encryption
  • Credential Storage

Web Server

Nginx and Apache - what they expose and how they are configured.

6 audits36 checks
  • Security Headers
  • Configuration Hardening
  • Content Exposure
  • TLS Configuration
  • Identification & Patching
  • Logging & Monitoring

Docker

Images, containers, volumes and the daemon socket.

6 audits39 checks
  • Daemon & Socket
  • Image Vulnerabilities
  • Volume Permissions
  • Runtime & Resources
  • Container Hardening
  • Network & Supply Chain
Full catalog

Every audit in the catalog

All 25 audits and what each one covers. Written-up audits link to their full checklist with commands and thresholds; the rest are on the way.

VPS & Server

7 audits45 checks
  • SSH & AccessRoot login, password auth, port, idle timeout, authorized keys and sudo privileges11 checks~14s2 need root
  • Services & ProcessesSoonAttack surface from services, listeners and scheduled jobs9 checks~11s2 need root
  • File SystemSoonDangerous permissions, set-id binaries and sensitive files7 checks~10s4 need root
  • Firewall & NetworkSoonFirewall state, exposed ports, Docker bypass and network policy6 checks~14s4 need root
  • Application SecuritySoonTLS certificates, runtime versions and database access5 checks~10s2 need root
  • System UpdatesSoonPending patches, automatic updates, kernel and reboot state4 checks~8s
  • Logging & MonitoringSoonSeparated logging and monitoring checks3 checks~9s3 need root

Database

6 audits37 checks
  • AuthenticationSoonPasswordless access, anonymous users, remote root and auth methods8 checks~14s8 need root
  • Configuration & HardeningSoonService users, installer defaults, patches, log placement and backups7 checks~19s5 need root
  • Network IsolationSoonEngine inventory, bindings, exposed ports and web admin tools7 checks~12s4 need root
  • Least-Privilege PermissionsSoonWildcard hosts, FILE privilege, admin accounts and allowed hosts6 checks~12s6 need root
  • Transport EncryptionSoonTLS enforcement and server certificates for client connections5 checks~11s5 need root
  • Credential StorageSoonConfig files in the web root, config permissions, exposed .git and client credential files4 checks~10s1 need root

Web Server

6 audits36 checks
  • Security HeadersSoonHSTS, CSP, framing, MIME sniffing, referrer and permissions policy8 checks~10s
  • Configuration HardeningSoonFile permissions, web root ownership, request limits and modules6 checks~11s2 need root
  • Content ExposureSoonDirectory listing, hidden files, backups, methods and status endpoints6 checks~14s2 need root
  • TLS ConfigurationSoonProtocol versions, cipher suites, certificates and HTTPS redirection6 checks~12s1 need root
  • Identification & PatchingSoonServer inventory, version disclosure, worker privileges and pending updates5 checks~9s1 need root
  • Logging & MonitoringSoonAccess and error logging, log permissions, rotation and WAF presence5 checks~12s2 need root

Docker

6 audits39 checks
  • Daemon & SocketSoonDaemon socket exposure, group access, log level and rootless mode8 checks~12s3 need root
  • Image VulnerabilitiesSoonContainer image CVEs, secrets, configuration and supply-chain hygiene8 checks~16s6 need root
  • Volume PermissionsSoonDocker volume mount safety, permissions and ownership7 checks~13s7 need root
  • Runtime & ResourcesSoonSeccomp, AppArmor/SELinux and memory, CPU, PID and restart limits6 checks~10s6 need root
  • Container HardeningSoonPrivileged mode, user, capabilities, privilege escalation and mounts5 checks~10s5 need root
  • Network & Supply ChainSoonPort publishing, inter-container connectivity, secrets, updates and images5 checks~12s4 need root
Getting started

How to work through it

  1. Step 1Pick the category you actually runStart with the server itself, then add database, web server or Docker depending on what the host is doing.
  2. Step 2Run the commands by handEvery check is ordinary POSIX shell. Each published page gives you the command, the values that pass, and the fix.
  3. Step 3Automate the re-checkThe first audit is the easy part. Drift is what undoes it, so the audit has to run again after every change.
Provenance

Why trust these thresholds?

Because you can check them. Here is the same check, in the script that runs it and on the page that documents it.

In the audit script
##RESULT|PASS|SSH Root Login|HIGH|Root login is disabled
transcribed, then asserted on every build
On this page
PASSThe effective value is noRoot login is disabled entirely.

One check, from the file that runs it to the row you read. The severity, the status and the wording all come from the same place, and the build fails if they stop matching.

  • Thresholds, not opinionsEvery pass, warning and failure value is transcribed from the script that applies it, not from a hardening guide.
  • Guarded against driftnpm run check:checklist fails the build if a page and its audit script ever disagree about a severity or a threshold.
  • Read-only by designEvery check inspects state. Nothing is installed, no service restarts, and nothing is written to the host.
  • Runs on any Linux you haveThe scripts detect the package family themselves, from Ubuntu and Debian through RHEL, Rocky, Alma, SUSE and Alpine.
FAQ

Security checklist questions

A server security audit checklist is a structured set of configuration checks run against a server to find the settings attackers look for: permissive remote access, over-privileged accounts, exposed services, weak cryptography and missing patches. A useful checklist states not just what to check but the exact value that passes, so two people auditing the same server reach the same conclusion.
157 checks across 25 audits, grouped into four categories: the server itself, databases, web servers and Docker. That count is of the published audit scripts. The CtrlOps desktop app also runs its own preflight checks at runtime, so the number it reports for a run is higher.
No. Every check on every page is an ordinary shell command you can paste into a terminal, with the passing value and the fix written out beside it. CtrlOps automates running them across a fleet and scoring the result, but the checklists themselves are the whole method and are free to use.
Yes. They are read-only: they parse configuration files and query system state. No package is installed, no service is restarted, nothing is written to the host, and no application data is read. A full category takes seconds of wall-clock time.
Any check that reads another account's files or a root-owned configuration file, such as another user's authorized_keys or /etc/sudoers. Each audit lists how many of its checks need root. Checks that cannot read what they need are reported as skipped rather than guessed, so an unprivileged run never reports a false pass.
After every change to who has access and after provisioning any new server, then monthly as a baseline for production. The reason is configuration drift rather than new vulnerabilities: a setting relaxed for a quick test is rarely reverted, and nothing on the server reminds you it happened.
Audit your fleet

Run every one of these checks, on every server

CtrlOps runs these audits over your existing SSH connection - no agents, no scripts to manage. $7/user/month after a 1 month free trial - no credit card required.

✓ Start instantly·✓ No credit card·✓ No sneaky autorenewals