← Back to notes

L7 Security: Application
Layer Security

2026-02-21

#l7#ddos#api

Теория

Что такое L7-угрозы

Layer 7 — протоколы уровня приложения: HTTP/1.1 (RFC 9112), HTTP/2 (RFC 9113), HTTP/3 (RFC 9114), gRPC (поверх HTTP/2), WebSocket (RFC 6455, стартует через HTTP Upgrade).

L7-атаки выглядят как валидный HTTP, поэтому L3/L4 фильтры бесполезны. Цель — не забить канал, а заставить origin тратить CPU, DB, upstream pool.

Категории L7-угроз

  • HTTP flood — RPS-перегрузка.
  • Slow HTTP — slowloris, slow POST (RUDY), drip body.
  • Credential stuffing — OAT-008 (OWASP Automated Threats).
  • API abuse — OWASP API Security Top 10 2023 (BOLA, BOPLA, BFLA).
  • Injection — OWASP A03:2021 (SQLi, NoSQLi, XSS, XXE, command injection).
  • Business logic abuse — манипуляция правил без эксплойта транспорта.

L3/L4 vs L7

Ключевой момент: L7-атака может иметь относительно низкий bandwidth, но высокий impact на CPU и latency.

Компоненты L7-защиты

Практический стек:

Client
↓
Edge (CDN / Reverse Proxy)
↓
WAF
↓
Rate Limiter
↓
Bot Management
↓
Origin

Архитектурные требования к слоям:

  • быть stateless или минимально stateful;
  • масштабироваться горизонтально;
  • работать event-driven и fail-fast.

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

  • RPS (общий и по endpoint/key);
  • error rate (4xx/5xx по URI, ASN, token);
  • upstream latency p95/p99;
  • IP/ASN entropy (источники);
  • URI distribution skew (перекос в «дорогие» пути);
  • header entropy (аномальное однообразие).

Entropy/skew — производные из логов, не встроенные метрики вендора.

Что нужно уметь объяснить

Почему L7-атака может быть дешевле для атакующего?

Потому что атакующему достаточно отправлять формально корректные запросы к «дорогим» операциям, а дорогую работу выполняет ваш origin (приложение, БД, downstream API).

Почему L7-атака может пройти мимо сетевых фильтров?

Потому что пакет/соединение выглядят «нормально», а злоупотребление видно только на уровне HTTP-семантики и бизнес-логики.

Почему на L7 важно смотреть не только RPS?

Одинаковый RPS может иметь радикально разную стоимость: дешёвый GET /health и дорогой POST /search с тяжёлой агрегацией создают разный CPU/DB impact.

Практика

1. Соберите baseline по «нормальному» дню

Минимум:

  • RPS по endpoint;
  • p95/p99 latency;
  • error ratio;
  • cache hit ratio;
  • топ ASN/Geo/IP.

2. Прогоните synthetic-нагрузку

wrk -t8 -c400 -d60s https://example.com/api/expensive

Сравните с baseline:

  • вырос ли tail latency;
  • изменилась ли доля 4xx/5xx;
  • выросла ли доля запросов в «дорогие» URI.

3. Проверьте, что edge реально разгружает origin

Сравните до/после включения WAF/rate limiting/bot challenge:

  • запросы на origin;
  • CPU origin;
  • p95/p99.

Ссылки

L7 Security: Application Layer Security | Aleksandr Suprun