Server Security Hardening Baseline

A pass over one server, from the state it is in now to a documented baseline: SSH and authentication policy, users and privileges, what is installed, what is listening, kernel and service settings, logging, and automatic security updates. Most servers are built in an afternoon under deadline and never revisited. This is the revisiting, written down.

What you get

• One server taken through a documented baseline — SSH and key policy, users and sudo rights, listening services, kernel and service settings, log retention, unattended security updates
• Every listening service either justified or switched off, with the decision recorded against it
• Firewall and security-group rules narrowed to what the server actually needs, including closing the origin to everything but your edge
• A hardening report: what changed, what was deliberately left alone and why, and what we could not change without your sign-off
• A short list of what will drift, so you know what is worth re-checking in six months

What this does not cover

• The application running on the server — a hardened host with a vulnerable web application on it is still a vulnerable web application
• Any test of whether the hardening holds up against somebody trying, which is External Penetration Test
• An audit or a certificate. The report is ours to you; it is not an attestation and cannot be submitted against a standard
• Staying hardened: configuration drifts with every deploy and every urgent fix, and nothing re-checks it unless you add Monthly Vulnerability Scan or the Annual Security Posture Review
• Servers beyond the one in scope, and anything we are not given administrative access to

Who it fits

The right first security purchase for a server that was built fast and never looked at again, and the one to buy before External Penetration Test — on an unhardened host a tester spends your money finding what this fixes. One server at a time: an estate of ten is a conversation, not ten purchases.