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

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

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

Требования¶

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

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

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

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

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

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

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

docker pull wallarm/node:4.0.2-1

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

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

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

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

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

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

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

   

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

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

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

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

  wallarm_ts_request_memory_limit → wallarm_general_ruleset_memory_limit

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

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

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

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

Если вы обновляете ноду версии 3.4 или ниже, также переименуйте следующие директивы и параметры:

• NGINX: wallarm_instance → wallarm_application

• NGINX: wallarm_local_trainingset_path → wallarm_custom_ruleset_path

• NGINX: wallarm_global_trainingset_path → wallarm_protondb_path

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

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

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

1. Скопируйте и кастомизируйте новую страницу-пример по инструкции.

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

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

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

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

docker stop <RUNNING_CONTAINER_NAME>

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

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

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

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

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

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

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

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

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

   curl http://localhost/etc/passwd
   

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

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

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

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

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

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