Тонкая настройка ноды Вебмониторэкс на основе NGINX¶

Директивы Вебмониторэкс¶

disable_acl¶

Позволяет выключить анализ источников запросов на совпадение с данными из списков IP-адресов. Для выключения необходимо передать в директиве значение on.

wallarm_acl_access_phase¶

Используется для увеличения производительности ноды Вебмониторэкс. Задействуйте директиву, если в черный список добавлено много IP-адресов (например, несколько страны), с которых отправляется большое количество запросов, создавая существенную нагрузку на CPU рабочей машины ноды.

По умолчанию фильтрующая нода блокирует запросы с IP-адресов из черного списка после анализа запросов на признаки атак. Включение wallarm_acl_access_phase on меняет операции местами, блокировка запросов при этом происходит сразу, без поиска атак. Это существенно снижает нагрузку на CPU ноды.

wallarm_api_conf¶

Задаёт путь к файлу node.yaml, содержащему реквизиты доступа к Вебмониторэкс API.

Пример:

wallarm_api_conf /etc/wallarm/node.yaml;

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

В API попадают только запросы с атаками. Запросы без атак не сохраняются.

Пример содержимого файла node.yaml:

# Ваши учетные данные для подключения к API

hostname: <some name>
uuid: <some uuid>
secret: <some secret>

# Параметры подключения к API (указанные ниже используются по умолчанию)

api:
  host: api.wallarm.ru
  port: 444
  ca_verify: true

wallarm_application¶

Уникальный идентификатор для обозначения защищенного приложения в Вычислительном кластере Вебмониторэкс. Значение может быть любым целым положительным числом, кроме 0.

Вы можете задать уникальные идентификаторы как для приложений, доступных на отдельных доменах, так и для путей одного домена. Например:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 1;

    location / {
            proxy_pass http://example.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;
    wallarm_application 2;

    location / {
            proxy_pass http://test.com;
            include proxy_params;
    }
}

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 ssl;

    ...

    wallarm_mode monitoring;

    location /login {
            proxy_pass http://example.com/login;
            include proxy_params;
            wallarm_application 3;
    }

    location /users {
            proxy_pass http://example.com/users;
            include proxy_params;
            wallarm_application 4;
    }
}

Подробнее о настройке приложений →

wallarm_block_page¶

Позволяет задать страницу и код ошибки, которые будут возвращены клиенту в ответ на заблокированный запрос.

Подробнее о настройке страницы блокировки и кода ошибки →

wallarm_block_page_add_dynamic_path¶

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

Подробнее о настройке страницы блокировки и кода ошибки →

wallarm_cache_path¶

Директория, в которой при запуске сервера NGINX будет создан каталог backup для хранения копии proton.db и файла индивидуального набора правил. У пользователя, от которого работает NGINX, должны быть права записи в эту директорию.

wallarm_custom_ruleset_path¶

Путь к индивидуальному набору правил, содержащему информацию о защищаемом веб‑приложении и настройках ноды.

wallarm_enable_libdetection¶

Включает дополнительную валидацию обнаруженных атак типа SQL‑инъекций с использованием алгоритмов библиотеки libdetection. Такой подход реализует двойное обнаружение атак и снижает количество ложных срабатываний.

По умолчанию анализ запросов с помощью libdetection отключен. Чтобы снизить количество ложных срабатываний, мы рекомендуем включить анализ (wallarm_enable_libdetection on).

Подробнее о работе и тестировании библиотеки libdetection →

Для корректного анализа тела запросов с помощью libdetection, необходимо включить буферизацию тела запроса клиента (proxy_request_buffering on).

Пример:

wallarm_enable_libdetection on;
proxy_request_buffering on;

wallarm_fallback¶

При значении on NGINX получает возможность войти в аварийный режим: если proton.db/файл индивидуального набора правил загрузить невозможно, данная настройка отключает модуль Вебмониторэкс для блоков http, server, location, для которых данные не загрузились. Сам NGINX продолжит работать.

wallarm_force¶

Задает анализ запросов и создание индивидуального набора правил на основе зеркалируемого трафика NGINX. Смотрите Анализ зеркалированного трафика с помощью NGINX.

wallarm_global_trainingset_path¶

wallarm_file_check_interval¶

