Перейти к содержанию

Обновление NGINX-модулей Вебмониторэкс устаревших версий

Инструкция описывает способ обновления NGINX‑модулей Вебмониторэкс устаревших версий (3.6 и ниже) до версии 4.8. Используйте этот способ, если нода установлена по следующим инструкциям:

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

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

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

Порядок обновления

  • Если модули WAF‑ноды и постаналитики установлены на одном сервере, выполните шаги ниже.

  • Если модули WAF‑ноды и постаналитики установлены на разных серверах, сначала обновите модуль постаналитики, затем выполните шаги ниже для модуля WAF‑ноды.

Требования

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

  • Доступ виртуальной машины к Вебмониторэкс 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: Обновите NGINX до последней стабильной версии

Обновите NGINX до последней стабильной версии, используя подходящую инструкцию:

DEB-дистрибутивы:

sudo apt update
sudo apt install nginx

RPM-дистрибутивы:

sudo yum update
sudo yum install nginx

Если NGINX установлен из репозитория Debian/CentOS, пропустите этот шаг. Версия NGINX будет обновлена позже вместе с модулями Вебмониторэкс.

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

Шаг 5: Подключите новый репозиторий Вебмониторэкс WAF

Отключите предыдущий репозиторий Вебмониторэкс WAF и подключите новый, используя команды для подходящей платформы.

CentOS

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.webmonitorx.ru/centos/wallarm-node/7/4.8/x86_64/wallarm-node-repo-4.8-0.el7.noarch.rpm

Поддержка CentOS 8.x прекращена

Поддержка CentOS 8.x прекращена. Вы можете установить ноду 4.8 на альтернативную операционную систему AlmaLinux, Rocky Linux или Oracle Linux 8.x:

sudo yum remove wallarm-node-repo
sudo yum clean all
sudo rpm -i https://repo.webmonitorx.ru/centos/wallarm-node/8/4.8/x86_64/wallarm-node-repo-4.8-0.el8.noarch.rpm

Debian и Ubuntu

  1. Откройте для редактирования файл /etc/apt/sources.list.d/wallarm.list:

    sudo vim /etc/apt/sources.list.d/wallarm.list

  2. Закомментируйте или удалите предыдущий адрес репозитория.

  3. Добавьте новый адрес репозитория:

    Используйте Debian 10.x (buster), только если [NGINX установлен из репозитория Debian/CentOS](../../installation/nginx/dynamic-module-from-distr.md). Начиная с ноды Вебмониторэкс 4.4 невозможно установить как модуль для NGINX stable, так как эти версии NGINX больше не поддерживают Debian 10.x.

deb http://repo.webmonitorx.ru/debian/wallarm-node buster/4.8/

    deb http://repo.webmonitorx.ru/debian/wallarm-node bullseye/4.8/

    deb http://repo.webmonitorx.ru/ubuntu/wallarm-node bionic/4.8/

    deb http://repo.webmonitorx.ru/ubuntu/wallarm-node focal/4.8/

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

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

Шаг 7: Обновите пакеты Вебмониторэкс WAF

WAF‑нода и постаналитика на одном сервере

  1. Выполните команду для обновления модулей WAF‑ноды и постаналитики:

    sudo apt update
sudo apt dist-upgrade

    Ошибка вида "signatures couldn't be verified"

    Если срок добавленных GPG-ключей истек, при обновлении пакетов возникнет ошибка вида:

    W: GPG error: https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.8/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

    Чтобы исправить ошибку, необходимо импортировать новые ключи для пакетов Вебмониторэкс и затем обновить пакеты. Используйте следующие команды:

    curl -fsSL https://repo.webmonitorx.ru/wmx.gpg \| sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

    sudo apt update
sudo apt dist-upgrade

    Ошибка вида "signatures couldn't be verified"

    Если срок добавленных GPG-ключей истек, при обновлении пакетов возникнет ошибка вида:

    W: GPG error: https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.8/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

    Чтобы исправить ошибку, необходимо импортировать новые ключи для пакетов Вебмониторэкс и затем обновить пакеты. Используйте следующие команды:

    curl -fsSL https://repo.webmonitorx.ru/wmx.gpg \| sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

    sudo yum update

    sudo yum update

  2. Если менеджер пакетов запросит подтверждение на перезапись конфигурационного файла /etc/cron.d/wallarm-node-nginx:

    1. Убедитесь, что миграция списков IP‑адресов выполнена.

    2. Введите Y для подтверждения перезаписи файла.

      Запрос появится, если вы изменяли конфигурационный файл /etc/cron.d/wallarm-node-nginx в предыдущих версиях. В новых версиях ноды изменилась логика работы списков IP‑адресов, поэтому содержимое конфигурационного файла /etc/cron.d/wallarm-node-nginx было обновлено. Для корректной работы черных списков IP‑адресов в новой версии необходимо использовать обновленный конфигурационный файл.

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

WAF‑нода и постаналитика на разных серверах

Порядок обновления модулей

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

  1. Обновите пакеты постаналитики.

  2. Обновите пакеты WAF‑ноды:

    sudo apt update
sudo apt dist-upgrade

    Ошибка вида "signatures couldn't be verified"

    Если срок добавленных GPG-ключей истек, при обновлении пакетов возникнет ошибка вида:

    W: GPG error: https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.8/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

    Чтобы исправить ошибку, необходимо импортировать новые ключи для пакетов Вебмониторэкс и затем обновить пакеты. Используйте следующие команды:

    curl -fsSL https://repo.webmonitorx.ru/wmx.gpg \| sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

    sudo apt update
sudo apt dist-upgrade

    Ошибка вида "signatures couldn't be verified"

    Если срок добавленных GPG-ключей истек, при обновлении пакетов возникнет ошибка вида:

    W: GPG error: https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.8/ Release:The following
