L7 Security: Anti-DDoS

Теория

Три класса DDoS

Volumetric (L3/4) — saturation канала (UDP flood, ICMP flood, DNS/NTP/memcached amplification). Метрика: bps/pps.
Protocol (L4) — эксплуатация state machine: SYN flood, ACK flood, исчерпание connection tables. Митигация: SYN cookies, connection limits.
Application (L7) — формально валидный HTTP: HTTP flood, slowloris, expensive query flood. Митигация: rate limiting, challenge-response, WAF, таймауты.

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

Anycast + BGP: распределение трафика по PoP, локальная мощность атаки = доля от общей.
Traffic scrubbing: внешний центр очистки (BGP rerouting или GRE tunnel) перед origin.
Rate limiting по ключу (IP/user/token).
Challenge-response: JS challenge / managed challenge / Turnstile / CAPTCHA.
Connection limiting: лимиты на IP/account, защита от exhaustion worker pool.

Slow HTTP mitigation

Slowloris и Slow POST держат соединения открытыми, посылая данные по байту, и исчерпывают connection state без потребления bandwidth. Контр-меры:

client_header_timeout, client_body_timeout, send_timeout;
limit_conn по IP;
лимиты тела запроса (client_max_body_size, client_body_buffer_size).

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

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

Атака распределяется по множеству PoP, локальная концентрация падает.

Почему challenge-response полезен именно на L7?

Отделяет браузер от автоматизации в трафике, который формально валиден.

Почему slow HTTP требует таймаутов, а не bandwidth-защиты?

Атака не потребляет канал, но удерживает connection state. Bandwidth-метрики не сработают; нужны таймауты и limit_conn.

Практика

1. Установите таймауты и лимиты в NGINX

http {
    client_header_timeout 10s;
    client_body_timeout 10s;
    send_timeout 15s;

    limit_conn_zone $binary_remote_addr zone=conn_per_ip:20m;

    server {
        location / {
            limit_conn conn_per_ip 20;
            proxy_pass http://backend;
        }
    }
}

2. Проверьте поведение на медленных клиентах

сгенерируйте slow headers/body трафик;
проверьте, что соединения закрываются по таймаутам;
проверьте, что origin не уходит в saturation.

3. Включите challenge/rate policies на edge

Сравните до/после:

входящий трафик на origin;
p95/p99;
ошибочные блокировки (FP).

4. Мониторьте ключевые индикаторы

active connections;
handshake/connection rate;
доля challenge/block;
origin CPU и upstream timeouts.