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

Обновление устаревших нод с мультиарендной опцией

Инструкция описывает способ обновления устаревших нод (версии 3.6 и ниже) с мультиарендной опцией до версии 4.6.

Требования

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

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

Шаг 1: Свяжитесь с командой поддержки Вебмониторэкс

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

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

Шаг 2: Следуйте стандартной процедуре обновления

Стандартные процедуры для разных вариантов установки ноды:

Создание ноды с опцией мультиарендности

При создании ноды выберите опцию Мультиарендная нода:

Multi-tenant node creation

Шаг 3: Адаптируйте настройку мультиарендности под новую версию

Измените конфигурацию тенантов и приложений, опираясь на пример:

  • Тенант обозначает клиента партнера Вебмониторэкс. У партнера 2 клиента.

  • Трафик с tenant1.com и tenant1-1.com связан с клиентом 1.

  • Трафик с tenant2.com связан с клиентом 2.

  • У клиента 1 есть 3 приложения:

    • tenant1.com/login
    • tenant1.com/users
    • tenant1-1.com

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

Изучите конфигурацию предыдущей версии

Конфигурация ноды 3.6 выглядела бы следующим образом:

server {
  server_name  tenant1.com;
  wallarm_application 20;
  ...
  location /login {
     wallarm_application 21;
     ...
  }
  location /users {
     wallarm_application 22;
     ...
  }

server {
  server_name  tenant1-1.com;
  wallarm_application 23;
  ...
}

server {
  server_name  tenant2.com;
  wallarm_application 24;
  ...
}
...
}

В приведенной конфигурации:

  • Трафик с tenant1.com и tenant1-1.com связан с клиентом 1 через идентификаторы 20 и 23, привязанные к этому клиенту при помощи запроса к API.

  • Подобные запросы к API должны быть выполнены для каждого идентификатора.

  • Тенанты и приложения являются отдельными сущностями, которые логично настраивать при помощи отдельных директив. Также более оптимальной представляется настройка, не включающая дополнительных действий, таких как отправка запросов к API. Вместо этого связи между тенантами и приложениями было бы логично обозначать непосредственно в конфигурационном файле. Эти возможности не предоставляются текущей конфигурацией и возникают с новым подходом 4.x, описанным ниже.

Изучите подход 4.x

В конфигурации ноды 4.x тенанты описываются при помощи UUID.

Чтобы обновить конфигурацию, выполните следующие действия:

  1. Получите UUID тенантов.

  2. Привяжите трафик к тенантам по UUID и настройте приложения.

Получите UUID тенантов

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

  1. Получите clientid, чтобы на следующем шаге узнать UUID, соотнесенные с ними:

    Скопируйте clientid из Консоли управления Вебмониторэкс:

    Селектор тенантов в Консоли управления

    1. Отправьте GET-запрос на роут /v2/partner_client:

      Пример запроса для отправки с собственного клиента

      curl -X GET \
'https://api.wallarm.ru/v2/partner_client?partnerid=PARTNER_ID' \
-H 'accept: application/json' \
-H 'x-wallarmapi-secret: YOUR_SECRET_KEY' \
-H 'x-wallarmapi-uuid: YOUR_UUID'

      Где PARTNER_ID – это идентификатор партнера, полученный на Шаге 2 процедуры создания тенанта.

      Пример ответа на запрос:

      {
"body": [
    {
        "id": 1,
        "partnerid": <PARTNER_ID>,
        "clientid": <CLIENT_1_ID>,
        "params": null
    },
    {
        "id": 3,
        "partnerid": <PARTNER_ID>,
        "clientid": <CLIENT_2_ID>,
        "params": null
    }
]
}

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

  2. Для получения UUID каждого тенанта, отправьте POST-запрос на роут v1/objects/client.

    Пример запроса для отправки с собственного клиента:

    curl -X POST \
https://api.wallarm.ru/v1/objects/client \
-H 'content-type: application/json' \
-H 'x-wallarmapi-secret: YOUR_SECRET_KEY' \
-H 'x-wallarmapi-uuid: YOUR_UUID' \
-d '{ "filter": { "id": [<CLIENT_1_ID>, <CLIENT_2_ID>]}}'

    Пример ответа на запрос:

    {
"status": 200,
"body": [
    {
        "id": <CLIENT_1_ID>,
        "name": "<CLIENT_1_NAME>",
        ...
        "uuid": "11111111-1111-1111-1111-111111111111",
        ...
    },
    {
        "id": <CLIENT_2_ID>,
        "name": "<CLIENT_2_NAME>",
        ...
        "uuid": "22222222-2222-2222-2222-222222222222",
        ...
    }
]
}

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

Привяжите трафик к тенантам по UUID и настройте приложения

В конфигурационном файле NGINX:

  1. Задайте директиву wallarm_partner_client_uuid, используя в качестве значения UUID тенантов.

  2. Задайте ID защищаемым приложениям при помощи директивы wallarm_application.

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

Пример:

server {
  server_name  tenant1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  ...
  location /login {
     wallarm_application 21;
     ...
  }
  location /users {
     wallarm_application 22;
     ...
  }

server {
  server_name  tenant1-1.com;
  wallarm_partner_client_uuid 11111111-1111-1111-1111-111111111111;
  wallarm_application 23;
  ...
}

server {
  server_name  tenant2.com;
  wallarm_partner_client_uuid 22222222-2222-2222-2222-222222222222;
  ...
}
...
}

В приведенной конфигурации:

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

  • Связи между тенантами и приложениями задаются через директивы wallarm_application в соответствующих блоках конфигурационного файла NGINX.

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

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

    curl http://localhost/etc/passwd

  2. Перейдите в Консоль управления Вебмониторэкс → раздел События и убедитесь, что атака появилась в списке.

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