Зачем нужна отдельная карта темы
Когда читаешь про WAF, rate limiting и anti-DDoS по отдельности, легко потерять нить: где какой слой, кто кому предшествует, почему порядок важен. Эта заметка — навигационная карта. Она не заменяет детальные разборы, а показывает, как все части складываются в единую модель защиты.
Детальные заметки по каждому блоку:
- Application Layer Security
- Cloudflare Architecture
- Edge Filtering
- WAF Design
- Rate Limiting
- Anti-DDoS
- Traffic Analysis
- Security Architecture Synthesis
Модель угроз: STRIDE на уровне L7
Прежде чем выбирать инструменты защиты, нужно понять, от чего именно защищаешься. STRIDE — стандартная классификационная рамка (Microsoft SDL):
| Угроза | Расшифровка | L7-пример |
|---|---|---|
| S Spoofing | Подмена идентичности | Credential stuffing, session hijacking |
| T Tampering | Модификация данных | SQLi, request parameter tampering |
| R Repudiation | Отрицание действия | Отсутствие audit log на критичных операциях |
| I Information Disclosure | Утечка данных | Verbose error messages, CORS misconfiguration |
| D Denial of Service | Отказ в обслуживании | HTTP flood, slowloris, volumetric DDoS |
| E Elevation of Privilege | Повышение привилегий | IDOR, business logic abuse, JWT manipulation |
STRIDE не диктует конкретные контры, но даёт систематический способ не забыть целый класс угроз. Для L7-защиты наиболее релевантны D (борьба с этим — ниже), S (bot management, auth), T (WAF, input validation) и I (CORS, заголовки безопасности).
L4 vs L7: где граница и почему она важна
Фундаментальный вопрос при проектировании защиты — на каком уровне действует угроза.
| Уровень | Цель атаки | Примеры | Характеристика |
|---|---|---|---|
| L3 | Saturation сети | UDP flood, ICMP flood, DNS amplification | Измеряется в Gbps/Tbps |
| L4 | Exhaustion TCP state | SYN flood, connection flood | Занимает таблицы соединений |
| L7 | Перегрузка app/CPU/DB | HTTP flood, expensive query flood, slowloris | Выглядит как валидный трафик |
Ключевая асимметрия 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Порядок неслучаен:
- Edge filtering — IP blocklist, ASN/Geo restrictions, TLS fingerprint (JA3/JA4). Дёшево, stateless, отсекает массу мусора до любой инспекции.
- Bot challenge / bot score часто выполняется до тяжёлых WAF-правил, чтобы не тратить дорогую inspection на явно автоматизированный трафик. Точный порядок зависит от платформы и phases.
- WAF инспектирует содержимое запросов — payload, заголовки, паттерны атак.
- Rate limiting ограничивает стоимость запроса на ключ — работает даже когда WAF не видит атаки в отдельном запросе, но видна в паттерне потока.
- 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 → ActionNormalization обязательна до правил: URL decode, HTML entity decode, path canonicalization, case normalization. Без неё — bypass через double encoding. Правило сравнивает форму запроса; если форма изменена кодированием, но смысл атакующий — правило не сработает.
Модели rule engine:
| Модель | Суть | Когда подходит |
|---|---|---|
| Signature-based | Паттерны/regex, OWASP CRS | Известные векторы, быстро |
| Anomaly scoring | Баллы по признакам, пороговое решение | Снижает FP одиночных сигналов |
| Behavioral | Отклонение от baseline | Новые паттерны, сложнее настроить |
| ML-based | Risk score + эвристики | Дорого, высокая точность |
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 forceapi_token→ гранулярная квота по клиенту APIroute + token— комбинация для дорогих endpoints
HTTP 429 Too Many Requests (RFC 6585) + Retry-After (RFC 9110). Для quota-информации предложены поля RateLimit и RateLimit-Policy (IETF draft draft-ietf-httpapi-ratelimit-headers, ещё не стандартизованы); 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 атака
| Сигнал | Flash crowd | Атака |
|---|---|---|
| Referrer | Присутствует (новость, соцсеть) | Отсутствует или фиктивный |
| Гео-распределение | Соответствует аудитории | Аномальная концентрация ASN/страны |
| Session depth | Нормальный путь, несколько страниц | 1–2 запроса, нет сессии |
| URI distribution | Легитимные страницы | Перекос в дорогие/аномальные endpoints |
| Timing | Нерегулярный (человеческий) | Механически регулярный |
| Ошибки | Пропорциональный рост | Непропорциональный spike |
Модель анализа: baseline (7–14 дней) → отклонение → корреляции → источник (ASN, Geo) → impact на upstream и бизнес-функции.
Детали — в Traffic Analysis.
OWASP Top 10 (2021): маппинг на L7-защиту
OWASP Top 10 — стандартная классификация рисков веб-приложений (https://owasp.org/Top10/). Механизмы ниже помогают снизить часть рисков, но многие классы требуют исправлений в приложении и процессе разработки.
| Код | Категория | Механизм защиты |
|---|---|---|
| A01 | Broken Access Control | Авторизация на origin, IDOR-защита, least privilege |
| A02 | Cryptographic Failures | TLS 1.3, HSTS, правильные cipher suites, mTLS |
| A03 | Injection (SQLi, XSS, …) | WAF (CRS rules), input validation, parameterized queries |
| A04 | Insecure Design | Threat modeling (STRIDE), security architecture review |
| A05 | Security Misconfiguration | CORS headers, security headers (CSP, HSTS), default deny |
| A06 | Vulnerable Components | Dependency scanning, managed rulesets обновляются вендором |
| A07 | Auth & Session Failures | MFA, session management, bot management против credential stuffing |
| A08 | Software & Data Integrity | CI/CD pipeline security, supply chain controls |
| A09 | Logging & Monitoring Failures | Traffic analysis, observability, audit log |
| A10 | SSRF | Egress filtering, origin-side validation входящих URL |
Таблица выше — редакция 2021. Актуальная редакция — OWASP Top 10:2025 (финал в январе 2026): A01 Broken Access Control (в него влит SSRF), A02 Security Misconfiguration, A03 Software Supply Chain Failures (новая), A04 Cryptographic Failures, A05 Injection, A10 Mishandling of Exceptional Conditions (новая).
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 (GCRA на Redis — поведенчески эквивалент token bucket, 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