Информационная безопасность
DDoS: атаки и митигация
Февраль 2020. AWS Shield отражает DDoS атаку 2,3 Tbps - достаточно трафика чтобы заполнить 23 000 домашних каналов одновременно. За 9 минут атака поглощена. Для сравнения: весь интернет-трафик США в 2000 году составлял около 100 Gbps в сутки. Одна атака 2020 года превосходит его в 23 раза.
- **Cloudflare** поглотила HTTP/2 Rapid Reset атаку 201 млн запросов/сек (2023) - крупнейшую application layer атаку в истории
- **Dyn DNS 2016**: Mirai ботнет из IoT-камер уронил Twitter, GitHub, Netflix - показал уязвимость централизованной DNS инфраструктуры
- **GitHub 2018**: Memcached amplification x51000 - сервис был недоступен 10 минут до подключения Akamai Prolexic scrubbing
Volumetric-атаки: перегрузка канала
Февраль 2020. GitHub получает 2,54 Tbps трафика - крупнейшая на тот момент DDoS-атака в истории. Сервис остался доступен. Через 10 минут атака прекратилась. За этим стоят годы инвестиций в distributed mitigation infrastructure.
Volumetric DDoS - наводнение канала трафиком. Цель не взломать систему, а исчерпать пропускную способность: если канал жертвы 10 Gbps, достаточно направить 15 Gbps мусора. Источник: ботнет из сотен тысяч скомпрометированных устройств (Mirai в 2016 использовал IoT-устройства с дефолтными паролями). Размер ботнета определяет максимальный объем атаки.
UDP flood - самый простой volumetric вектор: UDP stateless, spoofing прост. SYN flood - заполнение таблицы half-open connections TCP стека (SYN cookies как контрмера). ICMP flood (ping of death, smurf) - исторически важны, сейчас редки из-за фильтрации. Ключевой метрик атаки - Gbps (volumetric) и Mpps (packet rate) - маршрутизаторы имеют предел pps независимо от bandwidth.
Сервер имеет uplink 1 Gbps. Ботнет направляет 1,5 Gbps UDP трафика. Что произойдет с легитимными запросами?
Amplification-атаки: умножение мощности
Amplification решает проблему ботнета: зачем иметь 100K устройств, если можно превратить 1K в эффективный эквивалент 51K через amplification factor? Принцип: отправить небольшой запрос с spoofed IP жертвы к publicly accessible серверу, который отвечает значительно большим ответом - напрямую жертве.
DNS amplification: запрос ANY к DNS-серверу (50-100 байт) -> ответ до 4000 байт. Amplification factor x40. NTP Monlist: один запрос (40 байт) -> список 600 последних клиентов (48000 байт). Factor x1200. Memcached (2018): UDP запрос 15 байт -> ответ 750KB. Factor x51000. GitHub атака 2018 использовала именно Memcached.
BCP38 (Network Ingress Filtering) - стандарт 2000 года, который должен был уничтожить IP spoofing. ISP фильтрует исходящие пакеты: если src IP не принадлежит клиентской подсети - пакет дропается. Если бы все ISP внедрили BCP38, amplification атаки стали бы невозможны. В 2024 году около 30% автономных систем по-прежнему не фильтруют исходящие пакеты.
Почему Memcached amplification (x51000) значительно опаснее DNS amplification (x40)?
CDN и Anycast: поглощение атаки
Cloudflare имеет capacity 280 Tbps. Крупнейшая известная атака - 3,8 Tbps (2023, HTTP/2 Rapid Reset). Математика простая: если ваша capacity в 70 раз больше максимальной атаки, volumetric DDoS вас не уронит. Именно поэтому крупные CDN стали де-факто DDoS mitigation провайдерами.
Anycast - технология BGP маршрутизации, где один IP-адрес анонсируется из множества geographic точек. Каждый пользователь маршрутизируется к ближайшей PoP. Атакующий трафик тоже маршрутизируется - и распределяется между сотнями PoP вместо одного origin. 100 Gbps атака делится между 200 PoP по 500 Mbps каждый - поглощается без перегрузки.
RTBH (Remotely Triggered Black Hole) - механизм быстрого реагирования: ISP анонсирует /32 маршрут жертвы с community атрибутом blackhole. Все upstream провайдеры начинают дропать трафик к этому IP. Проблема: жертва становится недоступна для всех включая легитимных пользователей. Это тотальная блокировка, не фильтрация. Используется только когда атака угрожает инфраструктуре ISP.
Стартап хочет защититься от volumetric DDoS. Какой подход наиболее эффективен при ограниченном бюджете?
Rate Limiting и Application-Layer защита
Application layer DDoS (Layer 7) - труднее всего защититься. Трафик выглядит легитимным: HTTP GET к главной странице, поисковые запросы, комментарии. Объем небольшой, но каждый запрос создает высокую серверную нагрузку (сложный SQL, генерация PDF). 10,000 RPS такого трафика убивают сервер с capacity 100,000 RPS обычных запросов.
Rate limiting - ограничение числа запросов от одного источника за период. Token bucket: каждый IP накапливает токены со скоростью N/сек, каждый запрос тратит токен. При исчерпании - 429 Too Many Requests. Leaky bucket: очередь фиксированного размера, обрабатывается с постоянной скоростью. Алгоритмы реализуются в Redis/Nginx/API Gateway, а не в коде приложения.
Slowloris - элегантная L7 атака: открыть HTTP соединение, отправлять заголовки очень медленно (1 байт каждые 15 сек). Сервер держит соединение открытым, ожидая конец заголовков. Тысячи таких соединений исчерпывают connection pool. Один атакующий без ботнета может уронить веб-сервер. Mitigation: timeout на неполные заголовки, connection limit per IP, async event-driven сервер (nginx vs Apache prefork).
Мощный firewall на входе защитит от любого DDoS
Volumetric DDoS исчерпывает uplink канал до firewall; application DDoS проходит через firewall как легитимный трафик - нужны CDN anycast и L7 mitigation
Firewall работает на уровне сервера, а volumetric атака перегружает ISP канал до сервера. L7 атаки используют валидные HTTP запросы - firewall их не отличит от легитимных. Реальная защита многослойная: CDN (объем) + WAF (сигнатуры) + rate limiting (аномалии)
Злоумышленник отправляет 500 запросов/сек к endpoint /api/search (тяжелый полнотекстовый поиск). Rate limit установлен на 100 req/min на IP. Атака идет с 10 разных IP. Что изменить?
Связанные темы
DDoS защита пересекается с сетевой безопасностью и web-архитектурой:
- Сетевые протоколы и TCP/IP — Понимание UDP, TCP, DNS - основа анализа векторов атак
- Web Application Security — WAF, rate limiting, bot detection - защита на application layer
- Secure SDLC — Архитектурная защита от DoS закладывается на этапе проектирования
Ключевые идеи
- **Volumetric**: перегрузка uplink канала ботнетом; firewall не помогает - атака до него; нужна CDN capacity
- **Amplification**: x51000 через Memcached UDP; BCP38 фильтрация ISP - системное решение которое не все внедрили
- **CDN + Anycast**: распределение атаки по сотням PoP; суммарная capacity CDN >> максимальная атака
- **Rate limiting + L7**: token bucket/leaky bucket в Redis/Nginx; per-endpoint limits для тяжелых операций; circuit breaker как последний рубеж
Вопросы для размышления
- Почему amplification атаки возможны только через UDP, не TCP? Что в TCP handshake предотвращает spoofing?
- Cloudflare предлагает бесплатный DDoS protection. Какова бизнес-модель? Какие риски для пользователей?
- Slowloris атака не требует ботнета. Как event-driven архитектура (nginx) защищает от нее лучше чем thread-per-connection (Apache)?
Связанные уроки
- sec-08 — Сетевые протоколы (TCP/UDP/DNS) - основа понимания векторов DDoS
- sec-16 — Secure SDLC включает защиту от DoS на уровне архитектуры
- web-12 — WAF и rate limiting применяются на web-слое против application DDoS
- net-09-router-intro — BGP anycast - ключевая сетевая техника для поглощения объемных атак
- sec-09 — Firewall rules - первый рубеж фильтрации DDoS трафика
- net-43-ddos