Перейти к содержанию

Пользовательские правила детекта

В некоторых случаях может быть полезно добавить сигнатуру для детектирования атак вручную или создать так называемый виртуальный патч. Вебмониторэкс сам по себе не использует регулярные выражения для обнаружения атак, однако позволяет пользователям добавить дополнительные сигнатуры, основанные на регулярных выражениях.

Добавление нового правила детекта

Для этого надо создать правило Создать признак атаки на основе регулярного выражения и заполнить поля:

  • Регулярное выражение — регулярное выражение (сигнатура). Если значение указанного ниже параметра попадает под выражение, такой запрос детектируется как атака. Синтаксис и особенности регулярных выражений описаны в инструкции по добавлению правил.

    Изменение регулярного выражения в существующем правиле

    При обновлении регулярного выражения, которое также указано в правиле Отключить поиск атак на основе регулярного выражения, правило Отключить поиск атак на основе регулярного выражения для предыдущего выражения автоматически удалится.

    Чтобы отключить поиск атак по новому регулярному выражению, необходимо создать правило Отключить поиск атак на основе регулярного выражения с новым регулярным выражением.

  • Экспериментально — этот флаг позволяет безопасно проверить срабатывания регулярного выражения без блокировки запросов. Запросы не будут блокироваться даже при работе WAF‑ноды в режиме блокировки. Все срабатывания будут рассматриваться как обнаруженные экспериментальным методом и скрыты из списка событий по умолчанию. Чтобы найти экспериментальные атаки, введите выражение experimental attacks в поисковую строку;

  • Тип атаки — тип атаки, которая будет обнаружена при попадании значения параметра в запросе под регулярное выражение;

  • в этой части запроса — определяет, в каком параметре запроса детектировать соответствующие атаки.

Ограничения создания нового правила

Нельзя использовать переход на новую строку (Enter) после ввода регулярного выражения.

Нельзя использовать одинаковые регулярные выражения в разных point.

Правила, которые приводят к сбою в работе системы ,а также позволяющие выгрузить запросы клиента, удаляются системой автоматический. Для выгрузки запросов следует настроить работу с логами WAF ноды. Дополнительную информацию о работе с логами можно посмотреть в документации Nginx

Пример — блокировка всех запросов с некорректным заголовком X-Authentication

Если выполняются следующие условия:

  • приложение доступно на домене example.com;

  • приложение использует для аутентификации пользователей заголовок X-Authentication;

  • формат заголовка — 32 hex-символа.

Тогда для создания правила, запрещающего токены с неправильным форматом:

  1. Зайдите во вкладку Правила;

  2. Найдите ветку для example.com/**/*.* и нажмите Добавить правило;

  3. Выберите Создать признак атаки на основе регулярного выражения;

  4. Введите в поле Regex значение [^0-9a-f]|^.{33,}$|^.{0,31}$;

  5. Выберите для Атака тип Virtual patch;

  6. Выберите параметр Header и введите его значение X-AUTHENTICATION после в этой части запроса;

  7. Нажмите Создать.

Создание пользовательского правила детекта

Пример — Блокировать все запросы с параметрами тела class.module.classLoader.*

Один из способов эксплуатации уязвимости 0‑day в Spring Core Framework (Spring4Shell) — отправка вредоносного пэйлоада в следующих параметрах тела POST‑запроса:

  • class.module.classLoader.resources.context.parent.pipeline.first.pattern

  • class.module.classLoader.resources.context.parent.pipeline.first.suffix

  • class.module.classLoader.resources.context.parent.pipeline.first.directory

  • class.module.classLoader.resources.context.parent.pipeline.first.prefix

  • class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat

Если вы используете уязвимый Spring Core Framework и нода Вебмониторэкс работает в режиме мониторинга или мягкой блокировки, вы можете блокировать попытки эксплуатации уязвимости с помощью виртуального патча. Следующее правило будет блокировать все запросы с параметрами тела, приведенными выше:

Virtual patch for specific post params

Регулярное выражение:

(class[.]module[.]classLoader[.]resources[.]context[.]parent[.]pipeline[.]first[.])(pattern|suffix|directory|prefix|fileDateFormat)

Если нода Вебмониторэкс работает в режиме блокировки, такие попытки эксплуатации уязвимости блокируются по умолчанию.

Компонент Spring Cloud Function также имеет активную уязвимость с кодом CVE-2022-22963. Если вы используете уязвимый компонент и нода Вебмониторэкс работает в режиме мониторинга или мягкой блокировки, создайте дополнительный виртуальный патч.

Пример — Блокировать все запросы с заголовком CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION

Компонент Spring Cloud Function имеет активную уязвимость с кодом CVE-2022-22963. Злоумышленник может эксплуатировать ее, передав вредоносный пэйлоад в заголовке CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION или CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION.

Если вы используете уязвимый компонент и нода Вебмониторэкс работает в режиме мониторинга или мягкой блокировки, вы можете блокировать попытки эксплуатации уязвимости с помощью виртуального патча. Следующее правило будет блокировать все запросы с заголовком CLASS-CLOUD-FUNCTION-ROUTING-EXPRESSION:

Virtual patch for specific header

Блокировка запросов с заголовком CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION

Это правило не блокирует запросы с заголовком CLASS.CLOUD.FUNCTION.ROUTING-EXPRESSION, но NGINX по умолчанию отбрасывает запросы с таким заголовком как невалидные.

Если нода Вебмониторэкс работает в режиме блокировки, такие попытки эксплуатации уязвимости блокируются по умолчанию.

Компонент Spring Core Framework также имеет активную 0‑day уязвимость (Spring4Shell). Если вы используете уязвимый компонент и нода Вебмониторэкс работает в режиме мониторинга или мягкой блокировки, создайте дополнительный виртуальный патч.

Частичное отключение нового правила детекта

Если созданное правило необходимо частично отключить для отдельной ветки, то это можно сделать, создав правило Отключить поиск атак на основе регулярного выражения со следующими полями:

  • Регулярные выражения — ранее созданные регулярные выражения, которые необходимо игнорировать;

    Поведение правила при изменении регулярного выражения

    При обновлении регулярного выражения в правиле Создать признак атаки на основе регулярного выражения, правило Отключить поиск атак на основе регулярного выражения для предыдущего выражения автоматически удалится.

    Чтобы отключить поиск атак по новому регулярному выражению, необходимо создать правило Отключить поиск атак на основе регулярного выражения с новым регулярным выражением.

  • в этой части запроса — параметр, для которого нужно установить отключение правила.

Пример — разрешить неправильный заголовок X-Authentication для отдельного URL

Допустим, у вас есть скрипт example.com/test.php, на котором вы хотите изменить формат токенов.

Для создания соответствующего правила:

  1. Зайдите во вкладку Правила;

  2. Найдите или создайте ветку для example.com/test.php и нажмите Добавить правило;

  3. Выберите Отключить поиск атак на основе регулярного выражения;

  4. Выберите регулярное выражение, которое необходимо отключить;

  5. Выберите параметр Header и введите его значение X-AUTHENTICATION после в этой части запроса;

  6. Нажмите Создать.

Отключение пользовательского правила детекта