← Back to notes

L7 Security: модель защиты,
WAF, rate-limit, anti-DDoS

2026-04-26

#l7#waf#ddos#owasp#rate-limit#edge

Зачем нужна отдельная карта темы

Когда читаешь про WAF, rate limiting и anti-DDoS по отдельности, легко потерять нить: где какой слой, кто кому предшествует, почему порядок важен. Эта заметка — навигационная карта. Она не заменяет детальные разборы, а показывает, как все части складываются в единую модель защиты.

Детальные заметки по каждому блоку:

Модель угроз: STRIDE на уровне L7

Прежде чем выбирать инструменты защиты, нужно понять, от чего именно защищаешься. STRIDE — стандартная классификационная рамка (Microsoft SDL):

STRIDE не диктует конкретные контры, но даёт систематический способ не забыть целый класс угроз. Для L7-защиты наиболее релевантны D (борьба с этим — ниже), S (bot management, auth), T (WAF, input validation) и I (CORS, заголовки безопасности).

L4 vs L7: где граница и почему она важна

Фундаментальный вопрос при проектировании защиты — на каком уровне действует угроза.

Ключевая асимметрия L7-атаки: атакующий тратит минимум ресурсов (простой GET-запрос), а origin несёт полную стоимость обработки — парсинг, аутентификацию, запросы к БД, вызовы downstream API. Это делает L7 привлекательным вектором даже при скромном ботнете.

L4-защита (SYN cookies, TCP state limits, scrubbing) защищает транспортный слой, но недостаточна против L7-атак: трафик может выглядеть как корректные TCP-соединения с корректными HTTP-запросами. Нужна инспекция на уровне протокола приложения.

Стек L7-защиты: конвейер и порядок слоёв

Принцип конвейера: fail-fast, дешёвые проверки первыми, а дорогую body/regex-инспекцию выполнять после грубого отсева.

Client
  → Edge (IP reputation / ASN / Geo / TLS fingerprint)
  → Bot Management / Challenge
  → WAF (normalization → rules → scoring → action)
  → Rate Limiting
  → Cache
  → Origin

Порядок неслучаен:

  1. Edge filtering — IP blocklist, ASN/Geo restrictions, TLS fingerprint (JA3/JA4). Дёшево, stateless, отсекает массу мусора до любой инспекции.
  2. Bot challenge / bot score часто выполняется до тяжёлых WAF-правил, чтобы не тратить дорогую inspection на явно автоматизированный трафик. Точный порядок зависит от платформы и phases.
  3. WAF инспектирует содержимое запросов — payload, заголовки, паттерны атак.
  4. Rate limiting ограничивает стоимость запроса на ключ — работает даже когда WAF не видит атаки в отдельном запросе, но видна в паттерне потока.
  5. Cache перед origin: снижает давление, но требует аккуратной конфигурации — cache poisoning открывается через манипуляции заголовками/параметрами.

Подробнее о конвейере — в Edge Filtering и Cloudflare Architecture.

Edge-фильтрация: что отсекается до origin

Edge-слой работает с сигналами, которые не требуют понимания HTTP-семантики:

  • IP reputation — известные плохие адреса, адреса datacenter vs residential
  • ASN filtering — блокировка хостинговых AS при атаке, ограничение admin surface
  • Geo filtering — ограничение доступа к API по географии, когда бизнес-смысл позволяет
  • TLS fingerprint (JA3/JA4) — JA3 хеширует параметры ClientHello (cipher suites, extensions, elliptic curves). JA4 — структурированный формат, учитывает современные TLS-поля вроде ALPN/signature algorithms и лучше нормализует вариации клиентов
  • Header anomalies — отсутствие обязательных заголовков, невозможные комбинации

Почему «только IP blocklist» недостаточно: трафик распределён по облакам, NAT, прокси. Эффективная защита — ансамбль сигналов, а не один список.

Bot Management: отделить человека от автоматизации

Bot management решает ту же задачу, что CAPTCHA, но с меньшим friction для легитимных пользователей. Типовые сигналы:

  • TLS fingerprint — JA3/JA4 помогает отличать классы клиентских библиотек независимо от IP, но не является уникальной идентичностью пользователя
  • JS challenge — выполняется ли JavaScript, соответствует ли поведение браузеру
  • Bot score — агрегат из множества classifier signals
  • Поведенческие паттерны — timing запросов, session depth, UA distribution

Один сигнал ненадёжен. Работает ансамбль + policy: сначала log/count, потом challenge, потом block для высокой уверенности. Это safe rollout для bot policy — аналогично подходу для WAF-правил.

WAF: модели и trade-offs

WAF (Web Application Firewall) — enforcement-слой между edge и origin. Pipeline:

Request Parser → Normalization → Rule Engine → Scoring → Action

Normalization обязательна до правил: URL decode, HTML entity decode, path canonicalization, case normalization. Без неё — bypass через double encoding. Правило сравнивает форму запроса; если форма изменена кодированием, но смысл атакующий — правило не сработает.

Модели rule engine:

