DDoS-атаки: полный разбор типов, векторов и методов защиты

Автор: Кирилл Бодров, технический аккаунт-менеджер EdgeCenter.

DDoS-атака (Distributed Denial of Service, распределённый отказ в обслуживании) — это попытка сделать сервис недоступным, исчерпав один из его ресурсов: полосу канала, вычислительную мощность, память, лимит соединений или пул подключений к базе данных. «Распределённый» означает, что трафик идёт одновременно с тысяч или миллионов устройств, и заблокировать каждый источник точечно невозможно.

Атаки принято делить по уровням модели OSI: объёмные (L3), протокольные (L4) и прикладные (L7). Механика, признаки и способы защиты у них разные, и универсального решения не существует. Разберём каждый класс.

Кто атакует и зачем

Мотив определяет и продолжительность атаки, и её интенсивность, и то, стоит ли ждать повторения. Понимание мотива помогает выбрать реакцию.

Отдельно стоит отметить: атаки стоят дёшево. Услуги booter- и stresser-сервисов, формально позиционируемых как «нагрузочное тестирование», продаются по цене бизнес-ланча в кафе. Это означает, что жертвой может стать проект любого размера, а не только крупный бизнес. «Мы слишком маленькие, чтобы нас атаковали» не работает как стратегия.

Откуда берётся трафик

Ботнеты из IoT-устройств. Основной источник объёмных атак. Чаще всего это устройства, которые подключены круглосуточно, редко обновляются и часто работают с заводским паролем: камеры видеонаблюдения, роутеры, сетевые накопители, телевизоры и т.п. Заражение происходит перебором учётных данных по открытым портам управления. Одно устройство даёт немного трафика, но сто тысяч устройств — уже терабиты.

Скомпрометированные серверы. Их меньше по количеству, но каждый даёт полосу на порядки больше домашнего роутера. Именно они формируют основную мощность в атаках-рекордсменах.

Открытые усилители. Как описано выше — не заражённые машины, а корректно работающие публичные сервисы, используемые как отражатели.

Прокси-сети и резидентные прокси. Отдельный класс, критичный для L7. Трафик выходит с обычных домашних адресов реальных пользователей, часто через приложения, которые продают трафик в фоне. Отличить такой запрос от легитимного по адресу невозможно в принципе — работает только поведенческий анализ.

Арендованная инфраструктура. Виртуальные машины в облаках, оплаченные краденой картой. Быстро разворачиваются, быстро блокируются провайдером, но окно в несколько часов у атакующего есть.

Важно понимать, что источник атаки почти никогда не является её автором. Поэтому блокировка по адресам — это борьба с симптомом, а жалобы владельцам адресов не дают быстрого эффекта.

Классификация атак по уровням

Атака на 500 Гбит/с и атака на 50 000 запросов в секунду требуют принципиально разных средств. Первую нельзя отфильтровать на вашем сервере — она забивает канал до него. Вторая может выглядеть как обычный трафик и пройти любой сетевой фильтр, но положить бэкенд.

Как измеряется мощность атаки

Цифры из новостей о «рекордной атаке» регулярно вводят в заблуждение, потому что смешивают три несопоставимые величины.

Почему их нельзя сравнивать. Атака в 2 Тбит/с из крупных пакетов может быть безобиднее для оборудования, чем атака в 50 Гбит/с из мелких: во втором случае пакетов в разы больше, а обработка каждого стоит одинаково. И обе они не важны, если вас кладёт 30 000 RPS к поиску при полосе в единицы гигабит.

Практический вывод для выбора защиты. Вопрос «какую мощность вы держите» некорректен без уточнения. Спрашивайте у провайдера три цифры отдельно: ёмкость сети в Тбит/с, производительность фильтрации в млн pps и способность обрабатывать L7-нагрузку в RPS. Провайдер, называющий только первую, отвечает лишь на треть вопроса.

Время реакции важнее абсолютных цифр. Атака, отражённая за 10 секунд, не заметна пользователям. Та же атака, отражённая за 10 минут, — это полноценный простой. Уточняйте, как измеряется время до начала фильтрации и что происходит в этот промежуток.

Объёмные атаки (L3): забить канал

