Модуль challenge-response аутентификации для HTTP/HTTPS

Информация

Статья устарела и требует актуализации.

Web Challenger — это docker-контейнер, содержащий nginx и модуль обработки запросов HTTP/HTTPS, работающий в паре с контрмерой HCA в MITIGATOR. Контрмера HCA перенаправляет HTTP/HTTPS-запросы с неаутентифицированных IP-адресов на Web Challenger (проверяющий сервер), где выполняется проверка отправителя. Если проверка прошла успешно, IP-адрес отправителя добавляется в таблицу аутентифицированных контрмеры HCA. Также HCA может работать со сторонними устройствами L7-защиты.

Требования к внедрению

  • Web Challenger рекомендуется размещать на отдельном от MITIGATOR физическом сервере или виртуальной машине.
  • Запросы к Web Challenger MITIGATOR отправляет во внутреннюю сеть. Сеть должна доставить их по назначению.
  • Для работы Web Challenger необходимо, чтобы трафик от Web Challenger поступал на интерфейсы внутренней сети MITIGATOR.
  • При работе в кластере у каждого обработчика пакетов должен быть свой Web Challenger.
    • В настройках системы задаются группы, описывающие какие Web Challenger работают с какими обработчиками пакетов. Это позволяет при настройке контрмеры HCA выбрать одну из заранее настроенных групп.
    • В группе должны быть все обработчики пакетов кластера.
    • Групп может быть несколько, для тех же обработчиков другое сочетание Web Challenger.
    • В контрмере HCA выбирается только одна группа.
  • Если Web Challenger и интерфейс внутренней сети MITIGATOR находятся в одном сегменте L2-сети, то на Web Challenger должен быть маршрут через MITIGATOR, а на MITIGATOR должен быть задан MAC-адрес сетевого интерфейса Web Challenger.
  • Если Web Challenger подключен к роутеру R2, то на R2 должен быть маршрут, по которому трафик от Web Challenger должен доставляться до IPm int.
  • MITIGATOR может работать с Web Challenger, находясь в режимах интеграции в сеть «L2-прозрачность» и «L3-роутер».
  • Настройка Web Challenger осуществляется средствами MITIGATOR через VPN поверх mgmt-сети.

Системные требования

  • CPU: x86_64, 4 ядра, SSE 4.2.
  • RAM: 32+ ГБ.
  • SSD: 250 ГБ.
  • LAN: 1+ ГБ/с.
  • OS: Debian 10+, Ubuntu 20.04+.
  • MITIGATOR: v23.06.0 и выше.

Требования к CPU, RAM и LAN определяются реальной нагрузкой на Web Challenger в rps и могут быть оценены по производительности nginx.

Установка

Предполагается, что на сервер уже установлены Docker, docker-compose и wireguard-dkms.

  1. На сервере создайте рабочую директорию для Web Challenger:

    mkdir -p /opt/web-challenger
cd /opt/web-challenger

  2. Создайте файл .env следующего содержания:

    COMPOSE_FILE=docker-compose.yml

# MITIGATOR version
VERSION=vXX.XX

WEB_CHALLENGER_VPN_ADDRESS=X.X.X.X

    Здесь vXX.XX – версия MITIGATOR (например, v23.06 или v23.06.1).

  3. Скачайте docker-compose.yml:

    wget https://docs.mitigator.ru/master/dist/web-challenger/docker-compose.yml \
    -O /opt/web-challenger/docker-compose.yml

  4. Создайте службу для запуска Web Challenger:

    Скачайте файл сервиса:

    wget https://docs.mitigator.ru/master/dist/docker-compose@.service \
    -O /etc/systemd/system/docker-compose@.service

    Активируйте службу:

    systemctl enable docker-compose@web-challenger

  5. Загрузите контейнер Web Challenger:

    • Авторизуйтесь на docker.mitigator.ru

      docker login docker.mitigator.ru

    • Загрузите образы:

      docker-compose pull

Настройка взаимодействия с MITIGATOR по VPN

Для того чтобы MITIGATOR мог взаимодействовать с Web Challenger, необходимо настроить VPN. Процедура аналогична процедуре настройки VPN между экземплярами MITIGATOR с поправками на имена рабочей директории и переменных. Все файлы создаются в каталоге /opt/web-challenger.

