Перехват прокси и шлюзы безопасности: rate limiter, WAF, mTLS

Ботнет отправляет 10 000 запросов в секунду с 10 000 разных IP. Ваш per-IP rate limiter видит 1 запрос с IP — хорошо ниже лимита. Ваш WAF видит легитимные браузерные fingerprints. Сервер origin вот-вот будет перегружен. Шлюзы безопасности работают, но работают в одиночку, а не в связке. Этот урок рассматривает каждый шлюз, его стоимость и почему ни один из них не работает без остальных.

Шлюз 1: Маршрутизация обратного прокси по состоянию health

До того как SYN-пакет Бэа достигает origin, он может прийти к Патти — обратному прокси или CDN edge. Патти принимает решение о маршрутизации:

Путь при попадании в кэш. Патти проверяет кэш: «Есть ли у меня ответ для этого URL с совпадающими заголовками Vary?» Если да, она отвечает немедленно из кэша edge. TCP + TLS были согласованы с edge-сервером Патти (~20 мс RTT); origin никогда не видит запрос.

Путь при промахе кэша. Патти проверяет состояние origin. Health checks выполняются вне основного потока каждые несколько секунд — периодический GET /health или TCP-зонд к каждому серверу origin. Если origin здоров, Патти перенаправляет. Если нездоров (неудачная проверка, процесс упал, высокая частота 5xx), Патти маршрутизирует к резервному серверу в пуле. Это происходит на лету — SYN, приходящий во время failover, может быть направлен к другому серверу.

Connection draining. При удалении сервера из пула (деплой, уменьшение масштаба) Патти прекращает отправлять новые соединения на него, но позволяет существующим завершить ответ. Окно draining (обычно 30–60 с) гарантирует чистое завершение запросов в полёте до отключения сервера.

Шлюз 2: Rate limiter (token bucket)

Rate limiter устанавливает квоты: «Этот IP может отправить N запросов в секунду.» Реализация: алгоритм token bucket. У каждого IP есть корзина с ёмкостью C. Каждую секунду добавляется T токенов (до C). Каждый запрос потребляет один токен. Когда токены исчерпаны, новые запросы отбрасываются или возвращается 429 Too Many Requests.

Token bucket vs leaky bucket. Token bucket допускает всплески до ёмкости C. Leaky bucket вытекает с постоянной скоростью, предотвращая всплески. Большинство API rate limiter используют token bucket, потому что он допускает пакетных, но добросовестных клиентов (браузер, загружающий 30 подресурсов одновременно) без их наказания.

Проблема распределённого ботнета. Ботнет из 10 000 IP, каждый отправляет 0,9 req/s, отправляет суммарно 9 000 req/s. Лимит 2 req/s на IP пропускает их всех. Защита: добавить глобальный лимит одновременных соединений или адаптивное ограничение конкурентности на origin — когда количество запросов в полёте превышает мощность сервера, новые отклоняются быстрым 503 независимо от per-IP квоты.

Jitter при сбросе лимита. Если все клиенты одновременно достигают лимита и все токены сбрасываются в секунду 0, толпа бьёт по origin в t=1 с. Решение: рандомизировать смещения пополнения токенов на клиента (добавить ±10% jitter к окну пополнения). Сбросы лимита распределяются по клиентам, сглаживая нагрузку на origin.

Шлюз 3: WAF — Web Application Firewall

WAF проверяет контент на уровне приложения. Два режима:

На основе сигнатур (rule mode). OWASP ModSecurity Core Rule Set (CRS) определяет паттерны: SQL-инъекции (union select), XSS (<script>), path traversal (../), полезные нагрузки для конкретных CVE. Каждый запрос сопоставляется с сотнями правил. Работа на PL1–PL2 (Paranoia Level 1-2) балансирует ложные срабатывания и покрытие. PL4 (параноидальный) блокирует легитимный трафик, случайно совпадающий с агрессивными паттернами.

Аномальный. Базируется на нормальной форме запроса (скорость, user-agent, структура заголовков, энтропия нагрузки). Отклонения оцениваются. IP, отправляющий 100 req/min с fingerprint headless Chrome, который внезапно отправляет 3 000 req/min с идентичными заголовками, помечается как бот. Аномальное обнаружение нельзя обойти, зная правила.

Стоимость WAF. 1–5 мс на запрос для rule-based WAF на edge. Обоснование: устраняет широкие классы атак на уровне приложения, которые иначе потребовали бы дорогостоящих путей кода на уровне приложения или защиты запросов к БД.

Шлюз 4: mTLS — взаимная TLS для авторизации сервис-к-сервису

Обычный TLS аутентифицирует только сервер (Бэа доверяет Свену через сертификат Кары). mTLS аутентифицирует обе стороны. Во время TLS-рукопожатия Свен отправляет сообщение CertificateRequest. Бэа отправляет свой клиентский сертификат. Свен проверяет его против доверенного CA.

Где mTLS важен. Внутренние микросервисы в zero-trust сети. Если у вас есть payment service и user service в одном кластере Kubernetes, mTLS гарантирует, что user service не может имперсонировать payment service — даже если злоумышленник получает сетевой доступ внутри кластера.

SPIFFE. Фреймворк SPIFFE/SPIRE автоматизирует выдачу сертификатов для рабочих нагрузок: каждый сервис получает краткосрочный сертификат (SVID) от SPIFFE-сервера. Сертификаты ротируются автоматически (например, ежечасно). mTLS применяется service mesh (Istio, Linkerd) как sidecar proxy — код приложения не работает с TLS напрямую.

Стоимость mTLS. Один дополнительный round trip на новое соединение (запрос клиентского сертификата + отправка). 20–40 мс добавляется к задержке первого соединения. На тёплых соединениях (возобновление сессии) стоимость нулевая. Операционная стоимость: распределение, ротация и отзыв сертификатов должны быть автоматизированы — делать это вручную для сотен сервисов непрактично.