Linux Server Build and Hardening Template
A fill-in build record for a production Linux server — identity and SSH access, patching ownership, firewall position, logging, time, backups, and the recovery path when you cannot log in.
Markdown. No sign-up, no email.
One per production host. The value of this page is not the hardening list — it is that six months from now, someone can answer "why is this configured like this, and who owns it" without guessing.
Hostname: _______________ Purpose: _______________ Owner (person): _______________ Date built: _______ Environment: dev / staging / prod Physical / VM / cloud: _______
1. Base#
| Distribution and version | |
| Supported until | |
| Kernel | |
| Built from image / script / by hand | |
| Rebuildable from scratch without this host | yes / no |
🔴 The "supported until" date is the row people leave blank and regret. A host on an end-of-life distribution receives no security updates, and migrating it is always urgent by the time anyone notices.
If this host were lost entirely, how is it rebuilt, and how long would it take? _______________
2. Access#
| SSH: password authentication disabled | yes / no |
| SSH: root login disabled | yes / no |
| Key type in use | |
| Who holds keys (named individuals) | |
| Port | |
| SSH exposed to the internet | yes / no — restricted to |
| MFA / bastion in front |
Break-glass access: _______________ (A second key held by a second person on a different machine, or a documented console path. One key held by one person is a single point of failure that costs nothing to fix today and cannot be fixed on the day it matters.)
3. Accounts and privilege#
| Account | Human / service | sudo | Purpose |
|---|---|---|---|
- [ ] No shared logins
- [ ] Service accounts have no interactive shell
- [ ] sudo access is specific rather than blanket, where practical
- [ ] Removal process exists for when a person leaves
4. Patching#
| Who applies security updates | |
| How often | |
| Unattended security upgrades enabled | yes / no |
| Reboot policy for kernel updates | |
| Last patched |
Automated security patching with a defined reboot window is nearly always the right default. The common objection — "an update might break something" — is real, and it is a smaller risk than running known-vulnerable, internet-facing packages for months.
5. Network exposure#
| Port | Service | Bound to | Reachable from | Justified by |
|---|---|---|---|---|
- [ ] Firewall enabled, default deny inbound
- [ ] Every listening service either firewalled or deliberately exposed
- [ ] Verified from outside, not only from the host itself
Run ss -tulpn and reconcile it against this table. Services that quietly bind to all interfaces — databases, caches, admin panels, test instances — are the classic finding, and they are usually found by someone else first.
6. Time, logs and monitoring#
| Time synchronised (NTP source) | |
| Logs shipped off-host to | |
| Local log rotation configured | |
| Disk usage alerting | |
| Host reachability alerting | |
| Who receives alerts |
Logs that exist only on the host are lost in exactly the incidents where you need them. Clock drift makes correlating events across systems impossible, and it is invisible until it matters.
7. Storage and backup#
| Mount | Size | Purpose | Backed up | Retention |
|---|---|---|---|---|
| What is backed up | |
| Where backups are stored (off-host?) | |
| Restore tested on (date) | |
| Time the restore took |
8. Services running#
| Service | Starts at boot | Owner | Runbook |
|---|---|---|---|
- [ ] Nothing running that is not needed
- [ ] Each service starts cleanly after a reboot — tested by actually rebooting
A host that has not been rebooted since it was built has an untested boot path. The reboot you have not planned is the one that discovers a service was started by hand two years ago.
9. Sign-off#
| Name | Date | |
|---|---|---|
| Built by | ||
| Security review | ||
| Handed to operations | ||
| Next review due |