Механика таких атак — прислать больше трафика, чем вмещает ваш канал. Что происходит с сервером, уже неважно: пакеты не доходят.

Самые популярные L3-атаки:

1. UDP flood — поток UDP-датаграмм на случайные порты. Сервер отвечает ICMP-сообщениями о недоступности порта, тратя ресурсы, а канал забивается входящим потоком.

2. ICMP flood — массированная отправка ping-запросов. Сегодня встречается реже, поскольку ICMP обычно ограничивают на границе сети.

3. Amplification и reflection. Самый эффективный класс объёмных атак и главная причина, почему рекорды мощности растут год от года. Механика:

1. Атакующий подделывает адрес источника в запросе, указывая ваш IP.
2. Отправляет короткий запрос на публичный сервер стороннего протокола.
3. Тот отвечает — но не атакующему, а вам, и ответ во много раз больше запроса.

Коэффициент усиления зависит от протокола:

Отсюда два вывода. Первый: атакующему не нужен большой ботнет — усилители сделают работу за него. Второй: вы можете быть не жертвой, а невольным соучастником, если у вас открыт наружу резолвер, NTP или memcached. Это стоит проверить независимо от рисков атаки на вас.

Ключевое ограничение защиты. Объёмную атаку невозможно остановить на своей стороне: трафик забивает канал провайдера ещё до вашего оборудования. Отсюда единственный работающий подход — фильтрация выше по потоку, у оператора или в сети провайдера защиты, плюс anycast, который размазывает атаку по десяткам точек вместо одной.

Протокольные атаки (L4): исчерпать состояния

Здесь исчерпывается не полоса, а внутренние структуры данных: таблица соединений, пул сокетов, буферы.

SYN flood — классика жанра. Атакующий шлёт SYN-пакеты, сервер отвечает SYN-ACK и переводит соединение в состояние ожидания подтверждения. Подтверждение не приходит. Полуоткрытых соединений накапливается столько, что таблица переполняется, и легитимные клиенты не могут подключиться.

Защита известна и эффективна: SYN cookies. Сервер не хранит состояние до получения финального ACK, а кодирует нужные данные в номер последовательности. Механизм встроен в современные ядра, но его нужно включить и правильно настроить лимиты.

ACK flood и RST flood — поток пакетов с установленными флагами, не относящихся к существующим соединениям. Каждый заставляет систему проверить таблицу состояний. Опасен для сетевого оборудования и файрволов с ограниченной производительностью обработки состояний.

Фрагментированные атаки — пакеты, разбитые на фрагменты, которые невозможно собрать. Ресурсы тратятся на попытки сборки и ожидание недостающих частей.

Особенность L4-атак: они измеряются не в гигабитах, а в пакетах в секунду. Атака в 100 миллионов pps может занимать скромную полосу, но положить оборудование, потому что нагрузка идёт на обработку каждого пакета, а не на передачу объёма.

Прикладные атаки (L7): самые опасные

Атака уровня приложения выглядит как обычные запросы к сайту. Именно поэтому она проходит сетевые фильтры и требует на порядок меньше ресурсов от атакующего.

HTTP flood — массовые GET или POST к вашим страницам. Ключевой момент — выбор цели. Атакуют самые важные и самые слабые места веб-сервиса: поиск по каталогу, фильтрация с множеством параметров, экспорт отчёта, формирование корзины, страницы без кеша. Тысяча запросов в секунду к поиску положит сервис, который выдерживает сто тысяч запросов к статике.

Slowloris и медленные атаки — обратный принцип: не много запросов, а мало, но очень медленных. Клиент открывает соединение и отправляет заголовки по одному байту с интервалами, не завершая запрос. Сервер держит соединение открытым в ожидании. Несколько сотен таких соединений исчерпывают пул воркеров веб-сервера. Трафика при этом почти нет — обычные метрики не показывают ничего необычного.

RUDY (R-U-Dead-Yet) —то же самое, но для POST: объявляется большой Content-Length, тело передаётся по байту.
Атаки на дорогие операции — отдельная категория, требующая знания вашего приложения: массовые попытки авторизации (каждая — вычисление хэша пароля), генерация PDF, отправка SMS-кодов, вызовы внешних API, регистрации.

