Что нового в ноде Вебмониторэкс (при обновлении устаревших нод)¶

На этой странице перечислены изменения, доступные при обновлении ноды 4.2 и ниже до версии 4.6. Все изменения доступны как в клиентской ноде, так и в ноде с мультиарендной опцией версии 4.6.

Нода версии 4.2 и ниже больше не поддерживается

Обратите внимание, что нода версии 4.2 и ниже больше не поддерживается, поэтому мы рекомендуем обновить модули.

В последней версии ноды значительно упрощена настройка ноды и повышено качество фильтрации трафика. Некоторые настройки ноды 3.6 и ниже несовместимы с новой версией ноды. Перед обновлением компонентов внимательно изучите набор изменений и рекомендации по обновлению.

Критические изменения в наборе метрик¶

Начиная с версии 4.0, недоступны следующие метрики collectd:

curl_json-wallarm_nginx/gauge-requests — вы можете использовать аналогичную метрику, curl_json-wallarm_nginx/gauge-abnormal
curl_json-wallarm_nginx/gauge-attacks
curl_json-wallarm_nginx/gauge-blocked
curl_json-wallarm_nginx/gauge-time_detect
curl_json-wallarm_nginx/derive-requests
curl_json-wallarm_nginx/derive-attacks
curl_json-wallarm_nginx/derive-blocked
curl_json-wallarm_nginx/derive-abnormal
curl_json-wallarm_nginx/derive-requests_lost
curl_json-wallarm_nginx/derive-tnt_errors
curl_json-wallarm_nginx/derive-api_errors
curl_json-wallarm_nginx/derive-segfaults
curl_json-wallarm_nginx/derive-memfaults
curl_json-wallarm_nginx/derive-softmemfaults
curl_json-wallarm_nginx/derive-time_detect

Защита от IDOR/BOLA¶

Broken Object Level Authorization (BOLA), также известная как Insecure Direct Object References (IDOR), стала одной из самых распространенных уязвимостей API. В приложениях с уязвимостью IDOR/BOLA существует большая вероятность того, что конфиденциальная информация будут раскрыта злоумышленникам. Чтобы проэксплуатировать уязвимость, злоумышленнику достаточно подобрать реальный идентификатор какого-либо объекта и обратиться к нему через API. Отсутствие или некорректная проверка прав пользователя позволяет злоумышленникам получить доступ к запрашиваемому объекту и прочитать/изменить его данные. Целью атаки может стать любой эндпоинт API, который принимает идентификатор объекта.

Чтобы предотвратить эксплуатацию этой уязвимости, нода Вебмониторэкс 4.6 поддерживает триггер, который вы можете использовать для защиты своих эндпоинтов от BOLA-атаки. Триггер отслеживает количество запросов к указанному эндпоинту и регистрирует BOLA-атаки при превышении пороговых значений, указанных в триггере.

Обнаружение слабых JWT¶

JSON Web Token (JWT) — распространенный стандарт аутентификации для безопасного обмена данными между такими ресурсами, как API.

Компрометация JWT — частая цель злоумышленников, так как взлом механизмов аутентификации предоставляет им полный доступ к веб-приложениям и API. Чем слабее JWT, тем выше вероятность его компрометации.

Начиная с версии 4.4 вы можете настроить триггер Слабый JWT для регистрации уязвимостей в ваших JWT.

Если триггер включен, Вебмониторэкс регистрирует следующие уязвимости JWT:

JWT не зашифрованы — поле alg имеет значение none или отсутствует.
JWT подписаны скомпрометированным секретным ключом.

Проверка JSON Web Token на наличие атак¶

JSON Web Token (JWT) является одним из самых распространенных методов аутентификации, что делает его популярным инструментом для реализации атак (например, SQLi или RCE). К тому же, данные в JWT кодируются, поэтому находить атаки в его значении может быть сложно.

Нода Вебмониторэкс 4.6 находит JWT в любом элементе запроса, декодирует его и блокирует (в соответствующем режиме фильтрации) попытки атаки с помощью этого метода аутентификации.

Например, злоумышленник может закодировать в JWT вредоносный пэйлоад or+1=1--a-<script>prompt(1)</script> и передать этот JWT в заголовке запроса Authorization.

