Advanced Linux Server Hardening — Post-Breach Recovery
SY0-701 Obj 2.5 · 4.2 · Multi-Config Hardening
🚨
A threat actor gained SSH access to your Ubuntu 22.04 production web server using brute-forced credentials.
Forensics shows the attacker pivoted to root via a misconfigured sudo policy and established persistence.
You must harden four configuration files simultaneously — some fixes interact with each other.
Wrong changes in one file can break another working control.
sshd_config 0/7 pts
fail2ban 0/4 pts
ufw rules 0/3 pts
Consequence Qs 0/4 pts
/etc/ssh/sshd_config7 settings to fix — attacker used password auth + root login
⚠️ Note: changing Port also requires updating the fail2ban jail port — they must match.
/etc/fail2ban/jail.localBrute-force protection — must match the SSH port you set
1[DEFAULT]
2bantime = 1h
3findtime = 10m
4maxretry = 5
5
6[sshd]
7enabled =
8port = # must match sshd_config Port
9maxretry =
10bantime =
💡 Interdependency: If you changed SSH to port 4422 in sshd_config, the fail2ban port must also be set to 4422 — otherwise fail2ban monitors the wrong port and brute-force attempts go undetected.
UFW Firewall RulesSelect the correct UFW commands to apply — order matters
# Select the correct UFW rule for each requirement:
# 1. Allow SSH on new port (from management subnet only: 10.0.1.0/24)
# 2. Allow web traffic (HTTP + HTTPS) from anywhere
# 3. Set default policies (deny inbound, allow outbound)
⚠️ Configuration Consequence Questions — choose the best answer
Q1. You set PasswordAuthentication no but a junior admin has not yet uploaded their SSH public key. What is the immediate consequence?
Q2. You changed SSH to port 4422 in sshd_config but forgot to update fail2ban's port setting. What happens?
Q3. Which action is the most effective single change to prevent the original brute-force attack vector used in this breach?
Q4. The attacker established persistence by adding a cron job as root. After hardening SSH, what additional step must you take to remove this persistence?