Wazuh Active Response - автоматическое реагирование

Модуль Active Response (AR) в Wazuh обеспечивает автоматическое реагирование на инциденты безопасности. При срабатывании правила обнаружения сервер отправляет команду на агент для выполнения ответного действия - блокировки IP-адреса, отключения учетной записи или запуска пользовательского скрипта. Этот механизм сокращает время реагирования с минут до секунд и позволяет нейтрализовать угрозы до вмешательства аналитика.

Принцип работы Active Response

Active Response функционирует в связке с движком правил Wazuh. Последовательность обработки инцидента выглядит следующим образом:

  1. Агент собирает лог-данные с конечной точки
  2. Данные передаются на сервер Wazuh для анализа
  3. Движок правил сопоставляет событие с набором правил
  4. При совпадении правила с настроенным Active Response сервер формирует команду
  5. Команда отправляется на агент (или выполняется локально на сервере)
  6. Агент запускает соответствующий скрипт реагирования
  7. Результат выполнения логируется для аудита

Реагирование может быть привязано к конкретному правилу по его идентификатору (rules_id), группе правил (rules_group) или минимальному уровню критичности (level).

Встроенные скрипты реагирования

Wazuh поставляется с набором готовых скриптов, расположенных в директории /var/ossec/active-response/bin/ на агентах.

firewall-drop

Блокирует IP-адрес атакующего на сетевом уровне. На Linux использует iptables, на Windows - Windows Firewall. Применяется для автоматической блокировки источников brute-force атак, сканирования портов и других сетевых угроз.

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710,5711</rules_id>
  <timeout>600</timeout>
</active-response>

В данном примере при срабатывании правил 5710 или 5711 (множественные неудачные попытки SSH-аутентификации) IP-адрес атакующего блокируется на 600 секунд.

host-deny

Добавляет IP-адрес в файл /etc/hosts.deny (TCP Wrappers). Работает на системах, поддерживающих механизм TCP Wrappers - преимущественно Linux и BSD.

<command>
  <name>host-deny</name>
  <executable>host-deny</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>host-deny</command>
  <location>local</location>
  <level>8</level>
  <timeout>3600</timeout>
</active-response>

disable-account

Деактивирует учетную запись пользователя. На Linux выполняет passwd -l, на Windows отключает учетную запись через net user. Применяется при обнаружении компрометации пользовательских учетных данных.

<command>
  <name>disable-account</name>
  <executable>disable-account</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<active-response>
  <command>disable-account</command>
  <location>local</location>
  <rules_group>authentication_failures</rules_group>
  <timeout>900</timeout>
</active-response>

restart-wazuh

Перезапускает службу агента Wazuh. Используется для применения обновленной конфигурации или восстановления работоспособности агента после сбоя.

<command>
  <name>restart-wazuh</name>
  <executable>restart-wazuh</executable>
  <timeout_allowed>no</timeout_allowed>
</command>

Stateful и stateless реагирование

Wazuh поддерживает два режима работы Active Response.

Stateful (с восстановлением)

Stateful-реагирование автоматически отменяет выполненное действие по истечении заданного таймаута. Например, firewall-drop с таймаутом 600 секунд заблокирует IP-адрес, а через 10 минут автоматически разблокирует. Этот режим подходит для временного сдерживания угроз и предотвращает постоянную блокировку легитимных пользователей при ложных срабатываниях.

Для включения stateful-режима необходимо указать <timeout_allowed>yes</timeout_allowed> в блоке <command> и задать значение <timeout> в блоке <active-response>.

Stateless (без восстановления)

Stateless-реагирование выполняет действие однократно без автоматической отмены. Применяется для необратимых операций: отправка уведомления, создание снимка системы, запись события в журнал аудита.

Для stateless-режима параметр <timeout_allowed> устанавливается в no, а <timeout> в блоке <active-response> не указывается.

Конфигурация Active Response

Конфигурация состоит из двух XML-блоков в файле ossec.conf на сервере Wazuh.

Блок command

Определяет исполняемый скрипт и его параметры:

<command>
  <name>my-custom-response</name>
  <executable>my-script.sh</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>
