Определение IP‑адреса клиента¶

Вебмониторэкс использует IP‑адрес клиента для отображения источника атак в Консоли управления, для списков IP, блокировки сессий и обнаружения поведенческих атак. Если Ingress‑контроллер определяет адрес неправильно, в Консоли управления в качестве источника отображается адрес балансировщика или внутренний адрес кластера (например, 10.42.0.1), а блокировка по IP затрагивает всех клиентов сразу.

Ingress‑контроллер определяет адрес клиента по TCP‑соединению. Адрес может подменяться на двух этапах:

Внутри кластера. Kubernetes по умолчанию перенаправляет трафик Service типа LoadBalancer или NodePort через любой узел кластера и заменяет адрес источника на адрес узла (SNAT).
На внешнем балансировщике. Балансировщик уровня L7 (или L4 в режиме прокси) устанавливает собственное соединение с Ingress‑контроллером. Адрес клиента он передает в HTTP‑заголовке (обычно X-Forwarded-For) или по протоколу PROXY.

Шаг 1: Сохранение адреса внутри кластера¶

Задайте для Service Ingress‑контроллера политику externalTrafficPolicy: Local:

controller:
  service:
    externalTrafficPolicy: Local

С этой политикой трафик направляется только на узлы, где работают pod'ы Ingress‑контроллера, и адрес источника сохраняется. Балансировщик облачного провайдера проверяет доступность узлов и направляет трафик только на узлы с pod'ами контроллера.

Если трафик поступает на Ingress‑контроллер напрямую (без внешнего балансировщика‑прокси), этого шага достаточно.

Запросы изнутри кластера

Запросы, отправленные с узла кластера на внешний адрес Ingress‑контроллера, всегда отображаются с внутренним адресом (например, 10.42.0.1). Проверяйте определение адреса клиента запросами извне кластера.

Шаг 2: Адрес клиента за балансировщиком¶

Если перед Ingress‑контроллером стоит балансировщик, который устанавливает собственное соединение, настройте получение адреса клиента от балансировщика. Способ зависит от того, как балансировщик передает адрес: изучите документацию на ваш балансировщик.

Доверенные адреса

Ingress‑контроллер доверяет заголовку или протоколу PROXY только для соединений с адресов из set-real-ip-from. Укажите в нем только адреса ваших балансировщиков. Если указать 0.0.0.0/0, любой клиент сможет подставить произвольный IP‑адрес в заголовок, обойти блокировку по IP или заблокировать чужой адрес.

Заголовок X-Forwarded-ForПротокол PROXY

controller:
  config:
    entries:
      real-ip-header: X-Forwarded-For
      set-real-ip-from: "192.0.2.0/24,198.51.100.10"
      real-ip-recursive: "true"

real-ip-header — заголовок с адресом клиента;
set-real-ip-from — адреса и подсети балансировщиков через запятую;
real-ip-recursive — если запрос прошел через несколько доверенных прокси, использовать последний недоверенный адрес из заголовка.

controller:
  config:
    entries:
      proxy-protocol: "true"
      real-ip-header: proxy_protocol
      set-real-ip-from: "192.0.2.0/24"

Включайте протокол PROXY одновременно на балансировщике и в Ingress‑контроллере: если он включен только с одной стороны, соединения не будут устанавливаться.

Отличия от предыдущей версии Ingress‑контроллера

В предыдущей версии Ingress‑контроллера (на базе ingress-nginx) использовались ключи enable-real-ip, forwarded-for-header и proxy-real-ip-cidr. В новой версии используются ключи real-ip-header, set-real-ip-from и real-ip-recursive, а настройки задаются в разделе controller.config.entries.

Проверка¶

Отправьте тестовую атаку с компьютера за пределами кластера:
```
curl "https://app.example.com/?q=<script>alert(1)</script>"
```
В Консоли управления Вебмониторэкс → События источником атаки должен быть внешний IP‑адрес вашего компьютера.

Адрес клиента также указан в первом поле журнала доступа NGINX:

kubectl -n <KUBERNETES_NAMESPACE> logs deploy/wmx-ingress-controller -c wmx-ingress --tail=5