WAF, межсетевые экраны, mTLS и HSTS

Ваш межсетевой экран блокирует сканирование портов и явный мусор. Но злоумышленник отправляет валидные HTTP-запросы на порт 443. Межсетевой экран пропускает их все — он не видит внутрь зашифрованного TLS-пэйлоада. Для атак на прикладном уровне нужен другой инструмент, понимающий HTTP: WAF.

Межсетевые экраны против WAF: фундаментальное различие. Межсетевой экран (L3/L4) проверяет IP- и TCP-заголовки: IP-адрес источника, порт назначения, TCP-флаги. Он блокирует сканирование портов, подделку IP и нарушения протокола. Он не видит внутрь зашифрованных HTTPS-пэйлоадов. Web Application Firewall (WAF, L7) проверяет содержимое HTTP-запроса/ответа после завершения TLS: заголовки, параметры запросов, тела запросов — сопоставляя с известными паттернами атак (SQL-инъекция, XSS, обход пути). WAF должен видеть открытый текст для инспекции, поэтому он завершает TLS на edge или располагается на origin за TLS-терминацией. Оба необходимы: межсетевой экран останавливает сетевой мусор, WAF — атаки на прикладном уровне.

Режимы обнаружения WAF. Сигнатурный: сопоставление с базой известных паттернов атак. OWASP ModSecurity Core Rule Set (CRS) содержит паттерны вроде union select (SQL-инъекция), <script> (XSS) и ../../../etc/passwd (обход пути). Быстрый, с низким числом ложных срабатываний на известных паттернах, но пропускает zero-day и обфусцированные варианты (например, un/**/ion select).

Аномальный/ML-based: моделирует нормальный трафик, помечает статистические выбросы. Обнаруживает новые атаки, но требует настройки — слишком строгий блокирует легитимных пользователей, слишком мягкий пропускает атаки.

Аномальное скорирование OWASP CRS. Каждое правило в OWASP CRS назначает оценку (1–8 баллов). Запрос блокируется при суммарной оценке >= 5. Уровни паранойи (PL1–PL4) контролируют количество активных правил: PL1 — разрешительный (меньше ложных срабатываний, пропускает часть атак); PL4 — строгий (блокирует больше, но и больше легитимных пользователей).

Настройка WAF в production. Начните с PL1 в режиме обнаружения (логировать и оповещать, не блокировать) на 1–2 недели. Соберите базовые метрики: распределение аномальных оценок на реальном трафике, попадания по категориям правил. Затем повышайте уровень паранойи и наблюдайте за частотой ложных срабатываний. Если ложные срабатывания превысят допустимое значение, настройте правила: добавьте в белый список известные ложные срабатывания, скорректируйте веса или исключите низкоточные правила. Цель: блокировать 95%+ атак, затрагивая менее 0.1% реальных пользователей.

mTLS для идентификации сервис-к-сервису. Mutual TLS: и клиент, и сервер предъявляют X.509-сертификаты друг другу, а не только сервер клиенту. В service mesh (Istio, Linkerd) каждый sidecar-прокси использует mTLS для общения с соседними sidecar’ами, обеспечивая zero-trust: запрос от Pod A к Pod B зашифрован и аутентифицирован. SPIFFE (Secure Production Identity Framework for Everyone) выпускает краткосрочные сертификаты (часто ~1 час) через SDS (Service Discovery Service), который sidecar загружает и автоматически ротирует. Ключ sidecar никогда не покидает локальный контейнер; control plane обновляет сертификат вне диапазона.

Стоимость: каждый новый TLS-хендшейк добавляет 20–50 мс на старом оборудовании; ротация сертификатов увеличивает операционную сложность. Преимущество: боковое перемещение предотвращается, даже если сетевая структура контейнера скомпрометирована.

TLS-стриппинг и HSTS. SSL-стриппинг (Мокси Марлинспайк, 2009): MITM держит пользователя на HTTP, пока сам общается по HTTPS с реальным сервером, расшифровывая оба направления. Пользователь не знает, что находится на открытом тексте. Защита: HTTP Strict Transport Security (HSTS) — заголовок Strict-Transport-Security: max-age=31536000 сообщает браузеру «используй только HTTPS для этого origin следующий год». Но заголовок доставляется по HTTP в первом ответе — если первый запрос уже был стриппирован, заголовок тоже стриппируется.

HSTS preload. Список доменов, встроенный в браузер, которые должны использовать только HTTPS — применяется до первого посещения домена. Google, Firefox, Chrome и Safari поставляют preload-списки. Вы запрашиваете включение своего домена; оно входит в следующий релиз браузера. Начиная с этого момента, HTTPS применяется даже для первых посетителей. Минимальный max-age для preload: 31 536 000 секунд (1 год). Требование в 1 год обусловлено тем, что preload поставляется с релизами браузера (циклы в 4 недели у Chrome) — более короткий max-age может истечь до того, как пользователи установят следующее обновление.