On this page
What server hardening means
A freshly created server is built to be easy to access, not safe. Password logins are often enabled, services listen on every interface and updates wait for someone to apply them. Within minutes of going online, automated scanners begin trying to log in. Server security hardening is the process of closing those openings so only what your business needs is reachable.
It is not about making a server impossible to breach. It is about removing the easy routes that automated attacks rely on, and making sure you would notice if something did go wrong.
Who needs it
- Any business running its own VPS or cloud server, especially one set up quickly to meet a launch date.
- SaaS companies preparing for a customer security questionnaire.
- Agencies hosting client sites, where one compromised site can affect every other site on the server.
- Clinics, coaching platforms and others holding personal data they are responsible for protecting.
- Servers inherited from a previous developer with unknown accounts and open ports.
What’s included
- SSH restricted to key-based login, with root login and password authentication disabled.
- Named admin accounts with sudo, and removal of unused or former users’ keys.
- Firewall with default-deny and only required ports open.
- fail2ban or equivalent to block repeated failed login attempts.
- Automatic security updates enabled and verified.
- Unnecessary services and packages removed; databases and caches bound to localhost.
- File permission and secret checks for application directories and configuration files.
- A hardening report listing each change, why it was made and how to reverse it.
How we harden a server
- Take a backup or snapshot before making changes.
- Scan open ports and running services from outside and inside the server.
- Set up key-based access and confirm it works before disabling passwords, so nobody is locked out.
- Apply firewall, update and service changes one at a time, testing the application after each.
- Re-scan to confirm the attack surface is reduced as intended.
- Deliver the report and walk through anything that needs your decision.
Tools we use
Typical tooling includes OpenSSH configuration, UFW or nftables, cloud provider firewalls on AWS, Google Cloud, Azure, DigitalOcean and Hetzner, fail2ban, unattended-upgrades and audit tools such as Lynis for a baseline check. For fleets of servers, Ansible applies the same hardening consistently. Putting Cloudflare in front adds a layer of filtering for web traffic.
What affects timeline and cost
Hardening a new server is quick. An older, busy production server takes longer because every change must be tested against live applications. The number of servers, control panels, legacy services that must stay open and any compliance requirements also affect scope.
For businesses with several servers, we typically harden one first as a pilot, confirm nothing is affected, then apply the same configuration to the rest with Ansible so every server ends up with the same protections.
Compliance-driven work, such as mapping controls to a customer’s security questionnaire or a specific framework, takes extra time for evidence and documentation. We can prepare that material alongside the technical changes so the answers you give are backed by what is actually configured on the server.
What the hardening report contains
The report is designed to be useful to three audiences: your own team, a future administrator and, where relevant, a client or auditor asking how your servers are protected. It is short and specific rather than a generic checklist.
| Section | What it tells you |
|---|---|
| Starting point | Open ports, services, users and update status before any change |
| Changes made | Each change, why it was made and how to reverse it |
| Accepted exceptions | Anything left open for business reasons and the controls around it |
| Final state | The re-scan showing what is reachable now |
| Recommendations | Further steps, ranked by practical risk, that were outside the agreed scope |
Keeping this record matters because hardening decays. New software gets installed, a port is opened for a quick test, a contractor is given access. With a documented baseline, a later review can compare the current state against the report and spot drift quickly instead of starting from scratch.
Common mistakes
- Disabling password login before confirming key login works, and losing access.
- Opening a database port temporarily for testing and never closing it.
- Relying on a non-standard SSH port as the main defence, instead of keys and a firewall.
- Hardening once and never checking again as new software is installed.
Related: Firewall Configuration, Server Security and Security Auditing. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
Will hardening break my application?
We change one thing at a time and test after each step, with a snapshot taken first. Anything that must stay open for business reasons is agreed with you.
Does hardening make my server unhackable?
No server is unhackable. Hardening removes the easy routes most automated attacks use and makes problems easier to detect.
Can I show the report to my client or auditor?
Yes. The report is written to be readable by non-specialists and lists each change and its purpose.
How often should hardening be reviewed?
Whenever significant software is added, and at regular intervals. Ongoing server management includes these checks.
Can you harden a server with a control panel?
Yes, working within what the panel supports so its own updates do not undo the changes.
Talk to us about server security hardening
SSH keys, fail2ban, disabled root login and the smallest possible attack surface.