Lion Cipher Lab

Auto-block an SSH brute-force attacker with Wazuh active response

• SOC Analyst / Blue Team
• Intermediate
• ~75 min
• Free · no account required

Why it matters

Every SOC learns to SEE attacks before it learns to STOP them, and there is a long, dangerous gap between the two. A dashboard lighting up with 'SSHD brute force' at 3am does nothing on its own — someone has to notice it, decide, and act, and by the time a human does, the attacker has had thousands of guesses. Active response closes that gap for the clear-cut cases: the moment the SIEM is confident enough (a specific rule, at a specific level, firing), it runs a script that blocks the source, with no human in the loop. That is genuinely powerful and genuinely risky, which is exactly why it is…

What you'll learn

• explaining in plain words what SIEM active response is: the SIEM detects an alert, then automatically runs a script on the endpoint (or the manager) to DO something about it — here, block the attacker's IP
• telling a STATELESS response (a one-shot action) apart from a STATEFUL one (an action that automatically reverts after a timeout), and knowing firewall-drop is stateful
• standing up a single-node Wazuh stack with Docker and enrolling a Wazuh agent on the SSH server you want to protect
• measuring the before state: an attacker can keep hammering the SSH login unimpeded, and Wazuh's default rule 5763 ('SSHD brute force') fires but nothing acts on it
• binding the built-in firewall-drop command to rule 5763 in ossec.conf with an <active-response> block (command, location:local, rules_id, timeout) and reloading the manager
• proving the after state: re-running the same authorized failed-login burst gets the source IP dropped, the connection is refused, and /var/ossec/logs/active-responses.log records the add — then the block auto-expires when the timeout lifts
• stating the honest limits out loud: active response is reactive (attempts land before the block), IP-based (NAT collateral, retry after timeout), and can lock you out — an allowlist and key-only auth matter
• judgment: when automated blocking helps versus when it is a foot-gun, and why it complements — never replaces — rate limiting, key-only SSH and fail2ban

Steps in this lab

1. From zero: what 'active response' is, and why it is a loaded gun
2. Stand up (or reuse) a single-node Wazuh stack
3. Protect an SSH server: enroll a Wazuh agent on it
4. Measure the BEFORE: brute-force your own account and watch rule 5763 fire (but nothing act)
5. Wire firewall-drop to rule 5763 in ossec.conf
6. Measure the AFTER: re-run the attack and watch the IP get dropped
7. The honest limits: what active response does NOT protect you from

Open the full interactive lab →