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

Web Challenger (WebC) — это docker-контейнер, содержащий NGINX и модуль обработки запросов HTTP/HTTPS, работающий в паре с контрмерой HCA в MITIGATOR.

Возможности

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

  • Несколько обработчиков пакетов при работе в кластере могут работать с одним WebC.
  • Несколько WebC могут работать с одним обработчиком пакетов.
  • WebC может добавлять IP-адреса в таблицу аутентифицированных контрмеры HCA как через dataplane-сеть, так и по mgmt-сети.
  • Поддерживается сценарий работы WebC за NAT.
  • Сертификаты и секретные ключи защищаемых доменов могут загружаться не на WebC, а на load balancer за MITIGATOR.
  • Контрмера HCA поддерживает работу в режиме активной синхронизации.
  • Поддерживается возможность модификации конфигурации NGINX.
  • Возможность выбора режима челенджа для каждого защищаемого ресурса.
  • Предусмотрены возможности по балансировке нагрузки и повышению отказоустойчивости.

Активная синхронизация

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

Изменение конфигурации NGINX

Поддерживается возможность модификации конфигурации NGINX, работающего на WebC. Это позволяет расширять функциональность WebC стандартными средствами nginx, например для целей отправки логов с WebC или для передачи оригинального IP-адреса клиента при работе через балансеры и прокси.

Указанное в поле http распространяется на все защищаемые домены. Указанное в поле server распространяется только на конкретный домен.

Примеры применений:

  1. Для отправки логов с WebC, например на Logan.

Если задать формат логов

log_format myformat '$remote_addr - $remote_user [$time_local] "$request" $request_time $status $body_bytes_sent "$http_referer" "$http_user_agent"';

и параметры отправки,

access_log syslog:server=10.8.3.1:7201,tag=123456789abcdefg myformat;

то WebС будет отправлять логи в формате myformat на 10.8.3.1:7201 с токеном 123456789abcdefg.

  1. Передача оригинального IP-адреса клиента при работе через балансеры и прокси

В поле server задаются настройки для модуля ngx_http_realip_module.

real_ip_header X-Forwarded-For;
set_real_ip_from 192.168.1.0/24;
real_ip_recursive on;

В этом случае, если поступил запрос из подсети 192.168.1.0/24, то WebC аутентифицирует не тот IP-адрес, который был указан в src_ip, а указанный в http-заголовке X-Forwarded-For.

Выбор режима челенджа для каждого защищаемого ресурса

На вкладке «TLS-сертификаты» можно указать, какой режим проверки следует применять для конкретного защищаемого домена.

Режимы челенджа:

  • Redirect;
  • MetaRefresh (перенаправление выполняется браузером с помощью html-тега meta http-equiv="Refresh");
  • JsRefresh (перенаправление выполняется браузером в результате выполнения javascript кода).

Отказоустойчивость и балансировка

MITIGATOR позволяет перенаправлять трафик разных политик защиты на разные WebC, как для целей разделения защищаемых доменов и загрузки сертификатов только на нужные WebC, так и для целей балансировки нагрузки при защите одного домена в нескольких политиках защиты. Для этого в контрмере HCA разных политик нужно выбрать разные группы челенджеров.

MITIGATOR может выполнять периодический опрос WebC для проверки доступности по mgmt. В случае отказа контрмера HCA не будет направлять трафик на WebC, не ответивший на опрос. В сценарии работы с несколькими WebC, это позволяет повысить отказоустойчивость системы.

Балансировка трафика может также выполняться средствами стороннего балансировщика, расположенного за MITIGATOR.

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

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

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

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

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

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

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

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

  • WebC рекомендуется размещать на отдельном от MITIGATOR физическом сервере или виртуальной машине.
  • Запросы к WebC MITIGATOR отправляет во внутреннюю сеть. Сеть должна доставить их по назначению.
  • Для работы WebC необходимо, чтобы трафик от WebC поступал на интерфейсы внутренней сети MITIGATOR.
  • В настройках системы задаются группы, описывающие, какие WebC работают с какими обработчиками пакетов. Это позволяет при настройке контрмеры HCA выбрать одну из заранее настроенных групп.
  • В группе должны быть все обработчики пакетов кластера.
  • Групп может быть несколько, для тех же обработчиков другое сочетание WebC.
  • В контрмере HCA выбирается только одна группа.
  • Если WebC и интерфейс внутренней сети MITIGATOR находятся в одном сегменте L2-сети, то на WebC должен быть маршрут через MITIGATOR, а на MITIGATOR должен быть задан MAC-адрес сетевого интерфейса WebC.
  • Если WebC подключен к роутеру R2, то на R2 должен быть маршрут, по которому трафик от WebC должен доставляться до IPm int.
  • MITIGATOR может работать с WebC, находясь в режимах интеграции в сеть «L2-прозрачность» и «L3-роутер».
  • Настройка WebC осуществляется средствами 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 определяются реальной нагрузкой на WebC в RPS и могут быть оценены по производительности NGINX.

Установка

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

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

    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. Создайте службу для запуска WebC:

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

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

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

    systemctl enable docker-compose@web-challenger

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

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

      docker login docker.mitigator.ru

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

      docker-compose pull

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

Для того чтобы MITIGATOR мог взаимодействовать с WebC, необходимо настроить 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 секцию с публичным ключом и адресами WebC:

    Информация

    Рекомендуется выбирать для WebC адрес внутри 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 — адрес WebC внутри VPN. Должен быть уникальным среди всех участников VPN.

    192.0.2.1:4567 — внешний адрес WebC и настроенный выше порт. На этот адрес и порт другие экземпляры будут отправлять 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. Запустите WebC:

    docker-compose up -d

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

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

      docker-compose exec gateway wg

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

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

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

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

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

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