Задает интервал для проверки новых записей в proton.db и индивидуальном наборе правил. Единица измерения интервала передается в суффиксе, как описано ниже:

• Не указывается для минут.

• s - для секунд.

• ms - для миллисекунд.

wallarm_instance¶

wallarm_key_path¶

Путь к лицензионному ключу Вебмониторэкс.

wallarm_local_trainingset_path¶

wallarm_mode¶

Режим фильтрации трафика:

• off

• monitoring

• safe_blocking

• block

На возможности работы wallarm_mode влияет значение директивы wallarm_mode_allow_override.

Подробная инструкция по настройке режима фильтрации →

wallarm_mode_allow_override¶

Управляет возможностью переопределять значение директивы wallarm_mode через правила, выгружаемые из Вычислительного кластера (индивидуальный набор правил):

• off - индивидуальный набор правил игнорируется.
• strict - посредством индивидуального набора правил можно только усилить режим работы.
• on - можно как усиливать, так и смягчать режим работы.

Например, если задано wallarm_mode monitoring и wallarm_mode_allow_override strict, то через Консоль управления Вебмониторэкс можно включить блокировку запросов, но нельзя полностью отключить их анализ.

Подробная инструкция по настройке режима фильтрации →

wallarm_parse_response¶

Флаг для включения / выключения анализа ответов приложения. Анализ ответов необходим для определения уязвимостей приложения с помощью пассивного обнаружения и активной проверки атак. Возможные значения: on, off соответственно.

wallarm_parse_websocket¶

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

Возможные значения:

• on: анализ сообщений включен.
• off: анализ сообщений не производится.

wallarm_parser_disable¶

Позволяет отключать парсеры.

В настоящее время поддерживаются следующие парсеры:

• cookie
• zlib
• htmljs
• json
• multipart
• base64
• percent
• urlenc
• xml

Пример

wallarm_parser_disable base64;
wallarm_parser_disable xml;
location /ab {
    wallarm_parser_disable json;
    wallarm_parser_disable base64;
    proxy_pass http://example.com;
}
location /zy {
    wallarm_parser_disable json;
    proxy_pass http://example.com;
}

wallarm_parse_html_response¶

Флаг для включения / выключения HTML‑парсера ответов приложения. Возможные значения: on, off соответственно.

Директива применяется, только если wallarm_parse_response on.

wallarm_stalled_worker_timeout¶

Ограничение времени обработки одного запроса рабочим процессом NGINX. Значение задается в секундах.

Если запрос обрабатывается дольше указанного времени, информация о рабочих процессах NGINX записывается в параметры статистики stalled_workers_count и stalled_workers.

wallarm_process_time_limit¶

Ограничение на время обработки одного запроса нодой Вебмониторэкс.

Если запрос обрабатывается дольше заданного лимита, в лог записывается ошибка и запрос помечается как атака overlimit_res. В зависимости от значения wallarm_process_time_limit_block, нода блокирует, регистрирует или игнорирует атаку.

Значение задается в миллисекундах, единица измерения не указывается. Например:

wallarm_process_time_limit 1200; # 1200 миллисекунд
wallarm_process_time_limit 2000; # 2000 миллисекунд

wallarm_process_time_limit_block¶

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

• off: запросы всегда пропускаются.

  Риск обхода защиты

  Значение off следует использовать с осторожностью, так как оно отключает защиту от атак overlimit_res.

  Рекомендуется устанавливать значение off только для определенных location, где это действительно необходимо и нет риска обхода защиты и эксплуатации уязвимостей. Например: для location, где происходит загрузка больших файлов.

  Категорически не рекомендуется устанавливать значение off глобально (на уровне контекста http).

• on: запросы всегда блокируются, но при wallarm_mode off пропускаются.

• attack: зависит от режима блокировки атаки, заданного в параметре wallarm_mode:
  • off: запросы не фильтруются.
  • monitoring: запросы пропускаются, но информация об атаке overlimit_res выгружается в Вычислительный кластер Вебмониторэкс и отображается в Консоли управления.
  • safe_blocking: запросы с IP-адресов из серого списка блокируются. Остальные запросы пропускаются, но информация об атаке overlimit_res выгружается в Вычислительный кластер Вебмониторэкс и отображается в Консоли управления.
  • block: запросы блокируются.

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

