Аномалии доступа в Wazuh: правила для входов, привилегий и изменения групп

Управление доступом без мониторинга — это набор решений, которые никто не проверяет на практике. Администратора добавили в группу доменных админов в три часа ночи, служебная учётная запись вошла с рабочей станции, на сервере появился новый локальный пользователь: если об этом узнают на следующей проверке, злоумышленник уже закрепился. Нужно, чтобы система сама замечала такие события. Ниже какие события собирать, как написать правила в Wazuh для самых важных ситуаций, как проверить, что правила работают, и что делать при срабатывании.

Подключение источников и приём журналов: журналы сетевых средств в Wazuh. Проверка, что события доходят: доставка событий. Основные правила: правила обнаружения атак на Linux. Что делать с оповещением: классификация инцидентов.

Что хотим получить

Правила должны ловить немногое, но важное. Каждое оповещение имеет владельца и описанное действие, иначе его перестают читать через неделю. Начните с четырёх-пяти сценариев и добавляйте новые по мере необходимости.

Какие события собирать

Журнал безопасности Windows нужно включить на аудит: в политике «Advanced Audit Policy Configuration» включите категории Account Logon, Logon/Logoff, Account Management и Privilege Use с записью успехов и отказов. Без этого событий в журнале просто нет. Агент Wazuh на Windows читает канал Security по умолчанию. Контроллеры домена должны быть источниками обязательно: на них регистрируются изменения учётных записей и групп.

Что уже есть из коробки

Wazuh содержит готовые правила для множества сценариев: подбор паролей SSH, неудачные входы в Windows, добавление пользователей в Linux, блокировки учётных записей. Прежде чем писать своё, посмотрите, что срабатывает по умолчанию: в интерфейсе откройте раздел событий безопасности и отфильтруйте по группам authentication_failed, adduser, windows. Своё стоит писать только для ситуаций, специфичных для вас: имена ваших привилегированных групп, часы работы, служебные записи.

Шаг 1. Собственные правила

Правила лежат в /var/ossec/etc/rules/local_rules.xml, номера от 100000. Ниже три правила, которые закрывают основные сценарии.

<group name="local,windows,access,">

  <!-- 1. Изменён состав привилегированной группы -->
  <rule id="100200" level="12">
    <if_group>windows</if_group>
    <field name="win.system.eventID">^4728$|^4732$|^4756$</field>
    <field name="win.eventdata.targetUserName">^Domain Admins$|^Enterprise Admins$|^Administrators$|^Schema Admins$</field>
    <description>Изменён состав привилегированной группы $(win.eventdata.targetUserName): добавлен $(win.eventdata.memberName)</description>
    <mitre><id>T1098</id></mitre>
  </rule>

  <!-- 2. Ночной вход административной учётной записи (имена вида adm-...) -->
  <rule id="100201" level="10">
    <if_group>authentication_success</if_group>
    <field name="win.eventdata.targetUserName">^adm-</field>
    <time>10 pm - 6 am</time>
    <description>Ночной вход административной учётной записи $(win.eventdata.targetUserName) на $(win.system.computer)</description>
  </rule>

  <!-- 3. Создана новая учётная запись -->
  <rule id="100202" level="8">
    <if_group>windows</if_group>
    <field name="win.system.eventID">^4720$</field>
    <description>Создана учётная запись $(win.eventdata.targetUserName) пользователем $(win.eventdata.subjectUserName)</description>
  </rule>

</group>

Что делает каждое правило. Первое срабатывает на добавление в группы, дающие полный контроль над доменом, и это событие всегда должно иметь заявку. Второе ловит работу администраторов вне часов, пригодится как для украденных записей, так и для обычной ночной работы (для неё обычно есть заявка). Третье фиксирует новые учётные записи для сверки с кадровым списком. Для Linux пригодятся встроенные правила на создание пользователей и вход root, а имена ваших групп подставляйте в регулярные выражения. Числа часов и имена групп подберите под себя: правило с ночными часами зависит от часового пояса сервера Wazuh.

Шаг 2. Подбор паролей и блокировки

Для множественных неудачных входов с одного адреса используйте встроенную группу правил для Windows и SSH, они уже содержат пороги. Если нужно отдельно оповещать о блокировках учётных записей (событие 4740):

<rule id="100203" level="7">
  <if_group>windows</if_group>
  <field name="win.system.eventID">^4740$</field>
  <description>Заблокирована учётная запись $(win.eventdata.targetUserName)</description>
</rule>

<rule id="100204" level="10" frequency="5" timeframe="600">
  <if_matched_sid>100203</if_matched_sid>
  <description>Пять блокировок учётных записей за десять минут: возможен подбор паролей</description>
</rule>

Ожидаемо: единичные блокировки дают событие низкого уровня, серия — оповещение. Одна блокировка обычно значит забытый пароль, пять подряд — атаку. Так же можно настроить реакцию на подбор: блокировать адрес на экране автоматически через активный ответ (firewall-drop). Включайте её осторожно и только для внешних адресов: слишком чувствительное правило заблокирует вашего же сотрудника.

Шаг 3. Проверка правил

Прежде чем перезапускать менеджер, проверьте синтаксис и поведение. Сначала проверка конфигурации:

sudo /var/ossec/bin/wazuh-analysisd -t
sudo systemctl restart wazuh-manager

Ожидаемо: проверка завершается без ошибок. Затем на тестовой машине создайте событие: например, добавьте тестового пользователя в тестовую привилегированную группу (на тестовом домене, не на боевом) и проверьте, что в интерфейсе появилось оповещение с номером правила 100200. Для проверки на готовом событии: включите на время сохранение всех событий в формате JSON (<logall_json>yes</logall_json>), найдите событие в /var/ossec/logs/archives/archives.json и передайте его в wazuh-logtest. Выключите сохранение всех событий после проверки: оно быстро заполняет диск.

Шаг 4. Оповещение и реакция

Оповещение, не дошедшее до человека, не работает. Направьте оповещения уровня 10 и выше ответственному: письмом или в мессенджер (оповещения в Wazuh) и опишите, что делать по каждому правилу.

Порядок оформления инцидента: карточка инцидента, внутренние уведомления. Каждое оповещение должно заканчиваться записью: что было, что решили. Через месяц такие записи показывают, какие правила шумят, а какие приносят пользу.

Недельный обзор

Раз в неделю смотрите сводку по событиям доступа: сколько раз менялись привилегированные группы, сколько создано и отключено учётных записей, какие учётные записи чаще всего блокируются. Сравнивайте с заявками и кадрами: любое расхождение — это вопрос. Простая выборка с сервера Wazuh по оповещениям правил этой группы:

sudo jq -r 'select(.rule.id=="100200" or .rule.id=="100202") | [.timestamp, .rule.id, .rule.description] | @tsv' /var/ossec/logs/alerts/alerts.json | tail -n 20

Ожидаемо: последние оповещения с временем и описанием. Отправляйте эти данные в систему отчётности для руководителя: метрики ИБ.

Какие артефакты хранить

Диагностика

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

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

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

1. Тестовое добавление участника в привилегированную группу порождает оповещение в течение минуты.
2. Тестовый вход административной учётной записи ночью (в тестовой среде) вызывает правило ночного входа.
3. Оповещения доходят до ответственного, и он знает, что делать.
4. В архиве есть примеры реальных разборов оповещений за последний месяц.

Источники

• Wazuh, синтаксис правил: documentation.wazuh.com.
• Microsoft Learn, события безопасности Windows (4720, 4728, 4732, 4740): learn.microsoft.com.
• CIS Control 8, управление журналами аудита: cisecurity.org/controls.