L7 Security: WAF Design

⚙️ Теория

🧱 Что делает WAF

WAF (Web Application Firewall) анализирует HTTP-запросы/ответы на уровне приложения и применяет policy.

Типовой результат обработки:

allow
block
challenge
log/count

Практически это enforcement-слой между edge и origin.

🏗️ Архитектура WAF (pipeline)

Request Parser
↓
Normalization
↓
Rule Engine
↓
Scoring
↓
Action

Где чаще всего ломаются системы:

плохой parser (неполный разбор payload/encodings);
неполная normalization (обходы через encoding tricks);
слишком дорогие правила (regex CPU spike);
агрессивные блоки без safe rollout (FP).

🔧 Normalization (почему это обязательно)

До проверки правил нужно привести запрос к каноническому виду:

URL decode
HTML entity decode
canonicalization path/query
case normalization

Почему: без нормализации возможны bypass-техники, включая double encoding.

🧠 Rule Engine модели

Signature-based: паттерны/regex, managed rules, OWASP CRS.
Scoring: начисление баллов по признакам и пороговое решение (anomaly scoring).
Behavioral: отклонение от baseline-поведения.
ML-based: модельный risk score + сигнатуры/эвристики.

Практический паттерн в production: гибрид, а не «чистая» одна модель.

⚖️ Trade-offs

FP (false positives): блокируем легитимных пользователей.
FN (false negatives): пропускаем атаку.
regex и deep inspection увеличивают CPU cost.
каждый дополнительный шаг может увеличивать latency.

Архитектурный принцип:

WAF не должен быть bottleneck.

Это означает: контролируемая сложность правил, staged rollout (log/count -> challenge -> block) и постоянные замеры latency/CPU.

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

Почему normalization критична?

Потому что правило сравнивает «форму» запроса. Если злоумышленник меняет форму через кодирование, но смысл остаётся атакующим, без нормализации правило не сработает.

Почему просто «добавить больше regex» опасно?

Потому что сложные выражения и их количество линейно/нелинейно увеличивают стоимость обработки каждого запроса и могут сами создать деградацию.

Почему нужен scoring, а не только binary block?

Scoring снижает FP: слабые сигналы накапливаются и блокируются только при достижении порога риска.

🧪 Практика

1. Включите режим наблюдения

Стартуйте с count/log (или аналогичного режима), а не с instant block.

2. Добавьте normalization-тесты

Проверьте кейсы:

одинарное и двойное URL-encoding;
смешанный регистр;
HTML entities;
path traversal после canonicalization.

3. Замерьте latency cost правил

Сравните p95/p99 до и после подключения rule set.

4. Введите safe rollout

этап 1: log/count
этап 2: challenge
этап 3: block для подтверждённых сигнатур

🧾 Вывод

Сильный WAF это не «много правил», а корректный pipeline: качественный parser, обязательная normalization, разумный scoring и управляемое действие.
Главная инженерная цель сохранить security efficacy, не превратив WAF в узкое место по CPU и latency.