Обновление облачного образа ноды устаревшей версии¶

Инструкция описывает способ обновления образа WAF‑ноды 3.6 и ниже, развернутого в AWS или GCP, до версии 4.6.

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

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

В последней версии ноды значительно упрощена настройка ноды и повышено качество фильтрации трафика. Некоторые настройки ноды 3.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: Запустите новый инстанс с WAF‑нодой 4.4¶

Откройте образ WAF‑ноды Вебмониторэкс на маркетплейсе облачной платформы и перейдите к запуску:
- Amazon Marketplace
- GCP Marketplace
При запуске выполните следующие настройки:
- Выберите версию образа 4.4.x
- Для AWS выберите созданную группу безопасности в поле Security Group Settings
- Для AWS выберите название созданной пары ключей в поле Key Pair Settings
Подтвердите запуск инстанса.
Для GCP выполните настройку инстанса по инструкции.

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

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

Шаг 6: Подключите ноду к Вычислительному кластеру Вебмониторэкс¶

Подключитесь к инстансу с WAF‑нодой по SSH. Подробная инструкция по подключению к инстансу доступна в документации облачной платформы:
- AWS
- GCP
Создайте новую ноду Вебмониторэкс и подключите ее к Вычислительному кластеру по токену, как описано в инструкции для облачной платформы:
- AWS
- GCP

Шаг 7: Скопируйте настройки WAF‑ноды из предыдущей версии в новую версию¶

Скопируйте настройки обработки и проксирования запросов из следующих конфигурационных файлов предыдущей версии WAF‑ноды в файлы WAF‑ноды 4.6:
- /etc/nginx/nginx.conf и другие файлы с настройками NGINX
- /etc/nginx/conf.d/wallarm.conf с глобальными настройками WAF‑ноды
- /etc/nginx/conf.d/wallarm-status.conf с настройками сервиса мониторинга WAF‑ноды
  
  При копировании убедитесь, что содержимое файла соответствует рекомендуемой безопасной конфигурации.
- /etc/environment с переменными окружения
- /etc/default/wallarm-tarantool с настройками Tarantool
- Другие файлы с кастомными настройками обработки и проксирования запросов
Убедитесь, что в скопированных настройках нет устаревших параметров. В новой версии ноды изменились названия директив 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.

Переменная с устаревшим названием временно поддерживается, но в будущих релизах ее поддержка прекратится полностью. Логика переменной не изменилась.
Если вы обновляете ноду версии 2.18 и ниже, перенесите настройки белых и черных списков с предыдущей версии WAF-ноды на новую.
Обновите страницу блокировки Вебмониторэкс. В новой версии ноды изменился пример страницы блокировки Вебмониторэкс, &/usr/share/nginx/html/wallarm_blocked.html. Если вы используете эту страницу, скопируйте и отредактируйте ее по инструкции.

Подробная информация о работе с конфигурационными файлами NGINX доступна в официальной документации NGINX.

Список доступных директив для настройки WAF‑ноды доступен по ссылке.

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

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

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

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

Перейдите в Консоль управления Вебмониторэкс → Правила и откройте форму создания правила Настроить обработку атак типа overlimit_res.
Перенесите в правило настройки, заданные в директивах NGINX:
- Условие правила должно соответствовать блоку NGINX, в котором заданы директивы wallarm_process_time_limit и wallarm_process_time_limit_block.
- Лимит времени на обработку нодой одного запроса (в миллисекундах): значение wallarm_process_time_limit.
- Обработка запроса: рекомендуется Остановить обработку.
  
  Риск исчерпания памяти на сервере
  
  Установка высокого лимита и/или обработка запроса после превышения лимита могут привести к исчерпанию памяти на сервере и неконтролируемой по времени обработке запросов.
- Считать запрос атакой типа overlimit_res: рекомендуется Считать атакой.
  
  Если wallarm_process_time_limit_block off, Не считать атакой.
- Директива wallarm_process_time_limit_block не имеет аналога в форме создания правила в явном виде. Если в правиле задано действие Считать атакой, нода пропустит или заблокирует атаку типа overlimit_res в соответствии с общим режимом фильтрации:
  - В режиме мониторинга — перенаправит запрос в оригинальном виде на адрес приложения. Атаки, отправленные в обработанной и необработанной частях запроса, могут быть реализованы.
  - В режиме мягкой блокировки — заблокирует запрос, если он отправлен с IP-адреса из серого списка. Если с другого IP, перенаправит запрос в оригинальном виде на адрес приложения. Атаки, отправленные в обработанной и необработанной частях запроса, могут быть реализованы.
  - В режиме блокировки — заблокирует запрос.
Удалите директивы wallarm_process_time_limit и wallarm_process_time_limit_block из конфигурационного файла NGINX.

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

Шаг 9: Перезапустите NGINX¶

Перезапустите NGINX на виртуальной машине, чтобы применить настройки:

sudo systemctl restart nginx

Шаг 10: Протестируйте работу WAF‑ноды¶

Отправьте тестовый запрос с атакой Path Traversal на адрес защищенного ресурса:
```
curl http://localhost/etc/passwd
```
Перейдите в Консоль управления Вебмониторэкс → раздел События и убедитесь, что атака появилась в списке.

Шаг 11: Создайте образ виртуальной машины с WAF‑нодой 4.6 в AWS или GCP¶

Для создания образа виртуальной машины с WAF‑нодой 4.6, используйте инструкцию для AWS или GCP.

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

После успешной настройки и тестирования новой версии WAF‑ноды, удалите инстанс и виртуальную машину с предыдущей версией WAF‑ноды, используя консоль управления AWS или GCP.

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

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

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