L7 Security: Application Layer Security

⚙️ Теория

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

Layer 7 в этом контексте это протоколы уровня приложения: HTTP/HTTPS, gRPC, WebSocket.

Подтверждаемые факты:

gRPC работает поверх HTTP/2.
WebSocket стартует через HTTP Upgrade handshake.
L7-атаки часто выглядят как «валидные» HTTP-запросы, поэтому их сложнее отфильтровать, чем чистый L3/L4 flood.

Идея L7-атаки: не «забить канал», а заставить приложение тратить дорогие ресурсы (CPU, DB, кеш, upstream pool).

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

Типовые классы:

HTTP flood (перегрузка RPS).
Slow HTTP (slowloris, медленный POST/body drip).
Credential stuffing (массовая проверка украденных логин/пар).
API abuse (чрезмерная/злоупотребляющая автоматизация API).
Injection (SQLi, XSS и связанные инъекционные векторы).
Business logic abuse (эксплуатация правил приложения без обязательного взлома транспорта).

📊 L3/L4 vs L7

Уровень	Цель	Пример
`L3`	Saturation сети/IP	`SYN`/volumetric flood
`L4`	Exhaustion TCP state	connection flood
`L7`	Перегрузка app/CPU/DB	expensive query flood

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

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

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

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

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

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

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

RPS (общий и по endpoint/key).
Error rate (4xx/5xx по URI, ASN, token).
Upstream latency (p95/p99, очереди backend).
Unique IP 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 это защита не только от «большого трафика», а от экономически асимметричных атак, где атакующему дёшево, а приложению дорого.
Поэтому архитектура строится как многослойный edge-first pipeline, а качество защиты оценивается по impact-метрикам (latency, error, upstream pressure), а не только по bandwidth.