Table of Contents
Understanding “Hardening” at a High Level
Hardening is the process of reducing the attack surface of a system and limiting the impact of successful attacks. In practical terms, it means:
- Removing what you don’t need
- Restricting what you must keep
- Adding controls to detect and respond to failures
Think of it as moving from “it works” to “it works safely even when someone is trying to break it”.
This chapter focuses on core principles and mindset. Later chapters apply these ideas to specific areas (kernel, file integrity, vulnerability scanning).
Core Security Goals: CIA and Beyond
Hardening decisions are driven by a few classic security goals:
- Confidentiality – data is only readable by authorized parties.
- Integrity – data and system state cannot be modified undetected.
- Availability – systems and services are accessible when needed.
Two additional goals matter a lot in hardening:
- Accountability – actions can be traced to specific identities.
- Least Surprise / Predictability – the system behaves in a well-understood way, not full of “mystery” behaviors.
Every hardening choice should be justifiable as:
- Increasing one of these,
- Or at least not unacceptably damaging the others.
Principle 1: Least Privilege
Everyone and everything should have only the minimum permissions required to do their job—no more.
Applied to Linux:
- Users should not routinely use
root. - Services should run under dedicated, unprivileged accounts.
- File permissions should be as tight as possible:
640instead of644when world-read is not needed.700for private data directories.- Avoid
chmod 777and similar “fixes” that expand permissions broadly.
Least privilege reduces:
- The impact of compromised accounts or services.
- The usefulness of stolen credentials.
When choosing permissions or roles, always ask: “What is the narrowest permission set that still lets this work?”
Principle 2: Attack Surface Reduction
Attack surface is everything an attacker can interact with: network ports, services, binaries, APIs, user accounts, misconfigurations.
Hardening aims to eliminate or shrink that surface:
- Disable unused network services.
- Remove or avoid installing unnecessary packages.
- Turn off legacy/protocol features you don’t use (e.g., old cryptographic algorithms, weak ciphers).
- Minimize “admin entry points” (e.g., limit SSH access, avoid redundant remote management tools).
A good habit:
- For each service, ask:
- Does it need to be installed?
- If yes, does it need to be running?
- If running, does it need to listen on the network?
- If listening, must it be exposed beyond localhost or a specific subnet?
The fewer moving parts, the fewer things that can go wrong.
Principle 3: Defense in Depth
Assume that some layer will fail—because they will:
- A new kernel bug appears.
- A password leaks.
- A configuration is misapplied.
Defense in depth means:
- Do not rely on a single barrier.
- Use multiple, different controls so that failure of one does not mean full compromise.
Examples of layered controls:
- Network filtering (firewall) + strict service configuration + application-level authentication.
- Minimal file permissions + filesystem-level protections + application logic checks.
- OS-level protections (e.g., memory-hardening features) + process isolation + containerization.
When adding a control, ask:
- Which specific attack path is this layer interrupting?
- What other layers protect against the same path if this layer fails?
Principle 4: Secure by Default
A hardened system should aim for safe defaults, not “works but wide open”.
Key ideas:
- Default deny:
- Firewall: block all incoming; explicitly allow what’s needed.
- Access control: deny access unless explicitly granted.
- Minimal default services:
- Don’t enable network-facing services automatically.
- Secure default configurations:
- Strong cryptographic defaults.
- Avoid “demo” or test accounts.
This principle also means:
- Hardening is ideally baked into golden images, templates, or automation—so every new system starts from a secure baseline, not from “install then secure later”.
Principle 5: Simplicity and Understandability
Complexity is the enemy of security. Overly complex setups:
- Are harder to reason about.
- Lead to misconfigurations.
- Are neglected because no one feels comfortable touching them.
Good hardening:
- Uses the simplest control that accomplishes the goal.
- Avoids piling on tools when one well-understood tool is enough.
- Favors configurations that admins can read and understand at a glance.
Ask yourself:
- Can another admin look at this configuration and understand the security implications quickly?
- Does this setup require specialized, fragile knowledge to maintain?
If the answer is “no” or “yes” respectively, consider simplifying.
Principle 6: Secure Configuration and Baselines
A secure baseline is a known-good, documented configuration that all systems should conform to, as much as possible.
Important aspects:
- Choose and document:
- Required services and packages.
- Standard security settings (SSH, logging, firewall, etc.).
- Account policies (passwords, groups, sudo).
- Apply the same baseline consistently:
- Through configuration management or imaging.
- Regularly review and adjust baselines as:
- Threats evolve.
- Software versions change.
The principle here: configuration is security. Ad-hoc, one-off tweaks are risky. Baselines bring:
- Repeatability.
- Easier auditing.
- Faster recovery.
Principle 7: Secure Defaults for Identities and Access
Hardening strongly emphasizes identity and access:
- Minimize the number of privileged accounts.
- Avoid shared accounts; where they must exist, control and log their use carefully.
- Use strong authentication methods; avoid weak or default credentials.
- Design access with role-based thinking:
- Group permissions by role (e.g., web admins, DBAs, read-only users).
- Assign people/services to roles, not directly to raw privileges.
The underlying principle:
- Access should reflect real tasks and responsibilities, not convenience.
Principle 8: Fail-Safe, Not Fail-Open
Systems fail. Hardening aims to ensure that when they do, they fail in the safest possible way.
Examples of fail-safe vs fail-open:
- If a security component fails to start:
- Fail-open: allow all traffic “until the firewall is fixed”.
- Fail-safe: block traffic or take the system out of service until security controls are working.
- If an application cannot validate a certificate:
- Fail-open: continue the connection anyway.
- Fail-safe: refuse the connection.
Core guidance:
- When in doubt, choose the behavior that prevents unauthorized access, even if it impacts availability—for systems where confidentiality and integrity outweigh availability.
- Be explicit about which systems can tolerate strict fail-safe behavior and which need carefully managed exceptions.
Principle 9: Measurability, Logging, and Visibility
You can’t secure what you can’t see. Hardening includes making the system observable:
- Ensure system events are logged in enough detail to:
- Reconstruct security incidents.
- Detect suspicious behavior.
- Guard those logs:
- Logs must have integrity and protected access.
- Collect and centralize logs where possible:
- To prevent tampering and make analysis easier.
The principle:
- Security is not just prevention; it is also detection and response.
- If a hardening change reduces visibility drastically, consider the trade-offs carefully.
Principle 10: Patch and Change Discipline
Most compromises exploit known vulnerabilities on unpatched systems or insecure changes.
Hardening requires disciplined handling of:
- Updates:
- Apply security patches in a timely, predictable way.
- Test critical updates before wide rollout where possible.
- Changes:
- Avoid untracked, manual configuration tweaks on production systems.
- Document and, ideally, automate changes.
- Review changes that affect security (e.g., opening new ports).
Guiding ideas:
- “No unreviewed, permanent changes to exposed services.”
- Prefer infrastructure-as-code over hand-edited, undocumented config files.
Principle 11: Separation and Isolation
Breaking systems into isolated components limits how far an attacker can move after a compromise.
Forms of isolation:
- Separate user accounts for services.
- Separate machines or VMs for distinct roles (e.g., database vs web frontend).
- Use of containers, chroots, or jails as appropriate.
- Network segmentation:
- Public vs internal subnets.
- Admin-only networks.
Key mindset:
- Assume an attacker can breach one component; architect so that:
- They cannot trivially access others.
- Lateral movement is constrained and detectable.
Principle 12: Assume Breach and Design for Resilience
Modern hardening assumes that breaches are possible and aims to:
- Reduce the chance of initial compromise.
- Limit what an attacker can do post-compromise.
- Make detection likely and response feasible.
This mindset leads to questions like:
- If this account is compromised, what is the blast radius?
- If this host is fully compromised, what critical data/services remain safe?
- How quickly can we rebuild or restore this system from a clean state?
Resilience-focused hardening includes:
- Regular, tested backups.
- Rebuild procedures (e.g., re-provision from a hardened image).
- Clear incident response workflows (covered elsewhere in the course).
Balancing Security, Usability, and Performance
Hardening is not about making systems unusable “for security reasons”. It’s about:
- Finding the right trade-offs:
- A configuration that is secure enough for the risk level,
- While still being operable and maintainable.
- Being honest and explicit about those trade-offs.
When considering a hardening change:
- Identify the threat it addresses.
- Estimate the impact on:
- Users and workflows.
- Operations (maintenance, troubleshooting).
- Performance.
- Decide whether:
- To adopt it as-is,
- To adapt it (e.g., stricter on some systems, looser on others),
- Or to document and accept the risk.
Hardening is a continuous process, not a one-time checklist. Systems change, software changes, threats change. The principles here guide ongoing decisions so your systems remain robust over time.