Нода Вебмониторэкс декодирует полученный JWT и обнаружит вредоносный пэйлоад, характерный для атак типа SQLi и XSS. Попытки атак будут зарегистрированы в списке событий в Консоли управления:

Поддерживаемые формы установки¶

Обновлена версия Community Ingress‑контроллера NGINX, на котором основан Ingress-контроллер Вебмониторэкс. Ранее использовалась версия 0.26.2, теперь — 1.5.1.

Инструкция по миграции на новую версию Ingress‑контроллера Вебмониторэкс →
Добавлена поддержка Debian 11.x Bullseye
Добавлена поддержка Ubuntu 22.04 LTS (jammy)
Прекращена поддержка Ubuntu 16.04 LTS (xenial)
Прекращена поддержка поддержка CentOS 6.x
Прекращена поддержка поддержка Debian 9.x
Прекращена поддержка поддержка Debian 10.x для установки ноды как динамического модуля для NGINX stable или NGINX Plus
Добавлена поддержка AlmaLinux, Rocky Linux и Oracle Linux 8.x в связи с прекращением поддержки CentOS 8.x

Пакеты ноды для альтернативной операционной системы будут храниться в репозитории CentOS 8.x.

Полный список поддерживаемых форм установок →

Требования к системе для установки ноды¶

Теперь нода поддерживает работу с белыми, черными и серыми списками IP‑адресов. Вы можете добавить в список как одиночные IP-адреса, так и страны или дата-центры.

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

Диапазоны IP-адресов, к которым необходимо обеспечить доступ:
- Диапазон 1
- Диапазон 2
Начиная с версии 4.0 фильтрующая нода выгружает данные в Вычислительный кластер Вебмониторэкс, используя адрес api.wallarm.ru:443 вместо api.wallarm.ru:444.

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

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

Единый метод регистрации нод в Вычислительном кластере Вебмониторэкс¶

Начиная с версии 4.0 на любой платформе установки можно использовать токен для регистрации ноды в Вычислительном кластере Вебмониторэкс. В предыдущих версиях на некоторых платформах требовалась пара "email пользователя-пароль".

Единый метод регистрации нод по токену обеспечивает более безопасное и быстрое подключение к Вычислительному кластеру:

Для синхронизации ноды и Вычислительного кластера не требуется поддерживать отдельные аккаунты пользователей с ролью Деплой.
Личные данные пользователей остаются в пределах Вычислительного кластера Вебмониторэкс.
Нет необходимости отключать механизм двухфакторной аутентификации, обеспечивающий защиту данных аккаунтов пользователей.
Можно использовать одну ноду для первичной обработки трафика и пост-анализа запросов, если они выполняются на разных серверах.

В связи с изменениями в способах регистрации нод, изменяются типы нод:

Для обозначения ноды с единым способом регистрации появился новый тип — нода Вебмониторэкс. Нода подключается к Вычислительному кластеру по токену с помощью скрипта register-node.

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

Миграция с облачной ноды на ноду Вебмониторэкс не требуется.
Локальная нода считается устаревшей. Локальная нода подключалась к Вычислительному кластеру по паре "email пользователя-пароль" с помощью скрипта addnode.

Теперь при установке модуля Вебмониторэкс для NGINX, NGINX Plus, Kong или в форме Docker-контейнера регистрация ноды будет выглядеть следующим образом:
1. Создать ноду в Консоли управления и скопировать сгенерированный токен.
2. Запустить на сервере скрипт register-node, используя скопированный токен.
  
  В Docker-контейнер токен передается в новой переменной окружения WALLARM_API_TOKEN.
Поддержка локальной ноды

В версии 4.4 нода локального типа считается устаревшей, но еще поддерживается. В версии 4.6 поддержка локальной ноды прекращена.

Рекомендуется заменить локальную ноду на ноду Вебмониторэкс. Инструкции по обновлению включают шаги по миграции на новый тип ноды.

Упрощенная конфигурация ноды Вебмониторэкс с мультиарендной опцией¶

