L7 Security: Traffic Analysis

⚙️ Теория

🎯 Цель анализа

Нужно отличать четыре разных режима:

нормальный трафик;
flash crowd (легитимный всплеск);
L7-атака;
bot scraping/automation abuse.

Одинаковый рост RPS в этих сценариях требует разной реакции, поэтому без поведенческого анализа легко ошибиться.

📊 Метрики для анализа

Базовый набор:

RPS baseline (по сервису и по endpoint);
IP distribution entropy;
URI entropy / skew;
p95/p99 latency;
TLS handshake rate;
cache hit ratio.

Смысл набора: одновременно видеть источник трафика, характер запросов и реальную цену для origin.

🧠 Поведенческие сигналы

Типичные признаки подозрительного профиля:

высокая burstiness;
низкая session duration;
высокий error rate на «дорогих» URI;
аномальная повторяемость header/request fingerprint.

Сигналы всегда нужно смотреть в комбинации; по одному признаку легко получить FP.

🧪 Практическая модель анализа

Построить baseline на «здоровом» периоде.
Найти отклонение (RPS, latency, error, cache hit).
Проверить корреляции между метриками.
Проверить источник (ASN, Geo, ключевые IP сегменты).
Проверить impact на upstream и бизнес-функции.

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

Как отличить flash crowd от атаки?

Частый практический критерий:

flash crowd: рост легитимных URI, нормальные пользовательские паттерны, приемлемый conversion/business signal;
атака: перекос в дорогие/аномальные URI, плохие поведенческие сигналы, непропорциональный рост ошибок и latency.

Почему без baseline нельзя сделать надёжный детект?

Потому что «аномалия» определяется отклонением от нормального профиля конкретной системы, а не абсолютным числом RPS.

Почему нужно смотреть impact на upstream, а не только edge-метрики?

Потому что цель защиты сохранить SLA приложения. Edge может выглядеть «здоровым», а origin уже деградирует по p99/timeout.

🧪 Практика

1. Зафиксируйте baseline профиль

Снимите минимум за 7-14 дней:

RPS по URI;
p95/p99;
error ratio;
cache hit ratio;
топ ASN/Geo.

2. Настройте отклонения/алерты

Алерты на:

резкий рост request rate;
рост p99 при стабильном трафике;
падение cache hit ratio;
аномальный рост handshake rate.

3. Добавьте разбор источника

Группируйте события по:

ASN;
country;
user-agent family;
bot score/challenge outcomes.

4. Проведите post-incident разбор

Для каждого пика фиксируйте:

был ли это flash crowd или attack;
какие правила сработали;
где был bottleneck (edge, app, db, upstream API).

🧾 Вывод

Traffic analysis это дисциплина про причинно-следственные связи, а не про одну метрику.
Если у вас есть baseline, корректные корреляции и измерение impact на origin, вы можете отделять легитимный рост аудитории от реальной атаки и применять нужную защитную стратегию без лишних FP.