Сайт может лечь совершенно исправным. Код не менялся, сервер не взломали, база на месте, но посетители видят тайм-ауты, API отвечает через раз, а корзина перестает оформлять заказы. Причина бывает прозаичной. В инфраструктуру приходит больше трафика, пакетов, соединений или тяжелых запросов, чем она способна обработать.
DDoS расшифровывается как distributed denial of service, распределенный отказ в обслуживании. В отличие от обычного DoS поток идет из множества источников. Ими могут служить зараженные роутеры и камеры, серверы, компьютеры, прокси-сети или другие узлы. При отраженных атаках злоумышленник вообще заставляет сторонние серверы отправлять ответы жертве. Главная цель одна. Исчерпать какой-нибудь ограниченный ресурс раньше, чем к нему доберется обычный пользователь.
Я бы не называла DDoS разновидностью взлома. Для отказа в обслуживании атакующему не обязательно получать пароль администратора, запускать код на сервере или читать базу данных. Но отсутствие взлома не делает инцидент безобидным. Недоступность сайта, платежной системы, API или личного кабинета сама по себе наносит ущерб.
Материал посвящен защите и диагностике. Проверять нагрузочные сценарии можно только на собственной инфраструктуре или с явного разрешения владельца. Не направляйте тестовый трафик на чужие сайты и сервисы. Соблюдайте законодательство своей страны, включая требования российского законодательства, правила хостинга и облачных платформ.
У DDoS нет одной кнопки. Ломают то место, которое закончится первым
Удобнее всего представить сайт как цепочку. Пользователь обращается к DNS, получает адрес, проходит через сеть, балансировщик или CDN, устанавливает соединение, отправляет HTTP-запрос, после чего приложение может обратиться к кэшу, базе данных, поисковому движку, файловому хранилищу или внешнему API.
У каждого участка есть предел. У канала ограничена пропускная способность, сетевое оборудование обрабатывает конечное число пакетов, сервер держит конечное число соединений, приложение располагает ограниченным процессорным временем и памятью, а база данных имеет ограниченный пул подключений. DDoS ищет самое дешевое для атакующего и самое дорогое для владельца место.
Поэтому я смотрю не на одну цифру «трафик», а минимум на три. bps показывает объем данных в секунду, pps число пакетов, rps число запросов к приложению. Две атаки одинаковой мощности в гигабитах могут вести себя совершенно по-разному. Миллионы коротких пакетов давят на сетевое оборудование, а сравнительно небольшой поток HTTP-запросов может положить приложение, если каждый запрос запускает дорогую операцию.
На сетевом уровне L3 типичный пример дает ICMP Flood. Огромное число IP-пакетов забивает канал или заставляет сетевую инфраструктуру тратить ресурсы на обработку. На транспортном уровне L4 встречаются UDP Flood и SYN Flood. Во втором случае сервер получает массу запросов на начало TCP-соединения и вынужден хранить состояние незавершенных соединений. Механизм SYN cookies может помочь именно против части SYN Flood, но к DNS amplification или обычному UDP Flood отношения почти не имеет.
Отражение с усилением работает иначе. Злоумышленник подменяет исходный IP-адрес в UDP-запросе и указывает адрес жертвы. Открытый DNS, NTP или другой подходящий UDP-сервис принимает небольшой запрос и отправляет более крупный ответ уже жертве. Получается неприятная арифметика. Атакующий тратит один объем трафика, а цель получает значительно больше. Заодно реальный источник прячется за серверами-отражателями. Подробно механику мы разбирали в материале про атаки на DNS.
На L7 атакующий уже разговаривает с сайтом на HTTP или HTTPS почти как обычный посетитель. Боты могут открывать поиск, вызывать API, отправлять форму входа, строить сложный фильтр каталога или обращаться к GraphQL. Главная страница при этом спокойно отдается из кэша, а несколько тысяч запросов к поиску заставляют приложение и базу данных работать на пределе.
Поэтому фраза «у нас стоит CDN» сама по себе почти ничего не гарантирует. CDN прекрасно отдает закэшированные картинки, стили и страницы. Запрос к /login, /api/search, /graphql или генерации отчета часто приходится передавать дальше. Если на границе нет фильтрации и ограничений, атакующий использует CDN как скоростную дорогу к исходному серверу.
Мы отдельно разбирали атаки уровня L7, где обычный подсчет гигабитов почти ничего не говорит о реальной нагрузке.
| Что атакуют | Что обычно растет | Где защищаться |
|---|---|---|
| Канал | bps | Провайдер, сеть очистки, Anycast |
| Сетевое оборудование | pps, число соединений | L3/L4-защита, балансировщик, провайдер |
| HTTP и HTTPS | rps, задержка, 4xx и 5xx | WAF, ограничение частоты, защита от ботов |
| Приложение и база | CPU, память, очереди, подключения к БД | Кэш, лимиты, очереди, изменение логики приложения |
| DNS | Запросы к авторитетным серверам | Распределенная DNS-инфраструктура, Anycast, защита провайдера |
Масштаб тоже больше нельзя оценивать по представлениям десятилетней давности. Терабитные сетевые атаки перестали быть экзотикой, а параллельно растет число атак на прикладной уровень. В статистике первого полугодия встречаются сотни атак мощнее 1 Тбит/с. Для небольшого сайта даже ничтожная доля такого потока окажется фатальной, если мусор дойдет до его канала.
Как я бы строила защиту сайта
Главный принцип очень простой. Плохой трафик нужно отбрасывать раньше, чем он доберется до дорогого ресурса. Фильтровать гигабитный UDP Flood средствами NGINX поздно, если сетевой канал уже заполнен. Блокировать тяжелый поиск только на уровне базы тоже поздно, если приложение уже потратило процессорное время и заняло соединение.
Первый слой дает провайдерская или облачная защита L3/L4. Здесь гасят объемные потоки, SYN Flood, UDP Flood и другие сетевые атаки. Второй слой образует обратный прокси или CDN. Третий дает WAF и защита от автоматизированного трафика. Четвертый слой остается внутри приложения, где разработчик ограничивает дорогие операции и не разрешает одному клиенту бесконечно запускать поиск, экспорт или восстановление пароля.
В разных экосистемах названия различаются. В Yandex Cloud сетевой DDoS Protection работает с L3/L4, а Smart Web Security защищает HTTP-уровень и позволяет подключить WAF и Advanced Rate Limiter. В AWS сетевую защиту строят вокруг Shield, а для HTTP используют CloudFront и AWS WAF. В Google Cloud похожую роль выполняют глобальный балансировщик и Cloud Armor. Для отдельного VPS логика остается той же, даже если сервисы называются иначе.
Самая частая архитектурная ошибка появляется уже после подключения защиты. Домен смотрит на обратный прокси, но исходный сервер продолжает принимать соединения от всего интернета. Если настоящий IP сохранился в старых DNS-записях, служебном поддомене, почтовой инфраструктуре или другой утечке, атакующий просто обходит защитный узел.
Я бы по возможности закрыла исходный сервер так, чтобы веб-порты принимали соединения только от доверенного прокси, балансировщика или сети защиты. Еще надежнее архитектура, где исходный узел вообще не имеет общедоступной точки входа для веб-трафика. После переноса имеет смысл проверить старые A- и AAAA-записи, забытые поддомены и сервисы, которые используют тот же IP.
Дальше я составила бы список дорогих адресов. Обычно туда попадают вход в аккаунт, регистрация, восстановление пароля, поиск, API, GraphQL, загрузка файлов, создание PDF, экспорт данных и любые операции, которые обращаются к внешним сервисам. Общий лимит «100 запросов в секунду на весь сайт» намного грубее отдельных правил для конкретных функций.
- Кэшировать. Все, что можно безопасно отдать без обращения к приложению, лучше отдавать раньше.
- Ограничивать. Для тяжелых адресов задавать отдельные пределы по клиенту, сессии, токену API или другому подходящему признаку.
- Удешевлять. Не выполнять дорогой поиск, экспорт или обращение к внешнему API без проверки входных параметров.
- Изолировать. Админки, базы, Redis, Elasticsearch, панели мониторинга и тестовые сервисы не должны торчать в интернет без необходимости.
- Защитить DNS. Недоступный авторитетный DNS сделает сайт недоступным даже при совершенно здоровом веб-сервере.
- Собирать метрики. Нужна нормальная картина bps, pps, rps, задержек, кодов ответа, активных соединений и нагрузки на базу до инцидента, а не после.
Для NGINX базовое ограничение запросов может выглядеть так. Цифры здесь служат примером, копировать их в рабочий проект без измерения нормальной нагрузки не нужно.
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/m;
server {
location = /login {
limit_req zone=login_limit burst=10 nodelay;
proxy_pass http://backend;
}
}У такого примера есть ловушка. Если NGINX находится за CDN или обратным прокси и не настроен на получение реального клиентского адреса от доверенного прокси, переменная адреса может указывать на сам прокси. Тогда все посетители попадут в один лимит и защита начнет атаковать собственных пользователей. Сначала нужно корректно настроить доверенные адреса прокси и модуль реального IP, только потом строить ограничения на клиента.
Еще одна ошибка связана с блокировкой по IP. Для небольшого бота правило работает прекрасно, для распределенной сети гораздо хуже. За одним адресом мобильного оператора или корпоративного шлюза могут находиться тысячи обычных людей, а ботнет способен прислать по одному запросу с десятков тысяч адресов. Поэтому современные правила комбинируют адрес, URI, метод, сессию, токен, репутацию сети и поведение клиента.
Что делать, когда атака уже началась
Во время инцидента я бы сначала выяснила, какой ресурс уперся в потолок. Резкий рост bps или pps указывает на сетевую часть. Огромное число SYN и незавершенных соединений заставляет смотреть на транспортный уровень. Нормальный канал вместе с ростом HTTP-запросов, CPU, времени ответа и обращений к базе больше похож на L7.
Если забит внешний канал, локальный firewall почти бесполезен. Пакеты уже приехали по линии связи и заняли пропускную способность. Нужна фильтрация у хостинга, оператора или внешнего центра очистки трафика.
При HTTP Flood я ищу не просто «плохие IP», а общую форму трафика. Какие URL выросли сильнее всего, какие методы используются, какая доля запросов доходит до приложения, падает ли коэффициент попаданий в кэш, растет ли число ошибок, сколько времени занимает запрос и что происходит с пулом соединений к базе.
После этого можно временно отключить особенно дорогую функцию, ужесточить лимиты, перевести часть страниц в статический режим, включить дополнительные проверки для браузерного трафика или запретить явно аномальные комбинации запросов. Для API интерактивная CAPTCHA часто не подходит, поэтому там полезнее лимиты по токенам, ключам, сессиям и маршрутам.
Не советую во время паники блокировать половину мира одной географической маской или менять все DNS-записи подряд. Геоблокировка имеет смысл только там, где география бизнеса действительно известна. Неосторожная смена DNS способна раскрыть исходный сервер, а кэшированные записи еще некоторое время продолжат вести часть клиентов по старому маршруту.
Автомасштабирование тоже не превращает плохую архитектуру в анти-DDoS. Дополнительные экземпляры приложения помогают выдерживать легитимные пики, но вредоносные запросы продолжают потреблять процессор, базу и платные ресурсы. Без фильтрации можно получить одновременно работающий сайт и очень неприятный счет.
Я бы заранее подготовила контакты хостинга и поставщика защиты, инструкцию переключения трафика, доступ к метрикам и короткий сценарий аварийного ограничения функций. Многие современные атаки развиваются быстрее, чем человек успевает прочитать уведомление, поэтому автоматическая постоянно включенная фильтрация полезнее героического ручного реагирования.
Три мифа, из-за которых защита разваливается
«Достаточно поставить WAF». Нет. WAF видит HTTP и HTTPS и полезен на L7. Если атакующий забил канал UDP-трафиком раньше, веб-запрос до WAF вообще не дошел. Нужны разные слои защиты.
«Достаточно увеличить сервер». Иногда запас CPU действительно спасает. Но канал, таблица соединений, база данных и сторонний API масштабируются по другим правилам. Атакующий обычно ищет ресурс, который увеличить труднее или дороже всего.
«Для отказа нужны огромный ботнет и сотни гигабит». Не всегда. Объемная DDoS-атака действительно берет масштабом, но отказ можно вызвать и асимметрией стоимости. Летом была раскрыта уязвимость HTTP/2 в Apache HTTP Server, получившая CVE-2026-49975. Специально сформированные запросы могли заставлять сервер выделять чрезмерный объем памяти. Исправление вошло в Apache HTTP Server 2.4.68, что можно проверить в официальном перечне уязвимостей. Такой случай относится прежде всего к DoS, а не классическому DDoS, но хорошо показывает принцип. Иногда опаснее не число байтов, а соотношение «дешевый запрос для клиента, дорогая работа для сервера».
Мой рабочий минимум для публичного сайта выглядит так. Сетевую атаку фильтрует инфраструктура до сервера, HTTP проходит через защитный край, исходный сервер нельзя вызвать напрямую, тяжелые функции имеют собственные ограничения, DNS не зависит от одного хрупкого узла, а команда видит нормальные показатели нагрузки и может сравнить их с аномалией.
Ни CDN, ни WAF, ни мощный VPS по отдельности не дают «защиту от DDoS». Надежность появляется только тогда, когда каждый слой отбрасывает нагрузку раньше, чем та достигает более дорогого слоя. Если выбирать одну задачу, с которой стоит начать сегодня, я бы проверила, можно ли обратиться к исходному серверу в обход защитного прокси. Открытый origin способен обнулить почти всю остальную работу.
Частые вопросы о DDoS
Чем DoS отличается от DDoS
DoS означает отказ в обслуживании и может исходить даже от одного источника. При DDoS нагрузка распределена между множеством источников или создается через множество сторонних узлов. Из-за распределения простая блокировка одного адреса обычно не решает проблему.
Можно ли полностью защитить сайт от DDoS
Абсолютной гарантии нет. Можно сильно повысить устойчивость, если фильтровать сетевые атаки до своей инфраструктуры, защищать L7 через WAF и ограничение запросов, скрыть исходный сервер и убрать узкие места приложения.
Поможет ли CDN против DDoS-атаки
CDN хорошо поглощает запросы к закэшированному содержимому и может служить частью распределенной защитной инфраструктуры. Динамические страницы и API требуют дополнительной фильтрации, а исходный сервер нужно закрыть от прямого доступа.
Защищает ли WAF от DDoS
WAF помогает против атак прикладного уровня L7 и способен фильтровать вредные HTTP-запросы. От объемного UDP Flood или другой атаки, которая забивает канал до обработки HTTP, нужен сетевой уровень защиты.
Как понять, что сайт атакуют, а не просто пришло много посетителей
Сравнивают текущий трафик с обычным профилем сайта. Смотрят bps, pps, rps, активные соединения, задержку, коды ответа, наиболее популярные URL, нагрузку на процессор и базу данных. Один всплеск посещаемости сам по себе не доказывает атаку.
Поможет ли блокировка IP-адресов
Против небольшого числа источников поможет. Против крупного ботнета или отраженной атаки эффективность быстро падает. На L7 лучше учитывать маршрут запроса, частоту, сессию, токен и другие признаки, а объемный трафик блокировать выше по сети.
Что первым проверить владельцу небольшого сайта
Проверьте, идет ли весь публичный трафик через CDN или защитный прокси, скрыт ли настоящий IP сервера, закрыты ли лишние порты, установлены ли лимиты на вход, поиск и API, а также доступны ли метрики нагрузки. Такой аудит часто находит самые опасные ошибки еще до первой атаки.
