Обновление Docker‑образа на основе NGINX (для ноды устаревшей версии)¶

Инструкция описывает способ обновления Docker‑образа Вебмониторэкс устаревшей версии (3.6 или ниже) до версии 4.6.

Требования¶

• Доступ к аккаунту с ролью Администратор в Консоли управления Вебмониторэкс

• Доступ виртуальной машины к Вебмониторэкс API по адресу api.wallarm.ru. Убедитесь, что доступ не ограничен файерволом

Шаг 1: Сообщите об обновлении в техническую поддержку Вебмониторэкс (для ноды 2.18 и ниже)¶

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

Шаг 2: Отключите модуль активной проверки атак (для ноды 2.16 и ниже)¶

Если вы обновляете ноду версии 2.16 и ниже, отключите активную проверку атак в Консоли управления Вебмониторэкс → Сканер → Настройки.

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

Шаг 3: Измените порт Вебмониторэкс API¶

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

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

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

Шаг 4: Загрузите обновленный образ¶

docker pull wmx-public.gitlab.yandexcloud.net:5050/wmx-public/container-images/node:4.4.0-1

Шаг 5: Сгенерируйте токен для подключения к Вычислительному кластеру Вебмониторэкс¶

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

• До версии 4.x требовалось передавать имя пользователя и пароль в переменных DEPLOY_USER и DEPLOY_PASSWORD соответственно. С запуском контейнера нода создавалась в Вычислительном кластере автоматически.

• Теперь можно подключить ноду к Вычислительному кластеру по токену ноды, созданной в Вычислительном кластере заранее. Токен передается в контейнер в переменной WALLARM_API_TOKEN.

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

Чтобы создать ноду Вебмониторэкс и получить токен ноды:

1. Перейдите в Консоль управления → Ноды и создайте ноду.

   

2. Скопируйте сгенерированный токен.

Шаг 6: Перенесите настройки белых и черных списков с предыдущей версии WAF-ноды на новую (для ноды 2.18 и ниже)¶

Если вы обновляете ноду версии 2.18 и ниже, перенесите настройки белых и черных списков с предыдущей версии WAF-ноды на новую.

Шаг 7: Убедитесь, что в конфигурации образа нет устаревших элементов¶

В новых версиях образов Вебмониторэкс:

• Переменная окружения WALLARM_ACL_ENABLE больше не поддерживается.

• Изменились названия директив NGINX:

  • wallarm_instance → wallarm_application
  • wallarm_local_trainingset_path → wallarm_custom_ruleset_path
  • wallarm_global_trainingset_path → wallarm_protondb_path
  • wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit

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

• Переменная для расширенного логирования wallarm_request_time переименована в wallarm_request_cpu_time.

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

Шаг 8: Обновите страницу блокировки Вебмониторэкс (для образа на основе NGINX)¶

В новом образе ноды изменилась страница блокировки Вебмониторэкс, &/usr/share/nginx/html/wallarm_blocked.html. Теперь на странице по умолчанию не заданы логотип и почта.

Если вы используете страницу &/usr/share/nginx/html/wallarm_blocked.html:

1. Скопируйте содержимое новой страницы из нового образа.

2. Отредактируйте страницу по инструкции.

3. При запуске нового образа примонтируйте в Docker-контейнер конфигурационный файл NGINX и кастомизированную страницу блокировки Вебмониторэкс.

Шаг 9: Перенесите настройки обнаружения overlimit_res из директив в правило¶

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

Ранее настройка выполнялась с помощью:

• Директив NGINX wallarm_process_time_limit и wallarm_process_time_limit_block

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

Если вы задавали собственные настройки для обнаружения overlimit_res, рекомендуется перенести их в правило заранее:

1. Перейдите в Консоль управления Вебмониторэкс → Правила и откройте форму создания правила Настроить обработку атак типа overlimit_res.

2. Перенесите в правило настройки обнаружения overlimit_res, заданные в примонтированном конфигурационном файле:

   • Условие правила должно соответствовать блоку NGINX, в котором заданы директивы wallarm_process_time_limit и wallarm_process_time_limit_block или параметры process_time_limit и process_time_limit_block.
   • Лимит времени на обработку нодой одного запроса (в миллисекундах): значение wallarm_process_time_limit или process_time_limit.

   • Обработка запроса: рекомендуется Остановить обработку.

     Риск исчерпания памяти на сервере

     Установка высокого лимита и/или обработка запроса после превышения лимита могут привести к исчерпанию памяти на сервере и неконтролируемой по времени обработке запросов.

   • Считать запрос атакой типа overlimit_res: рекомендуется Считать атакой.

     Если в wallarm_process_time_limit_block или process_time_limit_block задано значение off, Не считать атакой.

   • Директива wallarm_process_time_limit_block (process_time_limit_block) не имеет аналога в форме создания правила в явном виде. Если в правиле задано действие Считать атакой, нода пропустит или заблокирует атаку типа overlimit_res в соответствии с общим режимом фильтрации:

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

3. Удалите директивы NGINX wallarm_process_time_limit, wallarm_process_time_limit_block process_time_limit, process_time_limit_block из примонтированного конфигурационного файла.

   Если заданы параметры и правило, поведение ноды будет соответствовать правилу.

Шаг 10: Остановите текущий контейнер¶

docker stop <RUNNING_CONTAINER_NAME>

Шаг 11: Запустите контейнер на основе нового образа¶

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

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

• Через переменные окружения для базовой настройки WAF‑ноды

  • Перейти к иструкции для Docker-контейнера на основе NGINX →
    

• В примонтированном конфигурационном файле для расширенной настройки WAF‑ноды

  • Перейти к иструкции для Docker-контейнера на основе NGINX →
    

Шаг 12: Адаптируйте настройку режимов фильтрации трафика¶

1. Убедитесь, что ожидаемое поведение следующих настроек соответствует изменениям в логике работы режимов off и monitoring:

   • Переменная окружения WALLARM_MODE или директива wallarm_mode Docker-контейнера на основе NGINX
     
   • Общее правило фильтрации в Консоли управления Вебмониторэкс
   • Правила, устанавливающие режим фильтрации трафика

2. Если ожидаемое поведение не соответствует изменениям в логике работы режимов off и monitoring, адаптируйте настройку режимов фильтрации.

Шаг 13: Протестируйте работу Вебмониторэкс¶

1. Отправьте тестовый запрос с атакой Path Traversal на адрес защищенного ресурса:

   curl http://localhost/etc/passwd
   

2. Убедитесь, что нода нового типа обрабатывает запрос так же, как его обрабатывала нода локального типа предыдущей версии. Например:

   • Блокирует запрос, если задан соответствующий режим фильтрации
   • Возвращает кастомизированную страницу блокировки, если она задана

3. Перейдите в секцию События и убедитесь, что:

   • Атака появилась в списке.
   • В информации о хите отображается UUID ноды Вебмониторэкс.
   

Шаг 14: Удалите WAF‑ноду предыдущей версии¶

Если развернутый образ версии 4.4 работает корректно, вы можете удалить WAF‑ноду предыдущей версии в Консоли управления Вебмониторэкс → секция Ноды.

Шаг 15: Включите модуль активной проверки атак (при обновлении ноды 2.16 и ниже)¶

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

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