Linux Server Build & Hardening Checklist

Host: _______________ Role: _______________ Date: _______

1. Before anything else#

• [ ] Purpose written down — what runs here and what does not
• [ ] Owner named
• [ ] Environment recorded: production / staging / development
• [ ] Built from an image or configuration management, not by hand
• [ ] The build can be repeated from scratch and has been, at least once

A server nobody can rebuild is a server nobody can patch confidently.

2. Access#

• [ ] Key-based SSH only — password authentication disabled
• [ ] Root login over SSH disabled
• [ ] Each person has their own account — no shared logins
• [ ] sudo rather than root, and sudo use is logged
• [ ] A second key or break-glass path exists, held separately
• [ ] Departed users removed — checked, not assumed
• [ ] SSH exposed to a management network or bastion, not to the internet

One key with no break-glass is fine until the laptop holding it fails. That is the day it is impossible to add a second.

3. What is listening#

• [ ] ss -tulpn reviewed — every listening port explained
• [ ] Nothing bound to 0.0.0.0 that should be on 127.0.0.1
• [ ] Firewall default-deny inbound
• [ ] Each allowed port has a named reason
• [ ] Database, cache and admin ports not reachable from outside
• [ ] Checked from outside the host, not only from on it

The most common serious finding on any server review is a service listening on all interfaces because that was the default in its configuration file.

4. Patching#

• [ ] Security updates applied at build
• [ ] A patching mechanism exists — automatic, or scheduled with an owner
• [ ] Reboot policy decided: kernel updates need one, and something must decide when
• [ ] The distribution release is still supported
• [ ] End-of-support date recorded in the same place as the owner

5. Services#

• [ ] Only what is needed is installed
• [ ] Each service runs as its own non-root user
• [ ] Service files define restart behaviour deliberately
• [ ] Dependencies between services declared, not assumed from start order
• [ ] Services start on boot — verified by rebooting once, on purpose

6. Disks and the failure that fills them#

• [ ] Separate filesystem for logs and variable data, so a full log cannot fill root
• [ ] Log rotation configured and verified by checking rotated files exist
• [ ] Disk usage alerting at 75% and 90%
• [ ] Growth rate known — how many days until full at the current rate?
• [ ] Temporary directories cleaned on a schedule

A full root filesystem takes down everything on the host at once and gives almost no warning to anyone not watching for it.

7. Time, names and locale#

• [ ] Time synchronised, and drift alerted on
• [ ] Timezone set deliberately, UTC unless there is a reason
• [ ] Hostname resolves, forward and reverse
• [ ] DNS resolvers configured with more than one

8. Logging#

• [ ] Logs shipped off the host — a compromised host's local logs cannot be trusted
• [ ] Authentication attempts logged and retained
• [ ] sudo use logged
• [ ] Retention period set and known
• [ ] Someone would notice a failed login burst — say who

9. Backup and recovery#

• [ ] What on this host is not reproducible from code? Listed.
• [ ] That data is backed up
• [ ] A restore has been performed, not just configured
• [ ] Rebuild time from scratch measured
• [ ] Recovery does not depend on anything stored only on this host

10. Monitoring#

• [ ] Reachability
• [ ] CPU, memory, disk, load
• [ ] The service's own health, not just the host's
• [ ] Certificate expiry, if the host serves TLS
• [ ] Alerts reach a person, and that person is named

11. Handover#

• [ ] Documented: purpose, owner, what runs, how to rebuild, how to restore
• [ ] In the same place as everything else, not on one person's machine
• [ ] Someone other than the builder has read it

Sign-off#

Back to Linux