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

Информация

В настоящий момент модуль Web Challenger находится в режиме бета-тестирования.

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.

На сервере создайте рабочую директорию для Web Challenger:
```
mkdir -p /opt/web-challenger
cd /opt/web-challenger
```
Создайте файл .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).

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

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

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

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

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

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

systemctl enable docker-compose@web-challenger

Загрузите контейнер 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 нужно взять с любого из настроенных экземпляров, чтобы дополнять его.

Создать приватный ключ (пример результата: yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=):
```
wg genkey
```
Записать ключ в vpn-private.conf:
```
[Interface]
ListenPort = 4567
PrivateKey = yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=
```
Указанный порт 4567 должен быть открыт для UDP-трафика.
Получить из приватного ключа публичный (пример результата: acfzxE6ZsiYE4jIqsBicOt7oT8ZuKhxBvuz0+6JxiEc=):
```
echo 'yDPg5doavYH7fdD86nt+cOzSBL4znVZcrcrJwjY/Xmw=' | wg pubkey
```
Добавить в 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-пакеты.
Отредактируйте в .env адрес экземпляра внутри VPN:
```
WEB_CHALLENGER_VPN_ADDRESS=10.8.3.254
```
Он должен совпадать с настроенным в vpn-public.conf.

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

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

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

docker-compose exec gateway reconfigure

Запуск

На сервере перейдите в рабочую директорию:
```
cd /opt/web-challenger
```
Запустите Web Challenger:
```
docker-compose up -d
```
Проверьте связность между 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.