ПараметрОписание
nameУникальное имя команды для ссылки из блока active-response
executableИмя скрипта в директории /var/ossec/active-response/bin/
timeout_allowedРазрешает stateful-режим с автоматической отменой (yes/no)

Блок active-response

Определяет условия срабатывания и параметры выполнения:

<active-response>
  <command>my-custom-response</command>
  <location>local</location>
  <rules_id>100100,100101</rules_id>
  <timeout>300</timeout>
</active-response>
ПараметрОписание
commandИмя команды из блока <command>
locationМесто выполнения: local (на агенте), server, defined-agent, all
rules_idСписок ID правил через запятую
rules_groupГруппа правил для срабатывания
levelМинимальный уровень критичности правила
timeoutВремя в секундах до автоматической отмены (stateful)
repeated_offendersУвеличение таймаута при повторных срабатываниях

Параметр location

  • local - скрипт выполняется на агенте, с которого пришел алерт
  • server - скрипт выполняется на сервере Wazuh
  • defined-agent - скрипт выполняется на указанном агенте (требует <agent_id>)
  • all - скрипт выполняется на всех агентах

Повторные нарушители (repeated_offenders)

Параметр repeated_offenders позволяет увеличивать время блокировки при повторных инцидентах от одного источника:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5710</rules_id>
  <timeout>600</timeout>
  <repeated_offenders>1800,3600,86400</repeated_offenders>
</active-response>

В этом примере: первая блокировка - 10 минут, вторая - 30 минут, третья - 1 час, четвертая и последующие - 24 часа.

Пользовательские скрипты реагирования

Wazuh позволяет создавать собственные скрипты Active Response на любом языке программирования. Скрипт получает данные алерта через стандартный вход (STDIN) в формате JSON.

Формат входных данных

Скрипт получает JSON-объект со следующими полями:

{
  "version": 1,
  "origin": {
    "name": "my-custom-response",
    "module": "active-response"
  },
  "command": "add",
  "parameters": {
    "alert": {
      "rule": {
        "id": "5710",
        "level": 10,
        "description": "Multiple SSH authentication failures"
      },
      "data": {
        "srcip": "192.168.1.100"
      },
      "agent": {
        "id": "001",
        "name": "web-server"
      }
    }
  }
}

Поле command принимает значение add (выполнить действие) или delete (отменить действие для stateful-скриптов).

Пример скрипта на Bash

#!/bin/bash

LOCAL=$(dirname "$0")
LOG_FILE="/var/ossec/logs/active-responses.log"

read -r INPUT_JSON

COMMAND=$(echo "$INPUT_JSON" | jq -r '.command')
SRCIP=$(echo "$INPUT_JSON" | jq -r '.parameters.alert.data.srcip // empty')

if [ -z "$SRCIP" ]; then
    echo "$(date) - No source IP found" >> "$LOG_FILE"
    exit 1
fi

if [ "$COMMAND" = "add" ]; then
    echo "$(date) - Blocking IP: $SRCIP" >> "$LOG_FILE"
    iptables -A INPUT -s "$SRCIP" -j DROP
elif [ "$COMMAND" = "delete" ]; then
    echo "$(date) - Unblocking IP: $SRCIP" >> "$LOG_FILE"
    iptables -D INPUT -s "$SRCIP" -j DROP
fi

exit 0

Пример скрипта на Python

#!/usr/bin/env python3

import sys
import json
import datetime

LOG_FILE = "/var/ossec/logs/active-responses.log"

def log_message(message):
    timestamp = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    with open(LOG_FILE, "a") as f:
        f.write(f"{timestamp} - {message}\n")

def main():
    input_data = sys.stdin.readline().strip()
    if not input_data:
        log_message("No input received")
        sys.exit(1)

    try:
        alert = json.loads(input_data)
    except json.JSONDecodeError:
        log_message("Invalid JSON input")
        sys.exit(1)

    command = alert.get("command", "")
    srcip = alert.get("parameters", {}).get("alert", {}).get("data", {}).get("srcip", "")

    if not srcip:
        log_message("No source IP in alert")
        sys.exit(1)

    if command == "add":
        log_message(f"Custom action triggered for IP: {srcip}")
        # Custom remediation logic here
    elif command == "delete":
        log_message(f"Custom action reverted for IP: {srcip}")
        # Revert logic here

    sys.exit(0)