Теперь при настройке ноды Вебмониторэкс с мультиарендной опцией тенанты и приложения задаются с помощью отдельных директив:

UUID тенанта задается в конфигурации с помощью новой директивы NGINX wallarm_partner_client_uuid.
Изменилось поведение директивы NGINX wallarm_application: теперь она используются только для задания уникальных идентификаторов защищаемых приложений.

Инструкция по обновлению ноды с мультиарендной опцией

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

Новый режим фильтрации трафика — мягкая блокировка.

Использование режима мягкой блокировки позволяет значительно снизить уровень ложных срабатываний на атаки за счет блокировки только тех запросов, которые содержат признаки атаки и отправлены с IP-адресов из серого списка.
Теперь нода анализирует источник запросов только в режиме мягкой или обычной блокировки.

В выключенном режиме (off) и режиме мониторинга (monitoring), нода:
- Не блокирует запросы, отправленные с IP‑адресов из черного списка.
- В режиме мониторинга выгружает в Вычислительный кластер Вебмониторэкс данные об атаках, отправленных с IP‑адресов из белого списка.

Подробнее о режимах работы ноды Вебмониторэкс →

Управление источниками запросов¶

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

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

Подробнее о миграции настроек черных списков →

Появились новые возможности для управления источниками запросов:

Полное управление белым, черным и серым списками IP-адресов через Консоль управления Вебмониторэкс.
Поддержка фильтрации трафика в режиме мягкой блокировки и поддержка серого списка IP-адресов.

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

Для автоматического добавления адресов в серый список вы можете использовать новый триггер Добавить IP в серый список.
Автоматическое добавление IP-адресов Сканера Вебмониторэкс в белый список. Теперь добавлять IP-адреса Сканера в белый список вручную не требуется.
Управление блокировкой групп IP-адресов, которые зарегистрированы в определенной стране, регионе, дата-центре, являются адресами узлов Tor или сети VPN.
Возможность выбрать приложения, к которым необходимо ограничить или разрешить доступ, при добавлении IP‑адресов в списки.
Новая директива NGINX. Данная настройка позволяет выключить анализ источников запросов на совпадение с данными из списков IP-адресов.

Подробнее о директиве NGINX disable_acl →

Подробнее о добавлении IP-адресов в белый, черный и серый списки →

ПО для построения структуры API¶

Теперь нода поставляется с ПО ПроAPI Структура, которое строит структуру ваших API на основе реального трафика приложений.

Подробнее о ПО ПроAPI Структура →

Двойная валидация вредоносных SQL‑инъекций¶

Начиная с версии 4.4, нода Вебмониторэкс валидирует обнаруженные SQL-инъекции дважды, чтобы снижать количество ложных срабатываний среди такого типа атак. Этот механизм реализован с помощью библиотеки libdetection, ноды 4.4 и выше используют ее для анализа атак по умолчанию.

Увеличение в количестве потребляемой памяти

При анализе атак с помощью библиотеки libdetection возможно увеличение объема памяти, потребляемой процессами NGINX и Вебмониторэкс, примерно на 10%.

Подробнее о механизме обнаружения атак →

Правило для настройки обнаружения атак типа `overlimit_res`¶

Теперь можно настраивать обнаружение атак типа overlimit_res с помощью специального правила в Консоли управления.

В связи с этим, устарели следующие директивы NGINX:

Директива NGINX wallarm_process_time_limit, которые использовались для установки собственного лимита времени на обработку одного запроса.

Теперь лимит задается с помощью правила.
Директива NGINX wallarm_process_time_limit_block, которые задавали режим блокировки атак типа overlimit_res.

Если создано правило, нода будет блокировать атаки типа overlimit_res в соответствии с общим режимом фильтрации.

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

Обновление страницы блокировки запросов¶

Обновлена страница блокировки /usr/share/nginx/html/wallarm_blocked.html. Обновлен внешний вид, добавлена возможность настроить логотип и почту для обращений.

Теперь по умолчанию страница выглядит следующим образом:

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

Новые параметры для базовой настройки ноды¶

