Обновление Docker‑образа на основе NGINX (с версии 2.18 и ниже)¶

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

Использование данных существующей WAF‑ноды

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

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

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

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

Требования¶

Доступ к аккаунту с ролью Деплой или Администратор и отключенная двухфакторная аутентификация в Консоли управления Вебмониторэкс
Доступ виртуальной машины к Вебмониторэкс API по адресу api.wallarm.ru:444. Убедитесь, что доступ не ограничен файерволом

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

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

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

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

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

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

Образ на основе NGINX

docker pull wallarm/node:3.6.2-1

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

docker stop <RUNNING_CONTAINER_NAME>

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

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

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

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

Переменная окружения WALLARM_ACL_ENABLE больше не поддерживается.
Изменились названия директив NGINX:
- wallarm_instance → wallarm_application
- wallarm_local_trainingset_path → wallarm_custom_ruleset_path
- wallarm_global_trainingset_path → wallarm_protondb_path
Если параметры заданы явно в примонтированном конфигурационном файле, рекомендуем их переименовать. Параметры с устаревшими названиями временно поддерживаются, но в будущих релизах их поддержка прекратится полностью. Логика параметров не изменилась.

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

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

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

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

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

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

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

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

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

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

Перейдите в Консоль управления Вебмониторэкс → Правила и откройте форму создания правила Настроить обработку атак типа overlimit_res.
Перенесите в правило настройки обнаружения 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, перенаправит запрос в оригинальном виде на адрес приложения. Атаки, отправленные в обработанной и необработанной частях запроса, могут быть реализованы.
  - В режиме блокировки — заблокирует запрос.
Удалите директивы NGINX wallarm_process_time_limit, wallarm_process_time_limit_block process_time_limit, process_time_limit_block из примонтированного конфигурационного файла.

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

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

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

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

Через переменные окружения для базовой настройки WAF‑ноды
- Перейти к иструкции для Docker-контейнера на основе NGINX →
В примонтированном конфигурационном файле для расширенной настройки WAF‑ноды
- Перейти к иструкции для Docker-контейнера на основе NGINX →

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

Убедитесь, что ожидаемое поведение следующих настроек соответствует изменениям в логике работы режимов off и monitoring:
- Переменная окружения WALLARM_MODE или директива wallarm_mode Docker-контейнера на основе NGINX
- Общее правило фильтрации в Консоли управления Вебмониторэкс
- Правила, устанавливающие режим фильтрации трафика
Если ожидаемое поведение не соответствует изменениям в логике работы режимов off и monitoring, адаптируйте настройку режимов фильтрации.

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

Отправьте тестовый запрос с атаками SQLI и XSS на адрес защищенного ресурса:
```
curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'
```
Перейдите в Консоль управления Вебмониторэкс → секция События и убедитесь, что атаки появились в списке.

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

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

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

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

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