Summary of "Watch how Wazuh Stop a SSH attack in Seconds with Active Response"

Watch how Wazuh Stops an SSH Attack in Seconds with Active Response

Demo: an SSH brute‑force (Hydra) attack is launched from an attacker Linux machine against a Linux victim. Wazuh detects the attack with correlation rules and automatically blocks the attacker IP using the built‑in firewall-drop active response.

What the video demonstrates

Simulation of an SSH brute‑force attack using Hydra against a Linux victim.
Wazuh detects SSH/PAM failures, correlates events, and triggers an automatic block (firewall‑drop) on the attacker IP.
Note: the presenter also tried Windows + OpenSSH, but could not get a usable source IP from the Windows agent, so active response did not work there — the demo uses Linux agents.

Environment and tools

Wazuh: manager (server) + agent on the victim machine; Wazuh dashboard / Threat Hunting UI to view alerts.
Attacker: Linux machine running Hydra to perform SSH password guessing.
Victim: Linux machine running SSHD (demo IP shown: 192.168.10.137).
Files edited on the manager:
- /var/ossec/etc/rules/local_rules.xml
- /var/ossec/etc/ossec.conf
Commands/tools used:
- hydra for brute force
- systemctl restart wazuh-manager to apply config changes

Detection details seen in Wazuh

Many SSH‑related alerts were logged: invalid/non‑existent user attempts and PAM authentication failures (valid username, wrong password).
Alerts were mapped to MITRE techniques (credential access / password guessing / brute‑force).
Important fields captured include the agent IP and data.srcip (attacker source IP). The correlation rule uses data.srcip to ensure events are coming from the same source.

Guide — creating a correlation rule and active response

Create a custom correlation rule (edit local_rules.xml)
- Group name: e.g., brute_force_correlation
- Custom rule ID: use a unique number (demo used 120000 as an example)
- Severity level: high (demo used level 12)
- Frequency: 3
- Timeframe: 120 seconds (match 3 events within 2 minutes)
- Ignore: 300 seconds (suppress repeat alerts for 5 minutes)
- Match any of several default Wazuh rule IDs for SSH/PAM failures (examples noted in the demo: 5763, 5503, 5760, 5710, 351, etc.)
- Add condition to correlate on the same source IP (data.srcip) to avoid false positives from many different IPs
- Description: e.g., “Correlation brute force SSH attack — these rule IDs triggered three times from same IP within 2 minutes”
Configure the active response (edit ossec.conf)
- Ensure the built‑in firewall-drop command exists and is enabled (Wazuh includes a firewall-drop active‑response script)
- Add an active‑response entry with fields such as:
  - disabled: no
  - command: firewall-drop
  - location: local (run on manager)
  - rules_id: the custom correlation rule ID (the one created above)
  - timeout: 180 seconds (initial block duration)
  - repeated_offenders / backoff: configure incremental blocking for repeat offenders (demo used repeated_offenders = 60 so subsequent blocks increase: first block 180s, then 180+60, etc.)
- Restart Wazuh manager: systemctl restart wazuh-manager

Behavior observed during the test

When Hydra triggered the configured threshold (3 matching events from the same data.srcip within 120s), the custom correlation rule fired.
Wazuh executed the firewall-drop active response. Active‑response logs showed the host was blocked (demo showed an active response rule ID 651).
The attacker IP was blocked for the configured timeout; pings from the attacker to victim failed while blocked.
Repeated offenders were subject to incremental timeouts (backoff increases blocking duration for persistent attackers).

Notes, tips, and follow‑ups

Use the data.srcip condition so correlation triggers only for repeated attempts from the same source IP — this distinguishes single‑source brute force from distributed scans or legitimate traffic.
Set ignore to suppress alert noise and avoid repeated alerts for the same incident.
Use repeated_offenders / backoff to avoid permanently blacklisting IPs while increasing penalties for persistent attackers.
Presenter plans a follow‑up showing an alternative active response: disabling the specific user account instead of blocking the IP.

Files / locations edited

/var/ossec/etc/rules/local_rules.xml — custom correlation rule
/var/ossec/etc/ossec.conf — active response configuration
Restart Wazuh manager after edits: systemctl restart wazuh-manager

Main speakers / sources

Video presenter/demonstrator (unnamed) — walkthrough and configuration steps
Wazuh manager (server) and Wazuh agent (on victim)
Attacker machine running Hydra
Wazuh dashboard / Threat Hunting UI used to observe alerts and active response actions

Summary takeaway: with a custom correlation rule keyed on data.srcip and the built‑in firewall-drop active response, Wazuh can detect SSH brute‑force attempts and block the attacker IP in seconds while allowing configurable backoff and suppression to reduce noise.