Production: гибрид, не одна модель. OWASP Core Rule Set (CRS) — распространённый открытый ruleset для известных HTTP attack classes; он дополняет, а не заменяет application-side validation.

Главный trade-off: FP (блокируем легитимных) vs FN (пропускаем атаку). Regex и deep inspection увеличивают CPU cost, WAF не должен стать bottleneck. Safe rollout: log/count → challenge → block.

Детали — в WAF Design.

Positive vs negative WAF model:

  • Negative model (по умолчанию): разрешено всё, кроме известных плохих паттернов. Проще в эксплуатации, покрывает известные угрозы.
  • Positive model: разрешено только то, что явно описано (whitelist по схеме API). Максимальная защита, высокая стоимость поддержки — нужно обновлять при каждом изменении API.

Anti-DDoS: три класса атак, три подхода

Volumetric

Saturation канала — десятки и сотни Gbps, иногда Tbps. Основной инструмент — anycast routing: BGP может распределить поток атаки по множеству PoP, снижая локальную концентрацию. Распределение зависит от BGP-топологии и не гарантирует равномерный баланс.

Traffic scrubbing — очистка на внешнем слое (scrubbing center), куда перенаправляется «грязный» трафик перед origin.

Protocol (L4)

SYN flood исчерпывает TCP state. SYN cookies — стандартная митигация на уровне ядра. Connection limits на edge предотвращают exhaustion connection tables.

Application (L7)

Самый сложный класс — трафик формально валиден. Инструменты:

  • Rate limiting по IP / user / token — ограничивает стоимость доступа к дорогим endpoints
  • Challenge-response — JS challenge, CAPTCHA — отделяет человека от автомата
  • Slow HTTP mitigation — slowloris занимает connection state, не bandwidth. Митигация: таймауты (client_header_timeout, client_body_timeout) и лимиты соединений на IP
http {
    client_header_timeout 10s;
    client_body_timeout   10s;
    send_timeout          15s;
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:20m;

    server {
        location / {
            limit_conn conn_per_ip 20;
            proxy_pass http://backend;
        }
    }
}

Подробнее — в Anti-DDoS.

Rate Limiting: алгоритмы и выбор ключа

Rate limiting работает на уровне потока запросов — видит паттерн, который WAF не видит в отдельном запросе.

Алгоритмы

Token Bucket: токены в ведре, пополняются с заданной скоростью r, ёмкость b (макс. burst). Запрос тратит токен. Подходит для API с эластичностью на коротких пиках — накопленные токены дают controlled burst.

Sliding Window: count = prev_window_count × (1 − elapsed/window_size) + current_window_count. Меньше boundary-артефактов, чем Fixed Window. Дороже по состоянию.

Fixed Window: счётчик в фиксированном интервале. Просто, дёшево, но boundary burst на границах окон.

Leaky Bucket: входящие запросы выравниваются к фиксированной скорости. В NGINX limit_req — leaky bucket: с nodelay запросы выше rate обслуживаются немедленно (в пределах burst), без nodelay — задерживаются.

Почему ключ важнее алгоритма

Правильный limit key определяет, кого именно ограничиваешь:

  • IP за NAT → массовые FP (один IP = тысячи пользователей)
  • user_id → защита аккаунта от brute force
  • api_token → гранулярная квота по клиенту API
  • route + token — комбинация для дорогих endpoints

HTTP 429 Too Many Requests (RFC 6585) + Retry-After (RFC 9110). Для quota-информации стандартные поля — RateLimit и RateLimit-Policy (RFC 9239); X-RateLimit-* остаются распространённой vendor-практикой.

Распределённый rate limiting добавляет сложность: race conditions, consistency между узлами, replication lag. Паттерны: sharded counters, consistent hashing по limit key, local+global hybrid (локальный token bucket + глобальный decision service).

Детали — в Rate Limiting.

Traffic Analysis и Observability

Без наблюдаемости невозможно отличить flash crowd от атаки — внешне одинаковый рост RPS требует противоположных реакций.

Ключевые метрики

  • RPS baseline — по сервису и по endpoint
  • IP distribution entropy — разнообразие источников
  • URI entropy / skew — перекос в «дорогие» пути
  • p95/p99 latency — реальная цена для origin
  • TLS handshake rate — рост = новые соединения, сигнал атаки
  • Cache hit ratio — падение = рост давления на origin
  • Error rate — 4xx/5xx по URI, ASN, token

Flash crowd vs атака

Модель анализа: baseline (7–14 дней) → отклонение → корреляции → источник (ASN, Geo) → impact на upstream и бизнес-функции.

Детали — в Traffic Analysis.

OWASP Top 10 (2021): маппинг на L7-защиту

