How to Automate Wazuh Active Response for External SSH Logins

You’re monitoring SSH auth logs and spot a success from an IP you don’t recognize.
Now what? Waiting for manual triage is too slow.

Wazuh active response lets you automatically block, redirect, or notify the moment a rule fires.
This guide walks through the exact steps – from rule creation to production-ready active response – for external SSH login detection.

1. The Problem: Why External SSH Logins Need Automated Response

A successful external SSH login could be a legit admin working remotely.
Or it could be a compromised credential being used from a hostile IP.

Relying only on dashboards creates reaction gaps.
You need active response to enforce policy immediately.

Active response runs commands on the affected endpoint or a network blocker.
Common actions: drop the source IP via firewall, redirect the session to a honeypot, or trigger a Slack/PagerDuty alert.

2. Step 1: Creating a Detection Rule for External SSH Success

Before active response can fire, Wazuh must generate an alert for the specific activity.
Base it on the built‑in rule 5715 (sshd: authentication success) and add a custom condition for “external” source IP.

2.1 Identifying Relevant Log Fields

From your Wazuh alert, the critical fields are:

In production, you would compare data.srcip against your internal RFC1918 ranges.
If the IP is not internal, flag it as external.

2.2 Writing the Rule XML

Create a custom rule file in /var/ossec/etc/rules/local_rules.xml:

<group name="local,sshd,external_auth,">
  <rule id="100010" level="10">
    <if_sid>5715</if_sid>
    <match>Accepted password</match>
    <description>External SSH login success from $(data.srcip)</description>
    <group>external_login,</group>
  </rule>
</group>

Note: This simplified rule assumes data.srcip is already external via log enrichment.
For true IP‑based filtering, use a CDB list or if_matched_geoip (Wazuh 4.x+).

2.3 Testing with ossec-logtest

Before deploying, test the rule locally:

/var/ossec/bin/ossec-logtest

Paste a sample log line:

Apr 08 08:34:38 srv-ids-01 sshd-session[34219]: Accepted password for srv-ids-01 from 10.0.197.233 port 42070 ssh2

You should see Rule 100010 triggered.

3. Step 2: Building the Active Response Command

Active response executes an external script or binary when a rule fires.
Wazuh ships with several default commands (e.g., firewall-drop, netsh).
We’ll create a custom command that can block IP and notify an admin.

3.1 Block IP with iptables (Linux)

Create a script /var/ossec/active-response/bin/firewall-block.sh:

#!/bin/bash
ACTION=$1
USER=$2
IP=$3
# Block the offending IP for 1 hour
iptables -I INPUT -s $IP -j DROP
# Log the block
logger -t wazuh-ar "Blocked $IP for external SSH login"

Make it executable: chmod 750 firewall-block.sh.

3.2 Redirect to a Honeypot (Advanced)

Instead of blocking, you can redirect the attacker to a low‑interaction honeypot.
Use iptables DNAT to reroute traffic on port 22 to a honeypot IP:

iptables -t nat -I PREROUTING -s $IP -p tcp --dport 22 -j DNAT --to-destination 192.168.77.99:22

Caution: This only works if the endpoint is a gateway or you control routing.

3.3 Send an Alert to Admin

A simple webhook (Slack/Teams) via curl:

curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"Wazuh: External SSH login from $IP to $USER\"}" \
https://hooks.slack.com/services/XXXX

Combine all actions in a single script or call separate commands.

4. Step 3: Configuring Active Response in ossec.conf

Wazuh’s ossec.conf (usually /var/ossec/etc/ossec.conf) contains <command> and <active-response> blocks.
You already have a snippet – we’ll extend it.

4.1 Command Definition

Add a new command that references your script:

<command>
  <name>custom-ssh-block</name>
  <executable>firewall-block.sh</executable>
  <timeout_allowed>yes</timeout_allowed>
  <expect>srcip</expect>
</command>

<expect>srcip</expect> tells Wazuh to pass the source IP as the third argument.

4.2 Active Response Block

Now tie the command to your custom rule:

<active-response>
  <disabled>no</disabled>
  <command>custom-ssh-block</command>
  <location>local</location>
  <rules_id>100010</rules_id>
  <timeout>3600</timeout>  <!-- block for 1 hour -->
</active-response>

• <location>local</location> runs the command on the agent that triggered the alert.
• <rules_id> can be a comma‑separated list.

4.3 Restart Wazuh Manager

After saving ossec.conf, restart the manager:

systemctl restart wazuh-manager

Check for syntax errors:

/var/ossec/bin/wazuh-check-conf /var/ossec/etc/ossec.conf

5. Testing and Validation

Trigger the rule by simulating an SSH login from an “external” IP (e.g., use a VPN exit IP or a cloud VM).
Watch the active response log:

tail -f /var/ossec/logs/active-responses.log

You should see a line like:

Executed custom-ssh-block for srcip 203.0.113.45

Verify the firewall block:

iptables -L INPUT -n | grep 203.0.113.45

Also confirm the Slack/webhook message arrives.

6. Optional Dashboard for Visibility

You don’t need a dashboard for active response to work – but it helps SOC analysts monitor what’s being blocked.

In Wazuh Indexer, create a custom dashboard with:

• A table of rule.id:100010 alerts
• A pie chart of blocked IPs by country (using GeoIP enrichment)
• A timeline of active response actions

Workflow Overview

Below is the automation flow from log to active response.

Technical FAQ

Q: What if the source IP is actually internal (RFC1918)?
A: Extend the custom rule with <if_matched_geoip> or a CDB list of your internal subnets.
Only fire active response when srcip is not in that list.

Q: How do I whitelist specific external IPs (e.g., office VPN)?
A: Add a predecoder filter in the rule or use a CDB list with srcip excluded via <list name="whitelist" />.
Then set <ignore> in the active‑response block.

Q: Can active response be reversed after timeout?
A: Yes – Wazuh automatically calls the same script with delete as the first argument when the timeout expires.
Your script must handle both add and delete actions.

Q: Does this work on Windows with netsh?
A: Absolutely. Replace the Linux script with netsh advfirewall firewall add rule name="block_%IP%" dir=in action=block remoteip=%IP%.
Wazuh already provides a netsh command – just reuse it.