wallarm_request_memory_limit¶

Ограничение на максимальный объем памяти, который может быть использован в процессе анализа одного запроса.

При превышении значения анализ запроса будет прерван, пользователю вернется ошибка 500.

В значении можно использовать следующие суффиксы:

• k или K для указания размера в килобайтах

• m или M для указания размера в мегабайтах

• g или G для указания размера в гигабайтах

Значение 0 отключает ограничения.

По умолчанию ограничение отключено.

wallarm_proton_log_mask_master¶

Настройки отладочного логирования Вебмониторэкс при работе master-процесса NGINX.

wallarm_proton_log_mask_worker¶

Настройка отладочного логирования Вебмониторэкс при работе worker-процесса NGINX.

wallarm_protondb_path¶

Путь к файлу proton.db, содержащему глобальные настройки фильтрации запросов, не зависящие от структуры веб‑приложения.

wallarm_request_chunk_size¶

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

• k или K для указания размера в килобайтах

• m или M для указания размера в мегабайтах

• g или G для указания размера в гигабайтах

wallarm_tarantool_upstream¶

Директива для задания адресов серверов. При помощи директивы wallarm_tarantool_upstream вы можете распределять запросы между несколькими серверами постаналитки.

Пример использования:

upstream wallarm_tarantool {
    server 127.0.0.1:3313 max_fails=0 fail_timeout=0 max_conns=1;
    keepalive 1;
}

    # omitted

wallarm_tarantool_upstream wallarm_tarantool;

Смотрите также Модуль ngx_http_upstream_module.

wallarm_timeslice¶

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

Вы можете использовать суффиксы интервалов времени, описанные в документации NGINX, для задания различных единиц времени в качестве значения директивы.

wallarm_ts_request_memory_limit¶

Ограничение на максимальный объем памяти, который может быть использован одним экземпляром "proton.db + файл индивидуального набора правил".

Если в процессе обработки какого-то запроса общий объем памяти будет превышен, то пользователю вернется ошибка 500.

В значении можно использовать следующие суффиксы:

• k или K для указания размера в килобайтах

• m или M для указания размера в мегабайтах

• g или G для указания размера в гигабайтах

Значение 0 отключает ограничения.

wallarm_unpack_response¶

Флаг для включения / выключения распаковки сжатых данных, полученных в ответе приложения. Возможные значения: on, off соответственно.

Директива применяется, только если wallarm_parse_response on.

wallarm_upstream_backend¶

Задаёт способ отправки сериализованных запросов – запросы можно отправлять либо в Tarantool, либо в API.

Возможные значения директивы:

• tarantool

• api

Значения по умолчанию в зависимости от других директив:

• tarantool - в конфигурации нет директивы wallarm_api_conf.

• api - в конфигурации есть директива wallarm_api_conf, но отсутствует wallarm_tarantool_upstream.

  Обратите внимание

  Если в конфигурации одновременно присутствуют директивы wallarm_api_conf и wallarm_tarantool_upstream – возникнет ошибка конфигурации вида directive ambiguous wallarm upstream backend.

wallarm_upstream_connect_attempts¶

Задаёт количество немедленных попыток повторного соединения с Tarantool или Вебмониторэкс API.

Если соединение с Tarantool или API прерывается, то попытки повторного соединения не происходит, кроме случая, когда соединений больше не остаётся, а очередь сериализованных запросов не пуста.

wallarm_upstream_reconnect_interval¶

Задает интервал между попытками переподключения к Tarantool или Вебмониторэкс API после того, как количество неудачных попыток превысило порог wallarm_upstream_connect_attempts.

wallarm_upstream_connect_timeout¶

Задает время таймаута на подключение к Tarantool или Вебмониторэкс API.

wallarm_upstream_queue_limit¶

Задает лимит на количество сериализованных запросов.

Установка параметра wallarm_upstream_queue_limit и отсутствие параметра wallarm_upstream_queue_memory_limit означает отсутствие лимита по последнему.

wallarm_upstream_queue_memory_limit¶

Задает лимит на суммарный объём сериализованных запросов.

Установка параметра wallarm_upstream_queue_memory_limit и отсутствие параметра wallarm_upstream_queue_limit означает отсутствие лимита по последнему.