DNS water torture — запросы к несуществующим поддоменам вашего домена: a1b2c3.example.ru, x9y8z7.example.ru. Кеширование не спасает — имена каждый раз новые, поэтому все запросы доходят до вашего авторитативного сервера и исчерпывают его.

Cache-busting: как атака проходит сквозь CDN

Это отдельный вектор атак, о котором стоит знать всем, кто считает, что CDN закрывает вопрос защиты.

Атакующий добавляет к каждому запросу уникальный параметр:

/catalog/?ATTACK_ID=8f3a91
/catalog/?ATTACK_ID=c40b27
/catalog/?ATTACK_ID=1de5f8

Если в ключе кеша учитывается строка запроса целиком, каждый такой URL — новый объект. Ни один не найдётся в кеше, все запросы пойдут на сервер-источник. CDN из щита превращается в прокси, добросовестно доставляющий атаку к вашему серверу, причём с распределением по всем узлам сети, что затрудняет диагностику.

Тот же приём работает с уникальными путями (/catalog/random123), заголовками, влияющими на ключ кеша, и произвольными cookie при неправильной конфигурации Vary.

Как закрывается:

• Явный список разрешённых query-параметров в ключе кеша вместо учёта всей строки. Всё, что не в списке, отбрасывается при формировании ключа. Это же полезно и в мирное время, так как позволит убирать мусор от UTM-меток и рекламных идентификаторов, поднимая cache hit ratio.
• Нормализация URL на edge-серверах: приведение к каноническому виду, сортировка параметров.
• Ограничение частоты по неизвестным параметрам — запросы с незнакомыми ключами получают отдельный, более жёсткий лимит.
• Мониторинг cache hit ratio как метрики безопасности. Резкое падение попадания в кеш при росте трафика — почти всегда либо cache-busting атака, либо серьёзная ошибка в конфигурации. Настройте на это алерт.

Атаки на API

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

Как реализовывается:

• Дорогие эндпоинты. Поиск с фильтрами, агрегирующие отчёты, экспорт данных. Один запрос — секунды работы базы.
• Пагинация с большими лимитами. Запрос вида ?limit=100000 заставляет выбрать и сериализовать огромный объём.
• Вложенные запросы GraphQL. Один синтаксически корректный запрос с глубокой вложенностью может породить экспоненциальное число обращений к данным. Закрывается это ограничением глубины и сложности запроса.
• Перебор на эндпоинтах авторизации. Каждая попытка — вычисление хэша пароля, операция намеренно медленная. Сотня попыток в секунду нагружает CPU сильнее, чем тысячи обычных запросов.

Общий принцип защиты API: лимиты должны быть не только по числу запросов, но и по стоимости операции.

Как отличить атаку от наплыва трафика и от собственной аварии

Ошибка в диагностике стоит дорого. При собственной аварии вы тратите время на защиту вместо починки, а при атаке — наоборот.

Самый быстрый практический маркер — расхождение между трафиком и бизнес-метриками. Если запросов в десять раз больше обычного, а заказов столько же или меньше, это не клиенты.

Второй маркер — доля запросов к статике. Живой браузер грузит CSS, шрифты, картинки, favicon. Бот-однодневка запрашивает только целевой URL. Резкое падение доли статики при росте общего трафика — сильный признак атаки. 

Отраслевая специфика: кого, когда и как атакуют

Атакуют то, что дороже всего обходится вам, а не то, что проще технически. Поэтому первый шаг подготовки — понять, какие ваши эндпоинты самые дорогие по ресурсам, и защитить в первую очередь их.

Методы защиты и их границы

Правильная архитектура защиты — многослойная: объёмные атаки отсекаются в сети провайдера, протокольные — на границе, прикладные — на уровне WAF и логики приложения. Ни один слой не заменяет остальные. 

Механики проверки: что такое challenge и чего он стоит

Когда трафик неотличим от легитимного по формальным признакам, остаётся проверить, человек ли на другом конце. Механик несколько, и они сильно различаются по цене для пользователя.

Правило применения: механики выстраиваются лестницей, а не включаются все сразу. Обычный трафик проходит без проверок, подозрительный получает лёгкую проверку, явно вредоносный — жёсткую. Включать капчу для всех — решение, при котором вы теряете больше клиентов, чем атакующий смог бы отнять.

