4.3.1. System Hardening Techniques

💡 First Principle: The minimum viable system is the most secure system. Every package that isn't installed can't be exploited. Every service that isn't running can't be attacked. Start with a minimal installation and add only what's needed — this is dramatically more effective than installing everything and trying to secure it.

Disabling Unused Filesystems:

# Prevent loading of uncommon filesystem modules (reduces attack surface)
# /etc/modprobe.d/disable-filesystems.conf:
install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install squashfs /bin/true
install udf /bin/true
# 'install X /bin/true' replaces modprobe X with a no-op

Removing Unnecessary SUID/SGID Bits:

# Find all SUID files
find / -perm /4000 -type f 2>/dev/null

# Find all SGID files
find / -perm /2000 -type f 2>/dev/null

# Remove SUID from a file that doesn't need it
chmod u-s /usr/bin/unnecessary_tool

Secure Boot and UEFI:

Secure Boot (enabled in UEFI firmware) uses cryptographic signatures to verify each component in the boot chain — firmware → bootloader → kernel → kernel modules. Only signed components execute. This prevents rootkits from inserting unsigned code early in the boot process.

• UEFI stores keys in firmware: Platform Key (PK), Key Exchange Key (KEK), Signature Database (db)
• Linux distributions ship with signed bootloaders (shim → GRUB → kernel)
• Custom kernels/modules need signing with a Machine Owner Key (MOK) via mokutil

SSH Hardening:

# /etc/ssh/sshd_config — key hardening options
PermitRootLogin no               # Never allow root to SSH directly
PasswordAuthentication no        # Key-based auth only (disable passwords)
PubkeyAuthentication yes         # Enable key auth
AuthorizedKeysFile .ssh/authorized_keys
X11Forwarding no                 # Disable X forwarding (reduces attack surface)
AllowUsers alice bob             # Whitelist specific users
AllowGroups sshusers             # Or whitelist by group
MaxAuthTries 3                   # Limit authentication attempts per connection
ClientAliveInterval 300          # Probe the client after 5 min of silence
ClientAliveCountMax 2            # Drop after 2 unanswered probes (~10 min) — detects DEAD connections, not idle users

# After editing sshd_config — validate before restarting
sshd -t                          # Test config syntax
systemctl reload sshd            # Reload (preferred over restart — keeps sessions alive)

fail2ban — Automatic IP Blocking:

systemctl status fail2ban
cat /etc/fail2ban/jail.conf      # Default config (don't edit)
cat /etc/fail2ban/jail.local     # Local overrides (create this)

# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
bantime = 3600                   # Ban for 1 hour
findtime = 600                   # Within 10-minute window

fail2ban-client status           # Overview
fail2ban-client status sshd      # SSH jail status
fail2ban-client set sshd unbanip 10.0.0.5   # Unban an IP

Avoiding Insecure Protocols:

Security Banners:

# /etc/issue        — Displayed before login on local console
# /etc/issue.net    — Displayed before login on network connections (SSH)
# /etc/motd         — Message of the Day, displayed after successful login
echo "Authorized use only. All activity monitored." > /etc/issue.net
echo "Authorized use only. All activity monitored." > /etc/issue

⚠️ Exam Trap: Disabling PasswordAuthentication in sshd_config only prevents password-based SSH login — it does not affect console/local logins or sudo passwords. If you lock yourself out by setting PasswordAuthentication no before adding your SSH key, you'll need console access to recover.

Reflection Question: A CIS Benchmark audit flags that SSH allows password authentication and permits root login. Write the two sshd_config lines that fix both issues, and identify what must exist before making these changes to avoid locking yourself out.