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

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

disable_acl¶

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

wallarm_acl_access_phase¶

Если в директиве задано значение on, нода Вебмониторэкс будет блокировать запросы с IP-адресов из черного списка на фазе NGX_HTTP_ACCESS_PHASE. Это обозначает следующее:

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

  Это соответствует стандартному поведению такого типа списков и снижает нагрузку на CPU рабочей машины с нодой. Поэтому значение on рекомендуемое и установлено по умолчанию.

• Если wallarm_acl_access_phase off, нода Вебмониторэкс сначала анализирует все запросы на наличие атак и затем, только в режиме фильтрации block или safe_blocking, блокирует запросы с адресов из черного списка.

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

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

  Поведение ноды с wallarm_acl_access_phase off значительно увеличивает нагрузку на CPU рабочей машины с нодой.

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/Angie и путь до страницы блокировки также задан с помощью переменной. В остальных случаях директива не используется.

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

wallarm_cache_path¶

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

wallarm_custom_ruleset_path¶

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

wallarm_enable_libdetection¶

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

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

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

wallarm_fallback¶

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

wallarm_force¶

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

wallarm_general_ruleset_memory_limit¶

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

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

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

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

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

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

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

wallarm_global_trainingset_path¶

wallarm_file_check_interval¶

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

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

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

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

wallarm_instance¶

wallarm_key_path¶

Путь к закрытому ключу Вебмониторэкс, который используется для шифрования/дешифрования файлов proton.db и custom_ruleset.

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
• jwt
• zip

Пример

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_partner_client_uuid¶

Уникальный идентификатор тенанта для ноды Вебмониторэкс с мультиарендной опцией. Значение должно быть строкой в формате UUID, например:

• 11111111-1111-1111-1111-111111111111

• 123e4567-e89b-12d3-a456-426614174000

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

server {
  server_name  tenant1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  ...
  location /login {
     wallarm_application 21;
     ...
  }
  location /users {
     wallarm_application 22;
     ...
  }

server {
  server_name  tenant1-1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  wallarm_application 23;
  ...
}

server {
  server_name  tenant2.com;
  wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222;
  ...
}
...
}

В приведенной конфигурации:

• Тенант обозначает клиента партнера Вебмониторэкс.

• Трафик с tenant1.com и tenant1-1.com связан с клиентом 11111111-1111-1111-1111-111111111111.

• Трафик с tenant2.com связан с клиентом 22222222-2222-2222-2222-222222222222.

• У первого клиента есть 3 приложения, настроенных при помощи директивы wallarm_application:

  • tenant1.com/login – wallarm_application 21
  • tenant1.com/users – wallarm_application 22
  • tenant1-1.com – wallarm_application 23

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

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_stalled_worker_timeout¶

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

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

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¶

wallarm_unpack_response¶

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

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

wallarm_upstream_backend¶

Задаёт способ отправки сериализованных запросов в Tarantool.

Значение директивы:

• tarantool

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 означает отсутствие лимита по последнему.