signatures couldn't be verified because the public key is not available: NO_PUBKEY 1111FQQW999
E: The repository 'https://repo.webmonitorx.ru/ubuntu/webmonitorx-node focal/4.6/ Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

    Чтобы исправить ошибку, необходимо импортировать новые ключи для пакетов Вебмониторэкс и затем обновить пакеты. Используйте следующие команды:

    curl -fsSL https://repo.webmonitorx.ru/wmx.gpg \| sudo apt-key add -
sudo apt update
sudo apt dist-upgrade

    sudo yum update

    sudo yum update

  3. Если менеджер пакетов запросит подтверждение на перезапись конфигурационного файла /etc/cron.d/wallarm-node-nginx:

    1. Убедитесь, что миграция списков IP‑адресов выполнена.

    2. Введите Y для подтверждения перезаписи файла.

      Запрос появится, если вы изменяли конфигурационный файл /etc/cron.d/wallarm-node-nginx в предыдущих версиях. В новых версиях ноды изменилась логика работы списков IP‑адресов, поэтому содержимое конфигурационного файла /etc/cron.d/wallarm-node-nginx было обновлено. Для корректной работы черных списков IP‑адресов в новой версии необходимо использовать обновленный конфигурационный файл.

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

Шаг 8: Замените тип ноды

Установленная нода версии 3.6 или ниже имеет локальный тип. Начиная с версии 4.2, нода локального типа считается устаревшей, вместо нее доступен новый тип — нода Вебмониторэкс.

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

Если модуль постаналитики установлен на отдельный сервер

Если модули первичной обработки трафика и постаналитики установлены на разные серверы, рекомендуется регистрировать такие модули в Вычислительном кластере по одному токену ноды. Для каждого модуля в Консоли управления будет отображаться отдельный инстанс ноды. Например:

Node with several instances

При обновлении модуля постаналитики вы уже создали ноду нового типа. Для следующего обновления модулей ноды:

  1. Скопируйте токен ноды, созданной при обновлении модуля постаналитики.
  2. Перейдите к выполнению шага 4 из списка ниже.

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

  1. Убедитесь, что роль вашего пользователя в Консоли управления Вебмониторэкс — Администратор.

    Для этого перейдите к списку пользователей в Консоли управления и проверьте столбец Роль:

    Список пользователей в консоли Вебмониторэкс

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

    Вебмониторэкс node creation

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

  4. Временно остановите сервис NGINX на сервере с установленной нодой:

    sudo systemctl stop nginx

    sudo service nginx stop

    sudo systemctl stop nginx

    sudo systemctl stop nginx

    Приостановка NGINX позволит избежать риска некорректного подсчета RPS из-за смены типа ноды.

  5. Выполните скрипт register-node для запуска ноды Вебмониторэкс:

    sudo /usr/share/wallarm-common/register-node -t <WALLARM_API_TOKEN> -H api.wallarm.ru --force

    • <WALLARM_API_TOKEN> — токен ноды Вебмониторэкс.

      Если модуль постаналитики установлен на отдельный сервер

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

    • Флаг --force позволит перезаписать параметры для доступа ноды к Вычислительному кластеру, заданные в файле /etc/wallarm/node.yaml.

Шаг 9: Обновите страницу блокировки Вебмониторэкс

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

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

Шаг 10: Переименуйте параметры ноды

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

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

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

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

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

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

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

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

  2. Перенесите в правило настройки, заданные в директивах 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, перенаправит запрос в оригинальном виде на адрес приложения. Атаки, отправленные в обработанной и необработанной частях запроса, могут быть реализованы.
      • В режиме блокировки — заблокирует запрос.

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

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

Шаг 12: Обновите настройки расширенного логирования

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

  • Переменная wallarm_request_time переименована в wallarm_request_cpu_time

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

  • Добавлена переменная wallarm_request_mono_time – внесите ее в конфигурацию расширенного логирования, если в лог необходимо вывести сумму следующих показателей:

    • Время, потраченное CPU машины с фильтрующей нодой на выполнение запроса
    • Время ожидания в очереди на выполнение

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

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

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

Шаг 14: Обновите содержимое файла wallarm-status.conf

Измените содержимое файла /etc/nginx/conf.d/wallarm-status.conf до следующего вида:

server {
  listen 127.0.0.8:80;
  server_name localhost;

  allow 127.0.0.0/8;         # Доступ открыт только для loopback-адресов сервера с WAF‑нодой 
  deny all;

  wallarm_mode off;
  disable_acl "on";         # Проверка источников запросов отключена, IP-адреса из черного списка могут обратиться к сервису wallarm-status. https://docs.webmonitorx.ru/admin-ru/configure-parameters-ru/#disable_acl
  access_log off;

  location ~/wallarm-status$ {
    wallarm_status on;
  }
}

Подробнее о настройке сервиса статистики

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

sudo systemctl restart nginx

sudo service nginx restart

sudo systemctl restart nginx

sudo systemctl restart nginx

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

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

    curl http://localhost/etc/passwd

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

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

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

    Атаки в интерфейсе

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

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

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

Шаг 18: Удалите локальную ноду предыдущей версии

После успешного тестирования ноды новой версии, вернитесь в секцию Ноды в Консоли управления и удалите локальную ноду предыдущей версии.

Если модуль постаналитики установлен на отдельный сервер, также удалите локальную ноду постаналитики предыдущей версии.

Настройка

Модули Вебмониторэкс WAF обновлены до версии 4.8. Остальные настройки Вебмониторэкс WAF из предыдущей версии применятся к новой версии автоматически. Чтобы применить дополнительные настройки, используйте доступные директивы.

Частые настройки: