Listen to this Post
Introduction:
Most security teams rely on IP blocking as their primary defense against brute-force attacks. However, attackers easily bypass this by switching to a new IP address, continuing their assault indefinitely. A stronger approach combines source blocking with target protection—disabling the user account under attack—creating a resilient defense that stops credential guessing even when attackers rotate IPs.
Learning Objectives:
- Understand the limitations of single-factor brute-force defenses and the value of layered active response.
- Configure Wazuh to detect SSH brute-force attempts using Rule 5763 and trigger simultaneous firewall-drop and account-disable actions.
- Implement and test reversible active response scripts that automatically restore access after a configurable timeout.
You Should Know:
1. Understanding Wazuh’s Active Response Framework
Wazuh’s active response module allows the SIEM to execute commands on monitored endpoints when specific alerts fire. Unlike passive alerting, active response takes immediate action—blocking IPs, disabling accounts, or killing malicious processes. The framework uses a command queue (/var/ossec/queue/alerts/ar) to communicate with agents, ensuring low-latency execution. In a brute-force scenario, when rule 5763 (SSH brute-force) triggers, Wazuh can run multiple responses in parallel. This architecture transforms detection into automated, proportionate remediation.
Step‑by‑step guide to verify active response readiness on a Linux Wazuh agent:
Check if active response is enabled in agent’s ossec.conf grep -A 3 "<active-response>" /var/ossec/etc/ossec.conf List available active response commands on the manager /var/ossec/bin/wazuh-control info | grep -i "ar" Test connectivity from manager to agent (replace <agent_id>) /var/ossec/bin/agent_control -l | grep "Active response"
For Windows agents, ensure the Wazuh service runs with sufficient privileges (SYSTEM account) to execute `net user` commands.
- Configuring Wazuh to Detect SSH Brute‑Force (Rule 5763)
Rule 5763 is part of Wazuh’s default SSH rule set (/var/ossec/ruleset/rules/0365-sshd_rules.xml). It triggers after a defined number of failed SSH logins within a time window. To ensure it fires correctly, verify your agent’s SSH logs are being collected and the frequency threshold meets your environment’s risk tolerance.
Step‑by‑step configuration:
- On the Wazuh manager, edit the local rules file to adjust the brute-force threshold:
sudo nano /var/ossec/etc/rules/local_rules.xml
- Add or modify the frequency rule (example: 5 failures in 60 seconds):
<group name="local,sshd,brute_force,"> <rule id="100100" level="10" frequency="5" timeframe="60" ignore="300"> <if_matched_sid>5716</if_matched_sid> <same_source_ip /> <description>SSH brute-force attempt (custom threshold).</description> <group>authentication_failures,pci_dss_11.4,gpg13_7.1,</group> </rule> </group>
3. Restart Wazuh manager: `sudo systemctl restart wazuh-manager`
- On the agent, ensure SSH logs are forwarded (default `/var/log/auth.log` or
/var/log/secure).
3. Implementing firewall-drop and disable-account Active Responses
Wazuh comes with pre-built active response scripts: `firewall-drop` (uses iptables or firewalld) and `disable-account` (locks a user account). The `disable-account` script is not included by default; you must create it. Below is a working script for Linux that locks the targeted user account and logs the action.
Step‑by‑step to create `disable-account` script on the Wazuh agent:
1. Create the script: `sudo nano /var/ossec/active-response/bin/disable-account.sh`
2. Add the following content:
!/bin/bash Wazuh active response: lock user account read INPUT_JSON USERNAME=$(echo $INPUT_JSON | jq -r '.parameters.alert.data.username') if [ -n "$USERNAME" ] && [ "$USERNAME" != "null" ]; then /usr/sbin/usermod -L $USERNAME logger -t wazuh-ar "Disabled account $USERNAME due to brute-force" fi exit 0
3. Make executable: `sudo chmod 750 /var/ossec/active-response/bin/disable-account.sh`
- On the Wazuh manager, define the command in
/var/ossec/etc/ossec.conf:<command> <name>disable-account</name> <executable>disable-account.sh</executable> <timeout_allowed>no</timeout_allowed> </command>
- Create an active response rule that triggers both actions:
<active-response> <command>firewall-drop</command> <location>local</location> <rules_id>5763</rules_id> <timeout>300</timeout> </active-response> <active-response> <command>disable-account</command> <location>local</location> <rules_id>5763</rules_id> <timeout>300</timeout> </active-response>
Restart the manager after changes.
4. Automating Reversible Actions with Timeout
The timeout attribute (300 seconds in the example) ensures both actions are automatically undone after five minutes. Wazuh’s active response daemon tracks each execution and runs the `restart` command with `-d` (delete) flag. For firewall-drop, this removes the iptables rule. For disable-account, you need a complementary restore script. Extend `disable-account.sh` to handle both `add` and `delete` actions.
Enhanced script with reversible logic:
!/bin/bash read INPUT_JSON ACTION=$(echo $INPUT_JSON | jq -r '.command') USERNAME=$(echo $INPUT_JSON | jq -r '.parameters.alert.data.username') if [ "$ACTION" = "add" ] && [ -n "$USERNAME" ]; then /usr/sbin/usermod -L $USERNAME echo "$(date): Locked $USERNAME" >> /var/log/wazuh-ar.log elif [ "$ACTION" = "delete" ] && [ -n "$USERNAME" ]; then /usr/sbin/usermod -U $USERNAME echo "$(date): Unlocked $USERNAME" >> /var/log/wazuh-ar.log fi exit 0
Wazuh automatically calls the script with `command: “add”` when the alert triggers and `command: “delete”` after the timeout expires. This provides hands‑off recovery without operator intervention.
- Testing the Defense: Simulating an SSH Brute‑Force Attack
Before deploying to production, simulate an attack from a test machine to verify both responses activate and revert correctly. Use `hydra` or a simple bash loop.
Step‑by‑step test:
- On a test Linux machine (attacker), install hydra:
sudo apt install hydra -y Debian/Ubuntu sudo yum install hydra -y RHEL/CentOS
- Launch a brute-force attack against the Wazuh agent’s SSH service:
hydra -l known_username -P /usr/share/wordlists/fasttrack.txt ssh://<agent_ip>
- On the Wazuh manager, monitor alerts in real time:
tail -f /var/ossec/logs/alerts/alerts.json | grep -E "rule|5763"
4. On the agent, verify IP is blocked:
sudo iptables -L -n | grep <attacker_ip>
5. Verify account lock:
sudo passwd -S <known_username> | grep Locked
6. After 300 seconds, re-check iptables and account status—both should be restored.
6. Extending to Windows RDP Brute‑Force
The same pattern applies to Windows environments facing RDP brute‑force attacks. Replace `firewall-drop` with `netsh advfirewall` and `disable-account` with net user /active:no.
Windows active response script for RDP (save as disable-rdp-account.bat):
@echo off set USERNAME=%1 if "%USERNAME%"=="" exit /b if "%WAZUH_COMMAND%"=="add" ( net user %USERNAME% /active:no echo %date% %time% Disabled %USERNAME% >> C:\wazuh-ar.log ) else if "%WAZUH_COMMAND%"=="delete" ( net user %USERNAME% /active:yes echo %date% %time% Enabled %USERNAME% >> C:\wazuh-ar.log )
Add the command to `ossec.conf` on the Windows agent and trigger on RDP brute‑force rules (e.g., rule 5710 for Windows Event ID 4625). Use `netsh advfirewall firewall add rule name=”BlockBrute” dir=in remoteip=
- Cloud Hardening: Integrating Wazuh with AWS Security Groups
For cloud-hosted instances, iptables rules are ephemeral and may interfere with load balancers. Instead, use Wazuh’s custom active response to modify AWS Security Groups via AWS CLI. This approach blocks the attacker’s IP at the cloud network perimeter.
Step‑by‑step cloud response:
- On the Wazuh manager (or a dedicated automation server), install AWS CLI and configure IAM credentials with permissions to revoke Security Group ingress.
2. Create a script `/var/ossec/active-response/bin/aws-sg-block.sh`:
!/bin/bash read INPUT_JSON ATTACKER_IP=$(echo $INPUT_JSON | jq -r '.parameters.alert.data.srcip') SG_ID="sg-xxxxxxxxxxxxx" Replace with your instance's SG ACTION=$(echo $INPUT_JSON | jq -r '.command') if [ "$ACTION" = "add" ] && [ -n "$ATTACKER_IP" ]; then aws ec2 revoke-security-group-ingress --group-id $SG_ID --protocol tcp --port 22 --cidr $ATTACKER_IP/32 elif [ "$ACTION" = "delete" ]; then aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 22 --cidr $ATTACKER_IP/32 fi
3. Register the command in `ossec.conf` and link to rule 5763. Note that timeout restoration re-adds the authorized IP, which is safe if the attack has stopped. For production, consider using AWS WAF rate-based rules instead.
What Undercode Say:
- IP blocking is necessary but insufficient – Attackers easily bypass it by rotating IPs; locking the target account neutralizes the attack regardless of source address.
- Automated, reversible responses reduce SOC fatigue – A timeout-based rollback eliminates manual re-enablement, allowing blue teams to focus on threat hunting rather than remediation.
Wazuh’s dual-action active response transforms brute‑force detection from a noisy alert into a self-healing control. By blocking the source and disabling the target, you cut off both the current and future attack vectors. The reversible design ensures legitimate users aren’t locked out permanently—a critical requirement for production systems. This pattern extends beyond SSH to any authentication service (RDP, FTP, web logins) and any infrastructure (on‑prem, cloud, hybrid). Security engineering is no longer about building taller walls; it’s about designing responses that adapt to attacker behavior in real time.
Prediction:
Within 18 months, SIEMs and XDR platforms will embed “dual‑action” playbooks as default templates for authentication brute‑force. We will see vendors pre‑packaging active responses that combine IP reputation blacklisting with identity‑aware access controls (e.g., temporary MFA step‑up or account velocity throttling). As AI‑driven attack tools automate IP rotation, static blocking will become obsolete. The future of detection engineering lies in context‑aware, multi‑vector responses that treat the entire attack surface—source, target, and session—as one unified defense plane. Organizations that fail to implement layered active responses will remain vulnerable to credential stuffing and password spraying, regardless of their firewall sophistication.
▶️ Related Video (70% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Yasinagirbas Wazuh – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