Отдельно про поисковых роботов. Любая проверка, требующая исполнения JavaScript, для них — препятствие. Заявленный User-Agent подделывается тривиально, поэтому проверять нужно обратным DNS-запросом: адрес должен разрешаться в имя официального домена поисковой системы, а прямой запрос по этому имени — возвращать исходный адрес. Список официальных адресов поисковики публикуют — используйте его.

Как устроена профессиональная фильтрация

Понимание механики помогает задавать провайдеру правильные вопросы.

Центр фильтрации — площадка с оборудованием фильтрации, через которую пропускается трафик. Атакующий трафик отбрасывается, легитимный доставляется к вам. Фильтрация многоступенчатая: сначала отбрасывается заведомо мусорное по формальным признакам, затем работают сигнатуры известных векторов, затем поведенческий анализ, и только в последнюю очередь — конкретные правила, способные ошибаться.

Два режима подключения:

Для сервисов, где простой стоит дорого, always-on почти всегда оправдан. On-demand разумен там, где короткая недоступность приемлема.

Трафик попадает на фильтрацию двумя основными способами:

• Анонс префикса по BGP. Провайдер защиты анонсирует вашу сеть, трафик приходит к нему, очищается и возвращается к вам туннелем. Требует наличия собственной автономной системы и блока адресов — вариант для крупных инфраструктур.
• Проксирование по DNS. Ваш домен указывает на адреса провайдера, трафик приходит к нему как к обычному обратному прокси. Не требует своей AS, подключается за минуты. Именно так работает защита в связке с CDN.

Что спросить у провайдера защиты до подписания договора:

• Ёмкость сети, производительность фильтрации в PPS, обработка L7-трафика в RPS — три цифры отдельно.
• Режим подключения и время до начала фильтрации.
• Как обрабатывается зашифрованный трафик: анализ L7-трафика требует терминации TLS, и нужно понимать, где и как это происходит.
• Что происходит при превышении заявленной мощности — фильтрация или блокировка ресурса.
• Есть ли ограничение по числу инцидентов в месяц и по объёму очищенного трафика.
• Как выглядит отчёт по инциденту и в какие сроки он предоставляется.
• Порядок эскалации и время реакции дежурной смены.

Цена ошибки: когда защита вредит больше атаки

Раздел, который редко пишут, но который стоит дороже всех остальных.

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

Слишком агрессивный rate limiting. Лимит в 30 запросов в минуту с одного IP выглядит разумно — до тех пор, пока не вспомнить, что за одним NAT-адресом может сидеть офис на 200 человек, весь мобильный оператор в регионе или корпоративный прокси. Все они получают отказ.

Обязательный JS-challenge для всех. Ломает всё, что не является браузером: мобильные приложения, интеграции по API, вебхуки платёжных систем, мониторинг, поисковых роботов.

Блокировка по геолокации «на всякий случай». Отсекает клиентов в поездках, пользователей корпоративных VPN и часть мобильного трафика, где выходной адрес может принадлежать другой стране.

Блокировка поисковых роботов. Самое коварное последствие: сайт работает, клиенты довольны, а через две-три недели обваливается органический трафик. Связь с настройками защиты к этому моменту уже неочевидна.

Как этого избежать:

1. Любое новое правило — сначала в режиме мониторинга. Неделю смотрите, кого бы оно заблокировало, прежде чем включать блокировку.
2. Проверяйте поисковых роботов по обратному DNS, а не по User-Agent, который просто подделывается. Прямая и обратная запись должны сходиться.
3. Ведите список исключений для интеграций, вебхуков и мониторинга до включения защиты, а не после первого инцидента.
4. Включайте защиту постепенно, по одному классу правил, с интервалом в несколько дней. Иначе при падении метрик вы не поймёте, какое правило виновато.
5. Держите наготове быстрый откат. Возможность отключить конкретное правило за минуту, не трогая остальные.

Если после включения защиты упала конверсия, а не только «плохой» трафик, значит, вы перестарались. Атака кончится, а потерянные клиенты и просевшая индексация останутся.

Сколько стоит защита и как обосновать бюджет

Модели тарификации у провайдеров различаются, и сравнивать предложения «в лоб» обычно не получается.

