Incident response (IR)

When a triaged alert warrants action, Mobius can respond, not just notify. The response layer executes through the Wazuh Manager's Active Response API on the affected agent, using the same connector session that reads your alerts. It is that session's one explicitly-gated write path.

The v1 action: block the attacker IP

The first supported action is an IP block on the affected agent, executed by the Wazuh agent itself via Active Response. It runs firewall-drop on Linux agents and netsh on Windows.

Two modes

Mode	Behavior
Approval-first, the default	The proposed action appears as a pending approval: who, what, why, and the evidence. An analyst approves or rejects it.
Automatic	For rules and severities you designate, the block executes immediately and the console records it.

Every execution, automatic or approved, lands in the audit trail with the triggering incident, the exact command, the target agent, and the outcome.

Setting it up

IR is off by default and configured per environment:

1. Enable it on an environment. On the response page, click Enable Incident Response and pick an environment. Only connector environments whose Wazuh Manager is reachable are offered. You can also enable it directly from the environment card. Flip the toggle on.

2. Choose the mode. Once enabled, the card reveals the Block IP action with a three-way switch:

   • Disabled, and the action never fires.
   • Auto, and a matching alert is blocked immediately.
   • Manual, and a matching alert becomes a pending approval in the response queue, plus a bell notification.

   The block always targets the affected agent only.

3. Protect your own hosts. Below the switch, two settings keep IR from turning on your own infrastructure:

   • Never block. IP addresses or CIDR ranges IR never acts on, in either mode: your vulnerability scanner, jump hosts, the admin subnet. One entry per line. Add these before you turn Auto on.
   • Block internal addresses automatically. On by default in Auto mode, because a compromised internal host spreads to its neighbours and cutting it off is what IR is for. Turn it off if you prefer internal addresses to wait for your approval while public attackers are still blocked automatically.

4. Approve or ignore, in Manual mode. A pending card shows the alert, source IP, and agent. Execute sends the block. Ignore dismisses it.

What Auto mode holds for approval

Even in Auto mode, a few cases wait in the queue with the reason shown in the notification, and nothing is dropped:

• the alert was raised on the Wazuh manager host itself (agent 000), where an unattended firewall change is not something to do automatically;
• the verdict came from Mobius recognising an attack pattern across many alerts rather than from the alert's own evidence;
• the address is internal and you turned automatic internal blocks off.

IR also records one action per attacker address per hour for an environment, whatever the outcome. A burst of alerts from one source becomes a single block or a single approval, not dozens.

Tracking actions in History

The moment an action is sent, automatically or after approval, it moves to History as Launched. Mobius does not wait on further confirmation. A send the manager or connector rejects shows as Failed with the reason. Dismissed approvals show as Ignored. Filter History by environment with the selector.

If a block fails

The reason on the row says what happened and what to do:

• The connector on this host does not allow Active Response. The Mobius connector permits it by default, so this means the machine owner opted out on the host, or the host runs an older connector. To allow it again: standalone connector, set active_response.enabled: true in /etc/mobius/connector.yaml and restart it; Wazuh Fleet plugin, remove the active_response opt-out from /etc/fleet-connector/plugins/mobius.yaml (or the file itself) and reconnect the plugin. An older Fleet plugin that predates this is read-only and needs updating. While a connector is read-only, the environment shows IR · read-only connector, and Mobius does not send blocks to it.
• The environment's connector is offline. Nothing was sent; the connector needs to check in again.
• The Wazuh manager could not deliver the command to the agent. The agent is not connected to the manager or the id is unknown.
• The Wazuh manager refused the command. The API user needs permission to run active-response commands.
• The Wazuh manager did not answer in time. The block was not confirmed.

IR is per-environment and never touches environments where it is off. The card's readiness line and the IR badge on the environment card, On or Off, reflect whether the Wazuh Manager is reachable.

Safety properties

• No new exposure. The Wazuh Manager API on :55000 is reached locally by the connector on your node, and nothing new listens anywhere.
• Explicitly gated. Everything else the connector does is read-only by design. The response call is a separate, allowlisted operation.
• Reversible. IP blocks are Wazuh Active Response actions with the standard timeout and undo semantics your deployment already uses.
• Your own hosts stay reachable. Addresses on the environment's never-block list are never acted on, and one attacker address gets one action per hour, so a scanner or a noisy source cannot flood the queue or the firewall.

note

IR is configured per environment: enable it, choose approval-first or automatic per severity, and set who gets the approval notifications. See Notifications.