Если уже настроено взаимодействие по VPN между экземплярами MITIGATOR, файл vpn-public.conf нужно взять с любого из настроенных экземпляров, чтобы дополнять его.

  1. Создать приватный ключ (пример результата: yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=):

    wg genkey

  2. Записать ключ в vpn-private.conf:

    [Interface]
ListenPort = 4567
PrivateKey = yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=

    Указанный порт 4567 должен быть открыт для UDP-трафика.

  3. Получить из приватного ключа публичный (пример результата: acfzxE6ZsiYE4jIqsBicOt7oT8ZuKhxBvuz0+6JxiEc=):

    echo 'yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=' | wg pubkey

  4. Добавить в vpn-public.conf секцию с публичным ключом и адресами Web Challenger:

    Информация

    Рекомендуется выбирать для Web Challenger адрес внутри VPN, отстоящий от адресов экземпляров, например 10.8.3.254. При этом все адреса должны быть внутри одной сети /24.

    [Peer]
PublicKey = acfzxE6ZsiYE4jIqsBicOt7oT8ZuKhxBvuz0+6JxiEc=
AllowedIPs = 10.8.3.254/32
Endpoint = 192.0.2.1:4567

    10.8.3.254 — адрес Web Challenger внутри VPN. Должен быть уникальным среди всех участников VPN.

    192.0.2.1:4567 — внешний адрес Web Challenger и настроенный выше порт. На этот адрес и порт другие экземпляры будут отправлять UDP-пакеты.

  5. Отредактируйте в .env адрес экземпляра внутри VPN:

    WEB_CHALLENGER_VPN_ADDRESS=10.8.3.254

    Он должен совпадать с настроенным в vpn-public.conf.

Настройка кластера после добавления экземпляра

После добавления нового экземпляра в файл vpn-public.conf нужно внести изменения у всех участников VPN.

На каждом из них нужно обновить конфигурацию VPN без перезапуска:

docker-compose exec gateway reconfigure

Запуск

  1. На сервере перейдите в рабочую директорию:

    cd /opt/web-challenger

  2. Запустите Web Challenger:

    docker-compose up -d

  3. Проверьте связность между Web Challenger и экземплярами MITIGATOR:

    • Выполните команду:

      docker-compose exec gateway wg

    • Убедитесь в наличии handshake между всеми участниками VPN-сети.

Настройка в Web-интерфейсе

Настройка Web Challenger выполняется через Web-интерфейс MITIGATOR.

В терминах системы MITIGATOR Web Challenger — это проверяющий сервер. Группы проверяющих серверов создаются и настраиваются только администратором системы. После задания настроек проверяющих серверов администратор должен указать защищаемые доменные имена на вкладке «TLS-сертификаты» и выбрать группу проверяющих серверов, на которых будет проверяться трафик каждого домена. Для каждого доменного имени должны быть загружены TLS-сертификат и секретный ключ.

Более подробное описание настройки проверяющего сервера приводится во встроенной документации MITIGATOR.

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

Использование HCA со сторонней L7-защитой

Контрмера HCA может работать не только с Web Challenger, но и со сторонними устройствами L7-защиты. В этом случае HCA выполняет функцию перенаправления трафика на L7-защиту. Для работы данной функциональности не нужны загрузка TLS-сертификатов или указание защищаемых доменных имен, но требуется соблюдать те же требования, что и для Web Challenger.

Работа в режиме аутентификации

При работе в режиме аутентификации контрмера HCA перенаправляет на устройство L7-защиты трафик неаутентифицированных клиентов. Устройство L7-защиты выполняет проверки и по REST API добавляет IP-адреса проверенных отправителей в таблицу аутентифицированных IP-адресов контрмеры HCA. Трафик от аутентифицированных отправителей начинает пропускаться контрмерой HCA на защищаемый сервер без обработки.

Следует учитывать, что из-за перенаправления, выполняемого контрмерой HCA, первая сессия с неаутентифицированного IP-адреса устанавливается клиентом не с защищаемым сервером, а с устройством L7-защиты.

Работа в режиме reverse-proxy

Трафик от всех пользователей всегда перенаправляется контрмерой HCA на устройство L7-защиты. Устройство L7-защиты выполняет проверки и по REST API добавляет IP-адреса отправителей, не прошедших проверку, в список блокировки контрмеры TBL.