Модуль 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
распространяется только на конкретный домен.
Примеры применений:
- Для отправки логов с 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.
- Передача оригинального 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.
-
На сервере создайте рабочую директорию для WebC:
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/master/dist/web-challenger/docker-compose.yml \ -O /opt/web-challenger/docker-compose.yml
-
Создайте службу для запуска WebC:
Скачайте файл сервиса:
wget https://docs.mitigator.ru/master/dist/docker-compose@.service \ -O /etc/systemd/system/docker-compose@.service
Активируйте службу:
systemctl enable docker-compose@web-challenger
-
Загрузите контейнер 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
нужно взять с любого из настроенных экземпляров, чтобы
дополнять его.
-
Создать приватный ключ (пример результата:
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
секцию с публичным ключом и адресами 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-пакеты. -
Отредактируйте в
.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
-
Запустите WebC:
docker-compose up -d
-
Проверьте связность между WebC и экземплярами MITIGATOR:
-
Выполните команду:
docker-compose exec gateway wg
-
Убедитесь в наличии handshake между всеми участниками VPN-сети.
-
Настройка в Web-интерфейсе
Настройка WebC выполняется через Web-интерфейс MITIGATOR.
В терминах системы MITIGATOR WebC — это проверяющий сервер. Группы проверяющих серверов создаются и настраиваются только администратором системы. После задания настроек проверяющих серверов администратор должен указать защищаемые доменные имена на вкладке «TLS-сертификаты» и выбрать группу проверяющих серверов, на которых будет проверяться трафик каждого домена. Для каждого доменного имени должны быть загружены TLS-сертификат и секретный ключ.
Более подробное описание настройки проверяющего сервера приводится во встроенной документации MITIGATOR.
После того как группа проверяющих серверов настроена и ассоциирована с защищаемым доменным именем, она может быть выбрана из списка в настройках контрмеры HCA.