Linux server
hardening baseline.
A practical starting point for reducing attack surface without turning operations into guesswork.
Hardening is about reducing unnecessary exposure while preserving required functionality: inventory → minimize privilege → minimize services → patch → monitor → validate.
1. Start with the Attack Surface
Begin with inventory, intended services, administrative paths and network exposure. A secure baseline should reflect the server's actual role rather than applying an identical configuration everywhere.
2. Accounts and Privilege
Remove or disable unnecessary accounts, use least privilege and review administrative access. Avoid routine work from privileged shells when a narrower account is sufficient.
Users → Groups → Privileges → Sudo / Admin path → Audit3. SSH Security
Restrict SSH access to the users and networks that require it. Prefer strong authentication, disable unnecessary authentication methods and monitor authentication activity.
Limit exposure
Restrict who can reach administrative SSH endpoints.
Strong authentication
Use an appropriate strong authentication mechanism and avoid unnecessary password-based access.
Least privilege
Administrative access should map to the user's actual operational need.
4. Services and Network Exposure
ss -tulpn
systemctl --type=service --state=runningCompare listening services with the intended server role. Remove or disable services that are not required rather than relying on obscurity.
5. Network Boundary
Apply host and network controls appropriate to the workload. Restrict management interfaces, expose only required application ports and document approved communication paths.
6. Patching and Supported Software
Maintain supported operating-system and application versions. Define a repeatable patch process with testing, rollout, verification and exception handling.
7. Logging and Visibility
Security-relevant logs should be retained and monitored. Hardening without visibility makes later investigation harder.
8. Validate the Baseline
After each hardening change, verify that required services still function and that the intended exposure has actually been reduced.
Baseline → Change → Functional test → Security test → Evidence → Approve9. Troubleshooting After Hardening
If an application stops working after a hardening change, identify the first changed control and compare expected versus observed behavior.
10. Common Hardening Mistakes
- Hardening without inventory. Required dependencies can be disabled accidentally.
- Overly broad administrative access. Privilege becomes difficult to audit.
- Open management ports. Administrative services are exposed beyond the required boundary.
- Ignoring logging. Security events cannot be investigated reliably.
- One-shot hardening. Configuration drifts as software and workloads change.
11. Baseline Rule
Minimize services, minimize privileges, patch consistently and keep security-relevant activity observable.