Security & System Hardening

Security is layered (defense in depth): no single control is sufficient. This chapter assembles a practical hardening baseline you can apply to any new host, emphasising modern, current best practices.

11.1 SSH Hardening

SSH is the front door. Use keys, not passwords, and forbid direct root login.

# On your laptop: create a key and install it
ssh-keygen -t ed25519
ssh-copy-id deploy@server
 
# In /etc/ssh/sshd_config on the server:
# PermitRootLogin no
# PasswordAuthentication no
sudo systemctl reload ssh   # (or sshd on RHEL)

11.2 Host Firewall

Default-deny: block everything, then allow only the ports you actually need.

# Ubuntu (ufw)
sudo ufw default deny incoming
sudo ufw allow ssh
sudo ufw enable
 
# RHEL-family (firewalld)
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

11.3 Updates

The single highest-value security task is keeping software patched, because most attacks use known, already-fixed bugs.

sudo apt update && sudo apt upgrade -y   # Ubuntu
sudo dnf upgrade -y                      # RHEL-family
# Consider unattended-upgrades for automatic security patches

11.4 Least Privilege

Give every user and service the minimum access needed. Audit for dangerous permissions.

# Find world-writable files (a common risk):
find / -xdev -type f -perm -0002 2>/dev/null
 
# Find setuid-root binaries to review:
find / -xdev -perm -4000 -type f 2>/dev/null

11.5 Intrusion Mitigation

fail2ban watches logs and temporarily bans IPs after repeated failed logins. SELinux (RHEL) and AppArmor (Ubuntu) add Mandatory Access Control that confines programs even if they’re compromised.

sudo apt install -y fail2ban   # enables an SSH jail by default
getenforce                     # SELinux mode (RHEL-family)
sudo aa-status                 # AppArmor status (Ubuntu)

11.6 Guided Lab: Apply a Hardening Baseline

Estimated time: 30 minutes. Apply a first-day hardening checklist to a test VM or cloud instance. (Keep a second SSH session open as a safety net.)

• Create a non-root admin user with sudo and install your SSH key (ssh-copy-id).
• Confirm key login works in a NEW terminal before changing anything else.
• In sshd_config set PermitRootLogin no and PasswordAuthentication no; reload ssh; re-test in a new session.
• Enable a default-deny firewall allowing only SSH (ufw or firewalld).
• Apply all available updates.
• Install fail2ban and confirm its SSH jail is active (sudo fail2ban-client status sshd).

Troubleshooting

Practice & Prove It

Write-the-command drills

• Generate an ed25519 SSH key pair.
• Allow SSH through ufw and enable the firewall.
• Disable a service’s password and root SSH (name the two sshd_config directives).
• Find all world-writable files on the root filesystem.
• Apply all pending updates on Ubuntu.

Quick quiz

• What should you verify before disabling password SSH login?
• What does a default-deny firewall policy mean?
• Why is patching the highest-value security task?
• Why is chmod 777 dangerous?
• What’s the right response when an app breaks under SELinux?

Key Takeaways

• Harden SSH first: keys only, no root login, no passwords — and test in a second session.
• Run a default-deny firewall that allows only required ports.
• Patching is the single highest-value security habit; automate it with a rollback plan.
• Apply least privilege and audit world-writable and setuid files; never use chmod 777.
• fail2ban blunts brute force; SELinux/AppArmor confine apps — fix policy, don’t disable it.

Next — Chapter 12: shell scripting and automation.