Server Estate Audit — Sample
A worked example of auditing a fleet of Linux servers — what is listening, who can log in, what is patched, and the hosts nobody could rebuild.
Markdown. No sign-up, no email.
This is an illustrative example. The estate and figures are invented to show the shape of an audit that produces a short ordered list. Copy the structure; run it against your own hosts.
Server estate audit — July 2026#
| Hosts | 43 |
| Method | Automated collection, then manual review of anything unexpected |
| Collected | Listening ports, accounts, sudo rules, patch state, disk, service inventory |
| Prepared for | Platform team |
1. Summary#
| Hosts | ||
|---|---|---|
| Built from configuration management | 26 | 60% |
| Built by hand, cannot be reproduced | 17 | 40% |
| Security patches current | 31 | 72% |
| Distribution still supported | 39 | 91% |
| Logs shipped off-host | 22 | 51% |
| Restore tested in the last year | 9 | 21% |
The 17 unreproducible hosts are the finding behind most of the others. They are unpatched more often, they are the ones with unexplained listening ports, and they are the ones nobody wants to reboot.
2. What is listening#
Collected from every host, then checked from outside.
| Ports | |
|---|---|
| Explained by the host's documented purpose | 88 |
| Unexplained | 19 |
| Bound to all interfaces where localhost would do | 14 |
| Reachable from outside the management network | 6 |
Six reachable services that should not be, all on hosts in the unreproducible 17:
| Service | Exposure | Note |
|---|---|---|
| Database admin interface | Internet | Authentication required, no rate limit |
| Cache, no authentication | Internal, all VLANs | Default configuration |
| Metrics endpoint | Internet | Discloses internal hostnames |
| Test web server | Internet | Left from a 2024 investigation |
| SSH on a non-standard port | Internet | Password authentication enabled |
| Message queue admin | Internal, all VLANs | Default credentials unchanged |
The last two are the immediate work. Everything else on this page can wait a week.
3. Access#
| Count | |
|---|---|
| Accounts across the estate | 214 |
| Belonging to current staff | 178 |
| Belonging to departed staff | 21 |
| Shared or role accounts with a password | 9 |
| Accounts with passwordless sudo | 31 |
| Hosts with password SSH enabled | 4 |
| Hosts with root SSH permitted | 2 |
Twenty-one accounts belong to people who have left, the oldest 19 months. Three have passwordless sudo. None of them has authenticated recently, which is the only reassuring thing on this table and is not a control.
One key, no break-glass. Every administrative key in the estate is held on the same laptop. Nothing in this audit found anything, and losing that laptop is currently an estate-wide outage.
4. Patching#
| Hosts | |
|---|---|
| Automatic security updates | 24 |
| Manual, patched within 30 days | 7 |
| Manual, over 90 days behind | 12 |
| Pending reboot for a kernel update | 15 |
| Distribution out of support | 4 |
The 12 unpatched hosts are all in the unreproducible 17. That is not a coincidence — a host nobody can rebuild is a host nobody wants to touch, so patching is deferred, which makes it more fragile, which makes people less willing to touch it.
The four out-of-support hosts run an application whose vendor has not certified a newer release. That is a supplier conversation, not a technical one, and it has not been had.
5. Disks#
| Hosts | |
|---|---|
| Over 90% on any filesystem | 3 |
| Over 75% | 11 |
| Logs on the root filesystem | 18 |
| Log rotation configured but not working | 5 |
| Inode usage over 80% | 2 |
Five hosts have log rotation configured and not functioning — the configuration exists and no rotated files have been produced. Two of those are among the three above 90%. This is the most predictable outage in the estate: a full root filesystem takes everything on the host at once, and the growth rate says two of them reach it within a month.
6. Recovery#
| Hosts | |
|---|---|
| Rebuildable from code | 26 |
| Backed up | 38 |
| Restore actually tested | 9 |
| Documented purpose and owner | 29 |
| No identifiable owner | 7 |
Seven hosts have no owner. Two of them are running services that other systems depend on, so they cannot be switched off, and nobody can say what would break if they were.
7. Priority#
| When | Action |
|---|---|
| Today | Disable password SSH on the internet-facing host · change the queue's default credentials |
| This week | Remove the 21 departed accounts · fix log rotation on the 5 · a second administrative key, held elsewhere |
| This month | Explain or close the 19 unexplained ports · bind the 14 to localhost · patch the 12 |
| This quarter | Bring the 17 hand-built hosts under configuration management, starting with the 12 unpatched · assign owners to the 7 |
| Standing | Test a restore quarterly, on a rotating host |
The quarterly item carries the rest. Hand-built hosts are why 12 are unpatched, why 19 ports are unexplained, and why nobody wants to reboot 15 that need it.
Notes on using this format#
Check from outside the host. Fourteen services bound to all interfaces looked correct in their own configuration files. The exposure is only visible from somewhere else.
Correlate findings against reproducibility. Every serious finding here clustered on the hosts nobody could rebuild. That correlation turns a list of 60 items into one root cause.
Report configured-but-not-working separately from not-configured. Five hosts had log rotation configured. A checklist asking "is rotation configured?" would have passed all five.