OWASP Top 10 — стандартная классификация рисков веб-приложений (https://owasp.org/Top10/). Механизмы ниже помогают снизить часть рисков, но многие классы требуют исправлений в приложении и процессе разработки.

WAF с OWASP CRS помогает прежде всего против известных injection/payload-паттернов (A03) и некоторых protocol anomalies. A01 (Access Control) и A07 (Auth failures) нельзя закрыть только WAF/rate limiting: нужны корректная авторизация, session management и app-side controls. A09 — зона logging, audit и observability.

CORS как вектор Information Disclosure

CORS (Cross-Origin Resource Sharing) — механизм браузера, контролирующий cross-origin запросы (MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). Неправильная конфигурация открывает класс A05 и I из STRIDE.

Критичные правила:

  • Access-Control-Allow-Origin: * + Access-Control-Allow-Credentials: true — запрещённая браузером комбинация; реальная опасность обычно в отражении произвольного Origin вместе с credentials
  • В production: явный список разрешённых origins, не wildcard
  • Preflight (OPTIONS) запросы — дополнительная защита для non-simple requests; не блокировать на edge без понимания последствий
  • CORS-rejection логировать — зонд атакующего, проверяющего allowed origins

Когда использовать

Edge filtering + bot management — базовый уровень для публичных сервисов. Требует аккуратного rollout, чтобы не блокировать легитимных пользователей за NAT/VPN.

WAF — когда приложение принимает пользовательский input (формы, API, загрузка файлов). Особенно важен для OWASP Top 10 A03 (Injection). Может не иметь смысла для чисто внутренних сервисов без внешнего трафика.

Rate limiting — для любого публичного API и для форм аутентификации. Абсолютный минимум: лимит на /login, /register, /reset-password. Для API — квоты по токену.

Anti-DDoS (dedicated scrubbing/anycast) — когда сервис публично значим или уже подвергался атакам. Cloudflare/AWS Shield/Google Cloud Armor дают инфраструктурный слой защиты; для большинства сервисов практичнее использовать managed-продукт, чем строить свою anycast/scrubbing-сеть.

Traffic analysis / observability — с первого дня. Без baseline аномалии трудно отличить от нормального роста. Инструменты могут быть простыми, но метрики и логи должны покрывать endpoint, ASN/Geo, cache hit ratio и upstream impact.

Типичные ошибки

Ошибка 1: WAF в режиме «поставил и забыл». Managed rules устаревают, FP накапливаются. Нужен регулярный review событий, обновление ruleset, замеры FP/FN.

Ошибка 2: Rate limit по IP за NAT. Один IP у корпоративного прокси может стоить за тысячи пользователей. Правильный ключ: user_id или API token, не голый IP.

Ошибка 3: Игнорировать slow HTTP. Атаки типа slowloris не видны в bandwidth-графиках, но убивают connection pool. Таймауты обязательны.

Ошибка 4: CORS * с credentials. Классическая misconfiguration, которую легко допустить при быстрой разработке. Открывает A05 + I (STRIDE).

Ошибка 5: Нет baseline — нет детекции. Без нормального профиля трафика нельзя отличить атаку от flash crowd. Алерты на абсолютные пороги дают много ложных срабатываний.

Ошибка 6: Deep inspection на каждый запрос. Тяжёлые WAF-правила и полная normalization + regex на 100% трафика превращают WAF в bottleneck. Selective deep checks, дешёвые тесты первыми.

Ошибка 7: Защита только периметра. Origin нужно защищать от прямого обхода CDN: ACL по source ranges, authenticated origin pulls/mTLS или другой origin-auth механизм.

Альтернативы

Вместо самописного rate limiter — использовать Cloudflare Rate Limiting, AWS WAF rate-based rules, или библиотеку типа redis-cell (token bucket на Redis с RESP команды CL.THROTTLE). Самописное решение оправдано только при специфических требованиях к ключу или алгоритму.

Вместо custom WAF rules — OWASP CRS как managed ruleset. Поддерживается сообществом, покрывает широкий спектр атак, имеет готовые профили для популярных фреймворков. Custom rules поверх CRS — для специфики вашего API.

Вместо edge-скрубинга своими силами — upstream CDN с DDoS-защитой (Cloudflare, Fastly, Akamai) или облачный Shield (AWS Shield Advanced, Google Cloud Armor с Adaptive Protection). Строить свою anycast-сеть имеет смысл только на масштабе уровня крупного хостера.

Вместо polling-мониторинга — event-driven observability: structured logs → Loki/Elasticsearch, метрики → Prometheus/Datadog, алерты по аномалиям, а не абсолютным порогам. Для traffic analysis это дешевле и точнее, чем ручной разбор логов.

Вместо WAF для API-to-API трафика — mTLS + schema validation на уровне gateway (Kong, Envoy). WAF оптимизирован для HTTP-трафика от браузеров; для internal API достаточно TLS mutual auth + input validation на стороне сервиса.

Ссылки

  • OWASP Top 10 (2021): https://owasp.org/Top10/
  • OWASP CRS: https://coreruleset.org/docs/
  • RFC 6585 (HTTP 429): https://www.rfc-editor.org/rfc/rfc6585
  • MDN CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
  • Cloudflare Learning Center: https://www.cloudflare.com/learning/
  • Google Cloud Armor Adaptive Protection: https://cloud.google.com/armor/docs/adaptive-protection-overview
L7 Security: модель защиты, WAF, rate-limit, anti-DDoS | Aleksandr Suprun