Новые переменные окружения для Docker‑контейнера Вебмониторэкс на основе NGINX:
- WALLARM_APPLICATION. В переменной передается идентификатор для обозначения защищенного приложения в Вычислительном кластере Вебмониторэкс.
- NGINX_PORT. В переменной передается порт, который будет использовать NGINX внутри Docker-контейнера.
Инструкция по запуску Docker‑контейнера Вебмониторэкс на основе NGINX →
Новые параметры конфигурационного файла node.yaml для настройки синхронизации Вычислительного кластера Вебмониторэкс и ноды: api.local_host и api.local_port. С помощью этих параметров вы можете задать локальный IP-адрес и порт сетевого интерфейса, через который отправляются запросы к Вебмониторэкс API.

Полный набор параметров node.yaml для настройки синхронизации Вычислительного кластера Вебмониторэкс и ноды →

Отключение IPv6-соединений в Docker-контейнере на основе NGINX¶

Начиная с версии 4.2 Docker-контейнер Вебмониторэкс поддерживает новую переменную окружения DISABLE_IPV6. С помощью этой переменной вы можете отключить IPv6-соединения на веб-сервере NGINX, тогда сервер будет обрабатывать только IPv4-соединения.

Переименованные параметры, файлы и метрики¶

Изменились названия следующих директив NGINX:
- NGINX: wallarm_instance → wallarm_application
- NGINX: wallarm_local_trainingset_path → wallarm_custom_ruleset_path
- NGINX: wallarm_global_trainingset_path → wallarm_protondb_path
- NGINX: wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit
Параметры с устаревшими названиями временно поддерживаются, но в будущих релизах их поддержка прекратится полностью. Логика параметров не изменилась.
Изменилось название аннотации Ingress: nginx.ingress.kubernetes.io/wallarm-instance → nginx.ingress.kubernetes.io/wallarm-application.

Аннотация с устаревшим названием временно поддерживается, но в будущих релизах ее поддержка прекратится полностью. Логика аннотации не изменилась.
Изменилось название файла со сборкой индивидуальных правил: /etc/wallarm/lom → /etc/wallarm/custom_ruleset. Теперь на ноду выгружается файл только с новым названием.

В директиве NGINX wallarm_custom_ruleset_path изменилось значение по умолчанию, новое значение — /etc/wallarm/custom_ruleset.
Файл закрытого ключа /etc/wallarm/license.key переименован в /etc/wallarm/private.key. Начиная с версии ноды 4.0 по умолчанию используется новое имя закрытого ключа.
Изменилось название метрики collectd: gauge-lom_id → gauge-custom_ruleset_id.

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

Все метрики collectd →
Лог-файл /var/log/wallarm/addnode_loop.log в Docker-контейнере переименован в /var/log/wallarm/registernode_loop.log.

Параметры сервиса статистики¶

Сервис статистики теперь учитывает запросы, отправленные с IP‑адресов из черного списка. Количество таких запросов записывается в новый параметр blocked_by_acl, а также учитывается в параметрах requests и blocked.
Изменились названия параметров статистики ноды Вебмониторэкс:
- lom_apply_time → custom_ruleset_apply_time
- lom_id → custom_ruleset_id
Эндпоинт http://127.0.0.8/wallarm-status временно возвращает как параметры с устаревшими названиями, так и с новыми. В будущих релизах устаревшие параметры будут удалены.

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

Новые переменные для настройки расширенного логирования ноды¶

Изменились следующие переменные ноды для настройки расширенного логирования:

Переменная wallarm_request_time переименована в wallarm_request_cpu_time – время, потраченное CPU машины с фильтрующей нодой на выполнение запроса.

Переменная с предыдущим названием временно поддерживается, но в будущих релизах ее поддержка прекратится полностью. Логика переменной не изменилась.
Добавлена переменная wallarm_request_mono_time. Значение переменной складывается из суммы следующих показателей:
- Время, потраченное CPU машины с фильтрующей нодой на выполнение запроса.
- Время ожидания в очереди на выполнение.

Возможность блокировать запросы с IP-адресов из черного списка без поиска признаков атак¶

Добавлена новая директива NGINX wallarm_acl_access_phase, с помощью которой вы можете увеличить производительность ноды Вебмониторэкс следующим образом:

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

Процедура обновления¶

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