Goal

Understand why system hardening matters and master the foundational principles of defense-in-depth security. Learn how attackers exploit unhardened systems and how layered defenses contain breaches.

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. BLOCKED - No access to real home directory
  4. BLOCKED - Can’t read files outside sandbox
  5. BLOCKED - Can’t install persistence (read-only system)
  6. Attacker stuck in isolated container

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: 50% improvement over default

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: 75% improvement over default

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: 90%+ improvement over default

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 transforms single-exploit-to-full-compromise into contained incidents