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

1. 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”

2. 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.