Компьютерные сети
DDoS атаки и защита
В феврале 2018 GitHub упал на 10 минут. Атака в 1.35 Tbps - больше чем пропускная способность небольшой страны. Через 5 дней рекорд побили: 1.7 Tbps. Как одна компания выдержала то, что могло уронить целую нацию?
- **Cloudflare** отражает в среднем 140 млрд кибератак в день. Их сеть в 248 Tbps - больше чем bandwidth всего интернета в 2005 году
- **Mirai ботнет** из умных камер и роутеров достиг 600K устройств и уронил DNS провайдера Dyn - Twitter, Netflix, GitHub были недоступны часами
- **Amplification атаки** - хакер с каналом 10 Mbps генерирует 5 Tbps трафика через публичные Memcached серверы. Асимметричная война
Предварительные знания
Цели урока
- Различать L3/L4 (volumetric, SYN flood, UDP flood) и L7 (HTTP flood, Slowloris) атаки
- Объяснить amplification: DNS x54, NTP x556, Memcached x51000, почему UDP опасен без spoof-protection
- Понимать архитектуру защиты: anycast scrubbing, BGP blackhole, rate limiting, challenge pages
- Прочитать tcpdump атаки и идентифицировать тип по pattern (SYN без ACK, identical payloads, low RPS на дорогих endpoint)
- Знать ключевые цифры: 1.35 Tbps GitHub 2018, 2.3 Tbps AWS 2020, 3.47 Tbps Azure 2021
Типы DDoS атак
**DDoS (Distributed Denial of Service)** - атака из множества источников, цель которой исчерпать ресурсы жертвы. В отличие от DoS (один атакующий), DDoS использует ботнеты - сети заражённых устройств (от умных лампочек до серверов).
**Три уровня атак по модели OSI:** L3/L4 (сетевой/транспортный) - исчерпание bandwidth и connection state. L7 (прикладной) - исчерпание CPU/памяти приложения. Каждый требует своих методов защиты.
**Ботнеты** - армия зомби-устройств. Mirai (2016) заразил 600K IoT устройств и атаковал Dyn DNS с мощностью 1.2 Tbps, уронив Twitter, Netflix, GitHub. Современные ботнеты достигают 10+ млн устройств.
Чем L7 DDoS опаснее L3/L4 атак?
SYN Flood
**SYN Flood** - классическая атака на TCP handshake. Атакующий отправляет тысячи SYN пакетов с поддельными IP-адресами. Сервер создаёт half-open соединения, ожидая ACK, который никогда не придёт. Очередь переполняется - новые клиенты не могут подключиться.
**SYN Cookies** - защита без хранения state. Сервер кодирует информацию о соединении в sequence number SYN-ACK. При получении ACK - декодирует и проверяет. Если ACK не придёт - ничего не потеряно, state не создавался.
Почему SYN Flood использует поддельные IP-адреса?
Amplification атаки
**Amplification** - атака с усилением. Атакующий отправляет маленький запрос на публичный сервер, подменяя source IP на IP жертвы. Сервер отвечает жертве пакетом в 10-500 раз больше. Маленький ботнет генерирует терабиты трафика.
**Memcached атака (2018)** - рекорд 1.7 Tbps на GitHub. Атакующий отправлял 203 байта, получал 100 MB ответа (усиление 500,000x!). Memcached слушал на публичном UDP без аутентификации. После атаки протокол массово закрыли.
**BCP38 (RFC 2827)** - стандарт защиты от IP spoofing. ISP должны фильтровать исходящий трафик: если source IP не из их сети - дропать. Если бы все ISP внедрили BCP38, amplification атаки стали бы невозможны. Но ~30% сетей всё ещё не фильтруют.
Почему Memcached дал рекордное усиление 500,000x?
Mitigation: защита от DDoS
**Mitigation** - смягчение атаки. Полностью предотвратить DDoS нельзя, но можно минимизировать ущерб. Стратегия: absorb (поглотить), scrub (очистить), blackhole (сбросить). Выбор зависит от типа атаки и ресурсов.
**Scrubbing Center** - дата-центр для очистки трафика. Весь трафик к вам идёт через scrubbing center, где отфильтровывается вредоносный. Чистый трафик пересылается на origin. Задержка +5-20ms, но защита от 1+ Tbps атак.
Когда оправдано использование BGP Blackhole?
Rate Limiting
**Rate Limiting** - ограничение количества запросов. Каждый клиент (IP, user, API key) получает лимит запросов в единицу времени. Превысил - 429 Too Many Requests. Это защита и от DDoS, и от abuse API.
**Sliding Window Log** - храним timestamp каждого запроса. При новом запросе удаляем старые (>60 сек) и считаем оставшиеся. Точно, но O(n) памяти. **Sliding Window Counter** - комбинация: weighted average между текущим и предыдущим окном. Почти точно, O(1) памяти.
Rate limiting полностью защищает от DDoS
Rate limiting защищает от L7 атак, но бессилен против volumetric - канал забьётся до сервера
Если 100 Gbps трафика летит к вам, rate limiting на nginx не поможет - пакеты уже забили канал. Нужен scrubbing на edge. Rate limiting - последняя линия для 'умных' атак
Какой алгоритм rate limiting лучше для API с burst трафиком?
Итоги
- **DDoS - три уровня:** Volumetric (забить канал), Protocol (исчерпать state), Application (убить CPU). Каждый требует своей защиты
- **SYN Flood** исчерпывает очередь half-open соединений. Защита: SYN Cookies кодируют state в sequence number
- **Amplification** умножает трафик в 50-500,000 раз через публичные UDP сервисы. Защита: BCP38 на ISP уровне
- **Mitigation многоуровневый:** Edge CDN (absorb) → ISP scrubbing → BGP blackhole (последнее средство) → Host rate limiting
- **Rate Limiting:** Token Bucket для burst, Sliding Window для точности, Fixed Window - избегать на стыках
Связанные темы
DDoS защита строится на знании всего сетевого стека:
- Firewall и ACL — Базовая фильтрация трафика, но не справляется с volumetric
- Anycast — CDN используют anycast для распределения нагрузки атаки
- CDN — Edge сеть - первая линия защиты от DDoS
- TCP Handshake — SYN Flood эксплуатирует three-way handshake
Вопросы для размышления
- Если BCP38 решает проблему spoofing, почему 30% ISP его не внедрили? Какие у них мотивы?
- Почему IoT устройства стали главным источником ботнетов? Как бы вы решили эту проблему?
- CDN защищает от DDoS, но добавляет third party в цепочку доверия. Когда это неприемлемо?