Linux hardening principles - defence in depth

Hardening is the discipline of making a host resistant to attack. The principles are universal, even as the specific controls change with each new vulnerability.

Defence in depth

No single control is perfect. Defence in depth layers multiple controls so an attacker has to defeat all of them:

Internet
  |
  v
Network firewall (perimeter)
  |
  v
Host firewall (nftables)
  |
  v
SSH hardening (publickey, modern ciphers)
  |
  v
Mandatory access control (SELinux / AppArmor)
  |
  v
Patch discipline (current packages)
  |
  v
Auditing (auditd)
  |
  v
Monitoring (logs, alerts)

Each layer fails differently. A firewall breach is caught by MAC; a MAC bypass is caught by auditing; an audit bypass is caught by monitoring. The attacker has to defeat all of them.

Least privilege

Every process and user should have the minimum access needed to do their job:

• Services run as dedicated users (nobody, www-data, nginx, postgres) with no shell.
• Users have only the groups they need (no blanket sudo).
• sudo grants specific commands, not blanket root.
• File permissions are 600 for secrets, 644 for config, 755 for binaries.

Fail-safe defaults

If a control fails, the host should fail closed:

• Default firewall policy: drop, not accept.
• Default MAC mode: enforcing, not permissive.
• Default sudo: requires password, not NOPASSWD.
• Default SSH: publickey, not password.
• Default password: locked, not empty.

A “user-friendly” default is a security risk if it is also the wrong default.

Complete mediation

Every access to every resource should be checked. If there is a path that bypasses the check, the check is not complete. Examples:

• A backup script that reads /etc/shadow directly, bypassing the user authentication.
• A service that runs as root and skips MAC because the policy is permissive.

Open design

Security should not depend on secrecy of the design. A closed-source MAC system is not inherently more secure than an open-source one. The discipline - the policy review, the testing, the monitoring - is what matters.

Least common mechanism

Different processes should not share security-critical state. A web server and a database should not share a service account. A user account should not be shared between operators.

Psychological acceptability

Security controls that operators cannot or will not use are useless. The break-glass account must exist. The MFA must work offline. The hardening must not break legitimate functionality.

Mapping to CIS Controls

The CIS Controls (v8) are a widely-adopted framework:

Mapping host hardening to CIS gives a recognised vocabulary and helps with audits.

Knowledge check