Как обосновать бюджет перед руководством. Рекомендуем делать расчёты через стоимость простоя:

1. Определите стоимость часа недоступности: недополученная выручка, простой сотрудников, стоимость восстановления и отток клиентов.
2. Оцените вероятную длительность инцидента без защиты. Реалистично: несколько часов на первой атаке, потому что часть времени уйдёт на диагностику и организационные вопросы.
3. Сопоставьте с годовой стоимостью защиты.

На большинстве коммерческих проектов расчёт показывает, что защита окупается одним предотвращённым инцидентом. Это тот аргумент, который работает с финансовым директором, в отличие от рассказов о рекордных атаках в новостях.

Что почти всегда недооценивают в расчёте: репутационные потери и стоимость авральной работы команды. Ночная эскалация с привлечением половины отдела стоит дороже, чем кажется, и происходит за счёт запланированных задач.

Подготовка: что сделать до атаки

Половина успеха определяется тем, что сделано заранее. Во время инцидента настраивать поздно.

Скройте адрес сервера-источника. Если реальный IP сервера известен, атака может пойти мимо защиты. Закройте входящие соединения файрволом, разрешив только сети провайдера защиты. Проверьте, не утёк ли адрес через старые DNS-записи, заголовки исходящей почты, публичные логи сертификатов и забытые поддомены.

Настройте мониторинг с алертами. Проверяйте запросы в секунду, долю ошибок 5xx, время ответа, число активных соединений, долю запросов к статике. Алерты должны срабатывать до того, как сервис ляжет.

Снизьте TTL DNS-записей заранее или держите его умеренным. Если понадобится экстренно переключить трафик, длинный TTL растянет переключение на часы.

Опишите runbook. Кто принимает решение об эскалации, у кого контакты провайдера и оператора, в каком порядке включаются меры, кто пишет клиентам. Документ должен быть на одну страницу и доступен без VPN.

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

Проверьте, что вы не усилитель. Убедитесь, что наружу не открыты DNS-резолвер, NTP, memcached, SNMP.

Проведите нагрузочное тестирование. Знать свой потолок нужно заранее.

Как проверить, что защита действительно работает

Настроенная, но ни разу не проверенная защита — это предположение, а не факт.

Что тестируется своими силами:

• Скрыт ли сервер-источник. Попробуйте обратиться к серверу напрямую по IP с внешнего адреса. Ответ должен не приходить. Проверьте также поддомены и почтовые записи.
• Работают ли лимиты. Отправьте серию запросов с одного адреса выше установленного порога и убедитесь, что срабатывает ограничение, а сообщение об этом понятно пользователю.
• Не заблокированы ли нужные клиенты. Проверьте с мобильного интернета разных операторов, из корпоративной сети за общим NAT, через мобильное приложение, через API-интеграцию, через официального поискового робота.
• Держит ли приложение заявленную нагрузку. Проведите нагрузочное тестирование на собственной инфраструктуре, по согласованию с провайдером и в оговорённое окно.
• Отрабатывает ли runbook. Проведите учебную тревогу. Соберите команду, пройдите процедуру эскалации, засеките время до контакта с провайдером. Обычно именно здесь обнаруживаются устаревшие телефоны и отсутствие доступов у дежурного.

Что проверить у провайдера защиты: фактическое время до начала фильтрации, поведение при превышении заявленной мощности, полноту отчётности по инциденту. Это запрашивается как часть приёмки услуги — попросите отчёт по последнему учебному или реальному инциденту.

Что делать во время атаки

1. Подтвердите, что это атака. Пройдите по таблице признаков выше. Убедитесь, что это не собственная авария и не удачная рекламная кампания.
2. Определите класс. Забит канал или растёт нагрузка на приложение при нормальной полосе? От этого зависят все дальнейшие действия.
3. Эскалируйте по runbook. Провайдер защиты, оператор связи — у них больше данных и инструментов.
4. Включайте меры от мягких к жёстким. Rate limiting, затем challenge для подозрительного трафика, затем блокировки. Не начинайте с самой жёсткой.
5. Сохраняйте логи. Они понадобятся для настройки правил и для разбора после инцидента.
6. Сообщите клиентам. Короткое честное уведомление лучше молчания. Здесь вам понадобится статус-страница на отдельной инфраструктуре, по другому адресу.
7. Не меняйте всё сразу. Одно изменение — оценка эффекта. Иначе вы не поймёте, что помогло.

