DDoS-атаки (Distributed Denial of Service) — это координированные попытки сделать онлайн‑сервис недоступным или ухудшить его качество путем исчерпания сетевых и вычислительных ресурсов. За последние годы они заметно усложнились: на смену «примитивным» UDP‑флудам пришли многоступенчатые кампании, где сочетаются удары по каналу, по стеку TCP/IP, по приложению и по зависимым сервисам (DNS, API‑шлюзам, базам данных). Это значит, что защищаться нужно архитектурно, выстраивая многоуровневую оборону и готовые к быстрому включению процессы, а не полагаться на одно «чудо‑устройство» или единственный облачный сервис.
Практическая задача защиты от DDoS состоит из трёх больших блоков: правильной топологии сети и периметра, устойчивой архитектуры приложения и выверенной операционной готовности. Ниже — развёрнутое описание этих блоков, с примерами техпроцедур и конкретных приёмов, а также со сдержанным количеством маркированных списков там, где они действительно повышают читабельность.
Картина угроз: почему DDoS становится умнее
Современная атака нередко выглядит как «кампания», где противник тестирует вашу защиту малыми порциями, выясняет болевые точки и лишь затем запускает основную волну. Целями выбирают не только фронт веб‑приложения, но и элементы инфраструктуры вокруг него: DNS‑зону, балансировщики, брокеры очередей, кэш‑кластеры, даже систему логирования. Важно понимать и поведенческий аспект: атакующие анализируют бизнес‑ритм (распродажи, праздничные пики, релизы) и бьют по SLA‑критичным окнам.
Ключевые причины усложнения ситуации:
- широкая доступность бот‑сетей и услуга «DDoS‑как‑сервис» с почасовой оплатой;
- рост доли API‑трафика и сложных L7‑эндпоинтов, где запрос «дороже» ответа;
- распространение микросервисов и зависимостей, приводящее к каскадным сбоям;
- активное использование CDN и WAF, из‑за чего противники смещают фокус на обход поведенческих правил, злоупотребление легитимными протоколами и атаки на соседние компоненты.
Типы атак и их опасность
На сетевом и транспортном уровне цель — забить каналы и/или перегрузить устройства обработки пакетов. Это классические volumetric‑флуды, отражённые и усиленные атаки через открытые сервисы, а также злоупотребление особенностями TCP (SYN‑flood, фрагментация). Здесь важно не только количество бит в секунду, но и пакетов в секунду: именно pps часто «кладёт» маршрутизаторы и балансировщики, а не суммарная полоса.
На уровне приложений акцент смещается на вычислительную трудоёмкость. Видимым следствием становится рост времени ответа, скачки в TTFB и нарастающая доля ошибок 5xx/429. Особенно опасны «медленные» сценарии (slowloris‑подобные техники), удерживающие воркеры и соединения, и целенаправленные удары по «дорогим» API‑операциям — экспортам, поискам со сложными фильтрами, отчётам.
Отдельный фронт — зависимые сервисы. Удары по авторитативным DNS способны сделать недоступным весь домен, даже если сами фронты и базы функционируют. А перегрузка API‑шлюза, брокера очередей или кэш‑кластера парализует микросервисную систему «изнутри», заставляя её рушиться каскадом.
Чтобы говорить с провайдерами и подрядчиками на одном языке, необходимо держать под рукой общие метрики. Критичны показатели пропускной способности (bps/Gbps/Tbps), плотности пакетов (pps), скорости новых TCP‑соединений (cps), интенсивности HTTP‑запросов (rps/qps), а также состояние ресурсов приложений: файловые дескрипторы, пулы соединений, оперативная память, загрузка CPU, глубина очередей и latency.
Стратегия защиты: многоуровневая модель без «серебряной пули»
Рабочая модель строится вокруг пяти стадий: предотвращения, поглощения, обнаружения, смягчения и восстановления. Предотвращение — это архитектурные решения, делающие дорогое дешёвым: кэширование на границе, предварительные вычисления, статлесс‑фронты, сегментация доменов и изоляция «дорогих» эндпоинтов. Поглощение — достаточные каналы и резервные мощности, договорённости с провайдерами об RTBH/FlowSpec и доступ к скруббинг‑центрам. Обнаружение — телеметрия по сетевым потокам и L7‑логам, поведенческие профили, дашборды и алерты. Смягчение — включение фильтров и политик: ACL, WAF, ограничение скоростей, челленджи, переводы префиксов в очистку. Восстановление — поэтапная отмена временных мер, наблюдение за рецидивами и пост‑мортем с последующим укреплением контура.
Короткий справочник по стадиям:
- предотвращение: архитектура, кэш, статлесс‑подход, разделение доменов;
- поглощение: каналы, балансировщики, скруббинг, Anycast;
- обнаружение: NetFlow/sFlow, логи WAF/балансировщиков, SIEM;
- смягчение: RTBH/FlowSpec, динамический rate‑limit, поведенческие правила;
- восстановление: выходные критерии, обратное переключение, анализ и план улучшений.
Сетевой периметр: где каждый pps на счету
На периметре ваша задача — не позволить вражескому трафику «прилипнуть» к вашей инфраструктуре. Anycast‑распределение рассеивает удар по нескольким точкам присутствия. Поддержка RTBH и FlowSpec у оператора связи даёт возможность гасить трафик ближе к источнику, не забивая ваши каналы. Скруббинг‑центры берут на себя тяжёлую очистку: весь подозрительный поток уходит по GRE/IPsec‑туннелю на фильтрацию и возвращается «промытой» струёй.
Полезный минимальный набор на периметре:
- Anycast‑входы для публичных сервисов и авторитативного DNS;
- договорённости с провайдерами: RTBH/FlowSpec, шаблоны BGP‑сообществ;
- CoPP/ACL для защиты плоскости управления маршрутизаторов и LB;
- stateless‑балансировщики с SYN‑cookies и лимитами CPS;
- управляемый доступ в админ‑сегменты, отдельный канал для out‑of‑band‑доступа.
Уровень приложений: сделать «дорогое» дешёвым
Основная мысль проста: чем меньше «дорогих» операций достигает ядра приложения и базы, тем устойчивее система при всплесках. Этого добиваются многоуровневым кэшированием (edge‑кэш, micro‑cache на 1–10 секунд для горячих путей), предварительными расчётами и материализованными представлениями, грамотным управлением параллелизмом (backpressure) и вводом деградационных профилей, когда при перегрузе пользователь получает упрощённый, но быстрый ответ.
WAF и антибот‑платформы помогают отсеивать аномальный трафик по поведенческим признакам: частоте запросов на ключ API/IP/ASN, сигнатурам TLS/JA3, отпечаткам клиента, заголовкам. Но важно сохранять баланс между защитой и UX: слишком агрессивные челленджи и CAPTCHA — прямые потери конверсии.
Что можно внедрить в кратчайшие сроки:
- микрокэширование «горячих» эндпоинтов и статики на границе;
- ограничение скоростей (token/leaky bucket) на IP/ключ/URI/метод;
- circuit breaker для внутренних API и БД, чтобы не допускать лавины;
- лимиты на размер тела запроса, тайм‑ауты и глубину пагинации;
- перевод тяжёлых экспортов/отчётов в асинхронные очереди;
- устранение «липких» сессий — фронты должны быть stateless для быстрого горизонтального масштабирования.
DNS как отдельный фронт
DNS часто становится единственной точкой отказа, поэтому относиться к нему стоит как к продукту первого класса. Нужны Anycast‑авторитативы в разных географиях и как минимум два независимых провайдера. Слишком длинные TTL мешают манёвру во время атаки, слишком короткие — увеличивают нагрузку и делают систему нервной. Важно измерять QPS, распределение RCODE, время ответа и долю SERVFAIL/NXDOMAIN, чтобы вовремя заметить аномалии.
Короткая памятка:
- разделяйте домены для статики, API и админки;
- держите два независимых авторитативных провайдера;
- выбирайте сбалансированные TTL для критичных записей;
- следите за QPS/latency/RCODE и настраивайте алерты раннего обнаружения.
Взаимодействие с провайдерами и облаками
Устойчивость невозможна без правильно оформленных отношений с операторами связи и поставщиками облачных анти‑DDoS/WAF‑решений. Пропишите, в каких случаях и как именно включаете RTBH/FlowSpec, какие префиксы допускаются к «чёрной дыре», какие пороговые значения являются триггерами. Не менее важна контактная матрица: кто отвечает ночью и в выходные, какова целевая скорость реакции и что входит в зону ответственности каждой стороны.
Договориться стоит заранее о следующем:
- сценариях перенаправления трафика в скруббинг‑центры и обратного вывода;
- порогах для автоматического включения фильтров и лимитирующих профилей;
- разделении трафика по доменам/подсетям, чтобы не «гасить» всё сразу;
- форматах отчётности и метриках SLA, по которым судят об эффективности защиты.
Наблюдаемость и ранняя сигнализация
Мониторинг — нервная система обороны. Он должен показывать, где именно бьют, каковы масштабы и как реагирует инфраструктура. Для сетевого слоя важны потоки NetFlow/sFlow/IPFIX с агрегацией по IP, ASN, портам и TCP‑флагам. На L7 — логи веб‑серверов/балансировщиков, коды ответов, размеры тел, TTFB и промахи кэша, а также поведенческие признаки пользователей и клиентов API.
Что обязательно вывести на боевые дашборды:
- bps/pps/cps и их аномалии по зонам и регионам;
- rps/qps, доля 4xx/5xx/429, время ответа и TTFB;
- топ‑пути и «дорогие» эндпоинты с их затратностью;
- распределение по IP/ASN/странам и необычным User‑Agent;
- состояние пулов соединений, файловых дескрипторов и очередей.
Реагирование на инциденты: от первых секунд до выхода из атаки
Когда срабатывает алерт, важно действовать по заранее написанному и проверенному сценарию. Хороший runbook краток, однозначен и содержит технические «кнопки» — команды/скрипты, которые быстро включают защитные меры. Ещё до инцидента стоит определить «клапаны» — упрощённые профили обслуживания для сохранения базовой функциональности под нагрузкой.
Базовая шкала действий:
- зафиксировать инцидент и собрать минимальные показатели (bps/pps/cps/rps);
- классифицировать атаку: L3/L4/L7, целевые домены и эндпоинты, географию и ASN;
- включить или усилить лимиты и поведенческие правила в WAF/бот‑менеджменте;
- при необходимости перевести префиксы в скруббинг или активировать FlowSpec/RTBH;
- временно отключить или упростить «дорогие» функции, включить деградационный профиль;
- масштабировать фронты, увеличить пулы и проверить «узкие горлышки»;
- поддерживать внешние коммуникации: статус‑страница, шаблонные уведомления и ответы поддержки.
После спада важно выходить из защитных режимов поэтапно, фиксируя влияние каждой отменённой меры. Затем следует пост‑мортем: что сработало, что нет, и какие изменения нужно внести в архитектуру, периметр и процессы обучения команды.
Тестирование и учения
Подготовка без практики не работает. Учения позволяют проверить, что команды действительно умеют пользоваться инструментами, а не просто «знают, что они есть». Тренироваться следует как в формате «настольных» сценариев, так и в реальных техокнах с согласованными нагрузочными испытаниями (легальными и безопасными для третьих лиц). Полезно периодически отключать один из DNS‑узлов или региональных входов, проверяя, как система переживает частичную деградацию.
Для плана учений достаточно:
- одного техокна в квартал для проверки перевода трафика в скруббинг и обратно;
- раз в месяц — настольного проговора runbook с фиксацией улучшений;
- регулярных «микро‑учений» on‑call: включение/выключение конкретных политик и правил.
Экономика и планирование ёмкости
Вопрос бюджета часто решающий. Но считать нужно не только стоимость подписки на анти‑DDoS и железо на периметре. Важно учитывать упущенную выручку, SLA‑штрафы, reputational damage, трудозатраты команды и эффект от деградации UX. Трезвая финансовая модель обычно показывает, что проактивные меры дешевле, чем «героическое тушение пожаров».
При планировании ёмкости обратите внимание на:
- несущую способность каналов и устройств в bps и pps, а не только «гигабиты»;
- устойчивость LB по новым соединениям (cps) и одновременным коннекциям;
- запасы по «дорогим» L7‑операциям и возможности их кэширования/предвычисления;
- сценарии быстрого расширения: дополнительный регион, новые фронты, договорённости с провайдерами.
Частые ошибки, которых легко избежать
Ошибки в защите от DDoS типично однообразны и потому особенно обидны. Самые распространённые: единый провайдер DNS или интернета, сессионность на фронтах, открытые «дорогие» эндпоинты без ограничений, узкая полоса для доступа к оборудованию в кризис,, чрезмерная любовь к CAPTCHA, отсутствие дашбордов и бодрых алертов, слишком длинные TTL для критичных DNS‑записей и игнор зависимостей внутренних сервисов.
Короткий перечень симптомов незрелости:
- «липкие» сессии на фронтах, из‑за чего горизонтальное масштабирование даёт мало эффекта;
- единая точка отказа в DNS или единственный оператор связи;
- экспорт/отчёты доступны анонимно или без лимитов и очередей;
- закрытая CoPP и слабые ACL на периметре;
- статус‑страница и шаблоны коммуникаций не готовы, команда узнаёт об инцидентах от пользователей.
Дорожная карта на 90 дней
Фреймворк внедрения удобно делить на три этапа по месяцу каждый. В первые 15–30 дней цель — базовая готовность: два независимых провайдера авторитативного DNS, проверка TTL критичных записей, включение базовых политик WAF и разумных лимитов на ключевые эндпоинты, настройка NetFlow/sFlow и L7‑логов, первые алерты по bps/pps/cps/rps и ошибкам 5xx/429. К этому же этапу относится подготовка runbook версии 1.0 и контактной матрицы с провайдерами.
Далее, в окне 30–60 дней, усиливается периметр и приложение: закрепляются договорённости по RTBH/FlowSpec и скруббингу, проверяются GRE/IPsec‑сценарии, на балансировщиках включаются SYN‑cookies и лимиты CPS, а в приложении внедряются микрокэш, circuit breaker, backpressure и деградационные ответы для «дорогих» функций. Полезно разделить домены на статику, API и админку, а также ограничить доступ туда, где это возможно.
Заключительные 30 дней посвящены зрелости и учениям: проводятся настольные и технические тренировки, уточняются WAF‑правила на основе реальных логов и вводятся поведенческие профили, автоматизируются быстрые переключения (скрипты для смены DNS/маршрутов, Terraform/Ansible для политик), готовится «боевой» дашборд и отчётность для бизнеса с ключевыми метриками MTTD/MTTR. Результатом становится понятная, повторяемая операционная рутина.
Небольшая «шпаргалка» по этапам:
- 0–30 дней: DNS×2, базовые лимиты и WAF, телеметрия и алерты, runbook 1.0;
- 30–60 дней: договорённости с провайдером, SYN‑cookies, микрокэш и деградация;
- 60–90 дней: учения, поведенческие профили, автоматизация, дашборды и отчётность.
Мини‑чеклист перед сезоном пиков
Чтобы быстро проверить готовность, пройдитесь по укороченному списку:
- два независимых авторитативных DNS‑провайдера с Anycast;
- действующие контакты и SLA с оператором связи, WAF/CDN и скруббинг‑центром;
- NetFlow/sFlow и L7‑логи сходятся в одну точку, алерты проверены ежемесячно;
- балансировщики выдерживают рост CPS, включены SYN‑cookies и лимиты;
- для «дорогих» эндпоинтов есть кэш, лимиты и деградационные ответы;
- runbook актуален, команда прошла учения в последние 90 дней.
Успешная защита от DDoS — это постоянная дисциплина: архитектура, периметр, процессы и люди. Многоуровневая модель, телеметрия и тренировки превращают даже мощные и «умные» атаки из катастрофы в управляемый инцидент. Сфокусируйтесь на том, чтобы дорогое стало дешёвым, а редкие ручные операции — автоматизированными. И тогда любой всплеск трафика будет восприниматься как ещё один сценарий из вашего runbook, а не как «чёрный лебедь».