← Back to notes

L7 Security: Сбор архитектурной
модели (Level 1)


Теория

Сборка модели


Что зафиксировать

  1. End-to-end путь запроса: Client -> Edge -> WAF -> Rate Limiter -> Bot Management -> Cache -> Origin

  2. Где именно принимается решение:

  • allow;
  • block;
  • challenge;
  • log/count.
  1. Где находится состояние:
  • stateless edge rules;
  • shared counters/quotas;
  • origin-side state.
  1. Где находятся bottleneck-точки:
  • rule engine CPU;
  • shared counters/locks;
  • upstream latency;
  • connection limits;
  • cache miss pressure.

Ответить письменно на вопросы

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

Потому что атакующий отправляет дешёвые для себя запросы, а дорогая часть вычисления выполняется вашим origin.

Где должен стоять WAF — до или после cache?

В edge-конвейере security-проверки выполняются до доступа к origin; конкретный порядок с cache зависит от платформы/фазы, но принцип один: опасный трафик должен отсеиваться максимально рано.

Почему distributed rate limiting сложнее локального?

Нужно согласовывать состояние между узлами при гонках и задержках репликации.

Почему anycast помогает против DDoS?

Поток атаки рассеивается по множеству PoP, уменьшая локальную перегрузку.

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

Смотреть не только на RPS, а на поведение: URI skew, ошибки, latency tail, bot/challenge сигналы и impact на origin.

Где возможен bottleneck в WAF?

В тяжёлой normalization/regex-инспекции и в слишком широком наборе deep rules на каждый запрос.

Почему edge filtering дешевле origin filtering?

Потому что ранний drop экономит самый дорогой слой: приложение, БД, внутренние очереди и upstream.


Смоделировать сценарии

1. 10k RPS + медленный upstream

Ожидаемое поведение:

  • рост active requests/connections;
  • рост p95/p99;
  • риск saturation по worker/upstream pool;
  • усиление эффекта при cache miss.

2. Burst 100k req/s

Ожидаемое поведение:

  • фильтрация/лимиты на edge должны сработать раньше origin;
  • без достаточного burst control появятся массовые drops/challenges;
  • bottleneck быстро проявится в rule CPU и shared counters.

3. 10MB request body

Ожидаемое поведение:

  • рост buffering/memory/temp-file I/O;
  • выше цена WAF/body inspection;
  • повышенный риск деградации на upload endpoints.

4. Отключённый keepalive

Ожидаемое поведение:

  • больше handshake/accept overhead;
  • рост CPU на соединения;
  • ниже эффективность при одинаковом полезном RPS.

Ссылки

L7 Security: Сбор архитектурной модели (Level 1) | Aleksandr Suprun