What is hardening?
Hardening is shrinking the attack surface of a system: closing unused ports, removing unnecessary software, patching, enforcing least privilege, and setting secure defaults. It is the unglamorous, ongoing work of making a system hard to break into.
Why it matters
Most breaches exploit known, preventable weaknesses — unpatched software, open ports, default credentials — not novel attacks. Hardening closes those doors before anyone tries them. As DevOps owns the infrastructure, this is a direct responsibility, and a strong line on any resume.
What to learn
- Minimizing installed packages and running services
- Keeping systems patched
- Closing unused ports and tightening firewalls
- Least-privilege users and file permissions
- Disabling password SSH and root login
- Container hardening: non-root, read-only filesystems
- Benchmarks like the CIS guidelines
Common pitfall
Hardening a server once at launch and never revisiting it. New packages get added, ports get opened for a quick fix, patches lag — and the attack surface creeps back up. Hardening is continuous: automate patching, audit regularly, and treat configuration drift toward openness as a problem to catch.
Resources
Primary (free):
- CIS — Benchmarks · docs
- OWASP — Docker security cheat sheet · docs
- Ubuntu — Security hardening · docs
Practice
Take a server or container and harden it: remove unneeded packages, close all but required ports, ensure it runs as non-root, and confirm SSH password login is off. For a container, set a read-only root filesystem. Done when a port scan shows only what you intend to expose.
Outcomes
- Reduce attack surface by removing software and closing ports.
- Enforce least privilege and non-root execution.
- Harden containers with read-only filesystems.
- Treat hardening as continuous, not one-time.