Что делать после атаки

• Постмортем без поиска виновных: что произошло, когда заметили, что сделали, что сработало, что нет.
• Донастройка правил по собранным логам — теперь у вас есть реальные данные о профиле атаки.
• Проверка побочного ущерба: не заблокированы ли поисковые роботы, не сломались ли интеграции, вернулась ли конверсия к норме.
• Обновление runbook по факту того, чего в нём не хватило.
• Оценка потерь: сколько стоил простой.

Часто задаваемые вопросы

Что такое DDoS-атака? Это попытка сделать сайт или сервис недоступным, отправив на него столько запросов, что он перестаёт справляться. Запросы при такой атаке идут одновременно с тысяч или миллионов устройств по всему миру, поэтому заблокировать один источник невозможно.

Чем DoS отличается от DDoS? DoS-атака ведётся с одного источника, DDoS — с множества. Разница в защите: одиночный источник блокируется по адресу за секунды, распределённую атаку так остановить нельзя, потому что адресов тысячи и часть из них принадлежит заражённым устройствам обычных пользователей.

Как понять, что идёт DDoS-атака? Главный признак — расхождение между трафиком и бизнес-показателями: запросов кратно больше обычного, а заказов столько же или меньше. Дополнительно: резкое начало, нетипичная география, концентрация запросов на одном-двух URL, падение доли запросов к статике, однообразные заголовки.

Что такое L3-, L4- и L7-атаки? Это классификация по уровням модели OSI. L3 — объёмные атаки, забивающие канал, измеряются в гигабитах в секунду. L4 — протокольные, исчерпывающие таблицы соединений, измеряются в пакетах в секунду. L7 — прикладные, нагружающие само приложение и базу данных, измеряются в запросах в секунду. Останавливаются они разными средствами.

Защищает ли CDN от DDoS-атак? Частично. CDN скрывает адрес origin-сервера, распределяет объёмную атаку по множеству узлов и поглощает запросы к кешируемым ресурсам. Но атаку на некэшируемые страницы (поиск, корзину, личный кабинет) CDN не остановит. Полноценная защита требует специализированной фильтрации на L3-L4 и WAF на L7.

Можно ли защититься от DDoS-атак своими силами? От простых атак — частично: включить SYN cookies, настроить лимиты, ограничить частоту запросов, закрыть лишние порты. От объёмной атаки — нет. Она забивает канал провайдера ещё до вашего оборудования, и фильтровать её нужно выше по потоку, в сети оператора или провайдера защиты.

Что такое amplification-атака? Это способ многократно усилить мощность атаки. Атакующий отправляет короткие запросы на публичные серверы DNS, NTP или memcached, подделав адрес источника на адрес жертвы. Серверы отвечают жертве, причём ответ во много раз больше запроса. Небольшой ботнет генерирует таким образом атаку в сотни гигабит.

Почему нельзя просто заблокировать атакующие IP-адреса? Их слишком много, и они постоянно меняются, а часть принадлежит заражённым устройствам реальных людей и компаний, поэтому блокируя их, вы отсекаете и потенциальных клиентов. Кроме того, при объёмной атаке трафик уже забил канал: блокировка на вашей стороне ничего не изменит, потому что пакеты всё равно доходят до границы сети.

Может ли защита от DdoS-атак навредить сайту? Да, и это частая проблема. Слишком жёсткий rate limiting отсекает офисы и мобильных операторов за общим NAT-адресом, обязательный JS-challenge ломает мобильные приложения и API-интеграции, а неправильная проверка ботов блокирует поисковых роботов — и через несколько недель обваливается органический трафик. Поэтому любое правило сначала включают в режиме мониторинга.

Сколько длится типичная DDoS-атака? От нескольких минут до нескольких суток. Короткие атаки часто используют как разведку — проверить, есть ли защита и как она реагирует. Многие атаки идут волнами: несколько интенсивных периодов с паузами, что осложняет диагностику и провоцирует преждевременное отключение защиты.