Hardening is making a system harder to attack — by removing what isn’t needed and constraining what is. Start with attack surface, least privilege, and a known baseline.
Why: every running service, open port, installed package, and enabled account is something an attacker can target — so the first principle of hardening is to remove everything you do not need. When: harden by subtraction first (disable, uninstall, close), then constrain what remains. Where: a smaller attack surface means fewer vulnerabilities to patch and fewer paths to defend, which is why minimal systems are more secure by default.
ATTACK SURFACE = everything an attacker could target:
running services · open ports · installed packages · user accounts ·
enabled features · exposed endpoints · trust relationships
Hardening principle #1: REMOVE what you don't need.
fewer services -> fewer vulns -> fewer paths in -> less to defend.
Then CONSTRAIN what must remain.Why: two principles govern what remains — least privilege (every user, service, and process gets only the access it needs) limits the damage of any compromise, and defense in depth (layered controls) means no single failure is fatal. When: apply both everywhere; they are why a breached low-privilege account does not become a full compromise. Where: these principles directly counter the privilege-escalation and lateral-movement techniques from the pentest and DFIR courses.
LEAST PRIVILEGE grant only what's needed, nothing more
-> a compromised account/service can do little damage
DEFENSE IN DEPTH layered controls; no single point of failure
-> one bypassed control isn't game over
Example layering for one server:
firewall -> service auth -> least-priv account -> logging -> EDR -> backups
Attacker must defeat EVERY layer, not just one.Why: hardening should not be improvised — established benchmarks (CIS Benchmarks, DISA STIGs, vendor guides) encode expert consensus on secure configuration, so you harden to a defined, testable standard rather than guessing. When: adopt a benchmark for each OS/app and measure against it. Where: a baseline makes hardening repeatable, auditable, and verifiable (the last lesson), instead of a pile of ad-hoc tweaks.
Don't invent hardening — harden to a published BASELINE:
CIS Benchmarks consensus secure-config guides (per OS/app)
DISA STIGs US DoD hardening standards
vendor guides RHEL/Ubuntu/Microsoft security baselines
A baseline gives you: repeatability, auditability, and a way to MEASURE
compliance (see the final lesson). Tweak from a standard, don't freestyle.