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

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

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

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

Для обновления Docker-образа версии 2.18 и ниже используйте отдельную инструкцию.

Требования¶

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

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

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

docker pull wallarm/node:3.6.2-1

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

docker stop <RUNNING_CONTAINER_NAME>

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

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

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

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

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

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

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

Шаг 5: Перенесите настройки обнаружения `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 из примонтированного конфигурационного файла.

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

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

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

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

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

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

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

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

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

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