if __name__ == "__main__":
    main()

Развертывание пользовательского скрипта

  1. Разместите скрипт в /var/ossec/active-response/bin/ на агенте
  2. Установите права доступа: chmod 750 /var/ossec/active-response/bin/my-script.sh
  3. Владелец должен быть root:wazuh
  4. Добавьте блоки <command> и <active-response> в ossec.conf на сервере
  5. Перезапустите менеджер Wazuh для применения конфигурации

Реагирование по правилам

Привязка к конкретным правилам

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>31104,31105,31106</rules_id>
  <timeout>600</timeout>
</active-response>

Привязка к группе правил

<active-response>
  <command>host-deny</command>
  <location>local</location>
  <rules_group>web_attacks</rules_group>
  <timeout>1800</timeout>
</active-response>

Привязка к уровню критичности

<active-response>
  <command>disable-account</command>
  <location>local</location>
  <level>12</level>
  <timeout>0</timeout>
</active-response>

При <timeout>0</timeout> действие выполняется без автоматической отмены - учетная запись остается заблокированной до ручного вмешательства.

Тестирование Active Response

Проверка конфигурации

Перед развертыванием проверьте синтаксис конфигурации:

docker exec wazuh-manager /var/ossec/bin/wazuh-control reload

Ручной запуск скрипта

Для тестирования можно запустить скрипт реагирования вручную на агенте:

echo '{"version":1,"origin":{"name":"test","module":"active-response"},"command":"add","parameters":{"alert":{"data":{"srcip":"10.0.0.99"}}}}' | /var/ossec/active-response/bin/firewall-drop

Проверка журнала Active Response

Журнал выполнения скриптов реагирования находится на агенте:

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

Мониторинг через wazuh-logtest

Используйте wazuh-logtest для проверки срабатывания правил, к которым привязано реагирование:

docker exec -it wazuh-manager /var/ossec/bin/wazuh-logtest

Сравнение с другими платформами

ВозможностьWazuh Active ResponseSplunk SOARELK Watcher
Автоматическое реагированиеВстроено, на уровне агентаЧерез плейбуки и интеграцииЧерез actions (email, webhook)
Выполнение на конечной точкеДа, агент выполняет скриптЧерез коннекторы и приложенияНет, только серверные действия
Stateful с откатомДа, встроенный таймаутЧерез логику плейбукаНет
Пользовательские скриптыBash, Python, любой языкPython-плейбукиНет, только предустановленные actions
СтоимостьБесплатно (open source)Коммерческая лицензияБазовая версия бесплатна, расширенная платная
Сложность настройкиНизкая (XML-конфигурация)Высокая (визуальный редактор)Средняя (JSON/YAML)

Подробнее о правилах обнаружения: Архитектура Wazuh

Устранение неполадок

Скрипт не выполняется

  • Проверьте права доступа к скрипту: ls -la /var/ossec/active-response/bin/
  • Убедитесь, что скрипт имеет права 750 и владельца root:wazuh
  • Проверьте журнал /var/ossec/logs/ossec.log на наличие ошибок
  • Убедитесь, что имя в <executable> совпадает с именем файла скрипта

Блокировка не снимается автоматически

  • Проверьте, что <timeout_allowed>yes</timeout_allowed> указано в блоке <command>
  • Убедитесь, что значение <timeout> задано в блоке <active-response>
  • Проверьте, что скрипт корректно обрабатывает команду delete

Ложные срабатывания

  • Уточните условия срабатывания: используйте <rules_id> вместо <level>
  • Добавьте исключения через белые списки в правилах Wazuh
  • Увеличьте порог срабатывания в правиле обнаружения
  • Начните с длительного таймаута и сокращайте по мере отладки

Реагирование работает, но не логируется

  • Проверьте наличие и права на файл /var/ossec/logs/active-responses.log
  • Убедитесь, что скрипт записывает в лог результат выполнения

Подробнее об установке агентов: Установка агента Wazuh

Подробнее о компонентах Wazuh: Компоненты платформы

Last updated on