Goal

Understand why system hardening matters and learn the foundational principles of defense-in-depth security: how attackers exploit unhardened systems, and how layered defenses contain a breach.

Prerequisites: Weeks 1-10 (especially Week 5 SSH hardening, Week 9 physical security)

This is Part 1 of 4 - Subsequent parts cover MAC systems, kernel hardening, and sandboxing.

1. Why System Hardening Matters

The Attacker’s Advantage

Without hardening:

Single vulnerability → Full system compromise

Example attack chain:

  1. Attacker exploits Firefox vulnerability (RCE)
  2. Gains shell as your user
  3. Reads all your files (no isolation)
  4. Exfiltrates GPG keys, SSH keys, browser cookies
  5. Installs rootkit for persistence
  6. Game over

With proper hardening:

Single vulnerability → Contained to sandboxed Firefox process

Same attack with sandboxing:

  1. Attacker exploits Firefox vulnerability (RCE)
  2. Gains shell inside Firefox sandbox
  3. LIMITED - Sees only whitelisted paths (the browser profile and Downloads), not the rest of your home, ~/.ssh or ~/.gnupg
  4. BLOCKED - Can’t read your SSH/GPG keys or documents outside the whitelist
  5. HARDER - System directories are read-only and the rest of your home is not writable, but the browser profile itself is, so the browser’s own cookies and logins are still at risk
  6. Attacker contained to the browser’s own data

Defense in Depth Philosophy

Multiple security layers:

Layer 1: Network firewall (Week 5: UFW)
Layer 2: Application sandboxing (This week: Firejail, AppArmor)
Layer 3: Filesystem permissions (Linux DAC)
Layer 4: Mandatory Access Control (AppArmor/SELinux)
Layer 5: Kernel hardening (sysctl, ASLR, etc.)
Layer 6: Physical security (Week 9: airgaps, FDE)

Why layered defense:

  • Attackers must defeat ALL layers
  • Single layer failure doesn’t mean total compromise
  • Different layers defend against different attack types
  • Increases attacker cost and reduces success probability

Real-World Hardening Scenarios

Scenario 1: Journalist Using Untrusted Software

  • Must open potentially malicious PDFs from sources
  • Solution: PDF viewer in Firejail sandbox, no network, no write access
  • Even if PDF exploits viewer, attacker trapped in sandbox

Scenario 2: Developer Running Build Scripts

  • Untrusted npm/pip packages might contain malware
  • Solution: Run builds in disposable containers, no access to SSH keys
  • Malicious packages can’t exfiltrate credentials

Scenario 3: Privacy Researcher Analyzing Malware

  • Need to execute suspicious binaries safely
  • Solution: Isolated VM with no network, snapshot before execution
  • Can analyze behavior without risk to host system

2. System Hardening Foundations

Threat Modeling for Hardening

Ask these questions:

1. What are we protecting?

  • GPG/SSH private keys
  • Browser session cookies
  • Work documents
  • Personal communications
  • System integrity (against rootkits)

2. Who are we protecting against?

  • Remote network attackers
  • Malicious applications we must run
  • Physical attackers with limited time
  • Forensic investigators
  • Insider threats (compromised local accounts)

3. What’s our risk tolerance?

  • Convenience > security (minimal hardening)
  • Balanced (moderate hardening)
  • Security > convenience (maximum hardening)

4. What can we realistically maintain?

  • Set-and-forget configurations
  • Monthly security updates
  • Active monitoring and tuning

Hardening Principles

1. Principle of Least Privilege (PoLP)

Every process should have only the minimum permissions needed
  • Don’t run apps as root unless absolutely necessary
  • Use sudo for specific commands, not full root shells
  • Grant network access only when needed
  • Limit filesystem access to necessary directories

2. Attack Surface Reduction

Fewer services running = fewer potential vulnerabilities
  • Remove unused software packages
  • Disable unnecessary services
  • Close all ports except those actively used
  • Minimize setuid binaries

3. Fail Securely

If something breaks, default to secure state
  • Firewall defaults to DENY, allow specific exceptions
  • AppArmor defaults to DENY, allow specific capabilities
  • If access control uncertain, deny access

4. Defense in Depth

Multiple independent security layers
  • Network firewall + application firewall
  • DAC permissions + MAC (AppArmor/SELinux)
  • Process isolation + filesystem encryption
  • No single point of failure

Hardening Levels Overview

Level 1: Minimal (Low effort, good baseline)

  • Run Lynis and fix critical warnings
  • Enable UFW firewall
  • Disable unnecessary services
  • Time investment: 1-2 hours
  • Security gain: closes the most common misconfigurations

Level 2: Moderate (Balanced security/usability)

  • Everything in Level 1
  • Apply kernel hardening (sysctl)
  • Enable AppArmor for Firefox, Tor, PDF viewers
  • Time investment: 4-6 hours
  • Security gain: contains many single-application compromises

Level 3: Paranoid (Maximum security)

  • Everything in Level 2
  • Firejail all untrusted applications
  • Custom AppArmor profiles for all internet-facing apps
  • Blacklist uncommon kernel modules
  • Regular re-auditing with Lynis
  • Time investment: 10-15 hours + ongoing maintenance
  • Security gain: substantially raises attacker cost; needs ongoing tuning and re-auditing

Recommendation: Start with Level 2 (Moderate) for most users

Up Next

Week 11b covers Mandatory Access Control (MAC) systems and security auditing with Lynis - the tools you’ll use to implement these principles.

Key Takeaways

  • Defense in depth means multiple independent security layers
  • Least privilege restricts every process to minimum needed permissions
  • Attack surface reduction eliminates unnecessary code and services
  • Fail secure defaults to blocking when uncertain
  • Hardening turns a single exploit that would have meant full compromise into a contained incident