Блог

Anti-DDoS: как выстроить защиту от DDoS-атак

2026-09-23 15:14
Из первой части мы уже знаем, что DDoS-атака может воздействовать на разные уровни инфраструктуры — от интернет-канала и сетевого оборудования до веб-приложения и базы данных. Поэтому защитить сервис одним инструментом не получится.
Для объёмных L3/L4-атак важно отфильтровать трафик до того, как он достигнет канала организации. Для L7-атак — анализировать сами запросы и ограничивать нагрузку на приложение. А чтобы атакующий не мог обойти защитный контур, необходимо учитывать архитектуру сервиса целиком: от точки входа трафика до origin-сервера, приложения и базы данных.
Одного универсального механизма защиты от DDoS нет. На практике используется несколько уровней, каждый из которых решает свою задачу.
1. Фильтрация трафика до узкого места
Для объёмных L3/L4-атак важно, чтобы фильтрация происходила до того, как вредоносный трафик заполнит канал организации.
Для этого используются провайдерские и облачные Anti-DDoS-сервисы, распределённые защитные контуры и другие решения, способные принять большой объём трафика, распознать атаку и передать дальше только необходимый трафик.
Именно здесь проявляется важное отличие между защитой от объёмных DDoS-атак и обычным WAF: WAF работает с HTTP/HTTPS на прикладном уровне, а сетевую перегрузку необходимо отсекать раньше.
CISA рекомендует организациям заранее оценивать пропускную способность инфраструктуры и рассматривать специализированные специализированных сервисов защиты от DDoS (DDoS mitigation services) для масштабных атак.
2. WAF для защиты приложений
WAF (Web Application Firewall) анализирует HTTP/HTTPS-запросы и позволяет применять правила к их содержимому и характеристикам.
С его помощью можно фильтровать подозрительные запросы, блокировать известные вредоносные шаблоны и ограничивать доступ к отдельным ресурсам.
Для DDoS-защиты WAF особенно полезен против L7-атак, когда проблема заключается не просто в количестве пакетов, а в том, какие операции выполняет приложение.
Например, запрос к статическому изображению и запрос, который запускает тяжёлую операцию в базе данных, могут одинаково выглядеть как HTTP-запросы, но создавать совершенно разную нагрузку.
3. Rate limiting
Rate limiting ограничивает интенсивность запросов.
Например, можно установить отдельные лимиты для:
  • всего сайта;
  • конкретного IP-адреса;
  • API;
  • отдельных URI;
  • операций авторизации;
  • ресурсоёмких запросов.
Это особенно важно для L7-атак: даже если запрос технически корректен, слишком большое количество таких запросов за короткий промежуток времени может перегрузить приложение.
При этом единый лимит на весь сайт не всегда оптимален. Для разных операций допустимая частота запросов может существенно отличаться. AWS рекомендует использовать как общий rate limit для HTTP flood, так и более строгие правила для отдельных URI и ресурсоёмких операций.
Традиционный rate limiting считает количество запросов в секунду (например, не более 5-10 запросов). Но современные адаптивные боты делают 1 запрос в 3 секунды, легко обходя лимиты. Поэтому современный rate limiting должен быть динамическим и поведенческим. Он анализирует аномальную сессию (например, если пользователь делает запросы 2 часа подряд без единой паузы на "почитать") и ограничивает её.
4. Anti-bot и проверка клиентов
Не каждый автоматизированный запрос является атакой, а не каждый вредоносный запрос можно определить только по IP-адресу.
Поэтому для веб-приложений могут использоваться механизмы обнаружения ботов, различные challenge-механизмы и анализ характеристик клиентских сессий.
Они помогают отличать автоматизированное поведение от обычной активности пользователей и особенно полезны там, где L7-атака имитирует реальные действия человека.
При этом Anti-bot не заменяет сетевую DDoS-защиту. Если канал уже переполнен, проверять пользователей на уровне приложения поздно.
5. CDN и кэширование
Часть запросов вообще не должна доходить до origin-сервера, то есть сервера, на котором хранятся оригинальные файлы, базы данных и программный код сайта или приложения.
Сеть дистрибуции содержимого (Content Delivery Network, CDN) позволяет отдавать кэшируемый контент с распределённых узлов, расположенных ближе к пользователям. Это снижает количество запросов, которые необходимо обработать исходной инфраструктуре.
Кэширование не является самостоятельной защитой от любого DDoS. Но оно может значительно уменьшить нагрузку на origin-сервер, особенно когда атакующий запрашивает ресурсы, которые можно обслуживать из кэша.
6. Защита origin-сервера
Даже хорошо настроенный WAF или CDN не поможет в полной мере, если атакующий может обойти защитный контур и обратиться непосредственно к origin.
Поэтому origin-сервер не должен оставаться без необходимости доступным из интернета напрямую.
Один из вариантов архитектуры:
Пользователь → DDoS-защита/CDN/WAF → origin-сервер
а не когда атакующий напрямую может обратиться к origin-серверу.
7. Балансировка нагрузки и распределение инфраструктуры
Если всё приложение находится на одном сервере или в одной точке отказа, DDoS может быстрее привести к полной недоступности сервиса.
Балансировка нагрузки позволяет распределять запросы между несколькими серверами или экземплярами приложения.
Распределённая архитектура сама по себе не предотвращает DDoS, но снижает зависимость от одного ресурса и может повысить устойчивость сервиса к нагрузке.
CISA также включает балансировку и распределение нагрузки между несколькими серверами или площадками в число мер, которые могут уменьшить влияние DDoS-атаки.
8. Мониторинг и базовый профиль нормального трафика
Чтобы понять, что происходит во время атаки, сначала нужно понимать, как выглядит нормальная работа сервиса.
Полезно отслеживать:
  • объём входящего трафика,
  • количество запросов в секунду,
  • распределение запросов по URI,
  • коды HTTP-ответов,
  • latency,
  • количество соединений,
  • нагрузку на CPU и память,
  • обращения к базе данных,
  • источники трафика,
  • изменения в поведении клиентов.
Резкий рост одного показателя не всегда означает, что идёт DDoS-атака. Например, всплеск трафика может быть связан с рекламной кампанией, публикацией новости или реальным ростом аудитории. Поэтому важно иметь базовый профиль нормальной нагрузки и сопоставлять сетевые и прикладные показатели.
9. План реагирования
Защита от DDoS — это не только технические средства.
До инцидента стоит определить:
  • кто принимает решение об изменении правил фильтрации,
  • кто связывается с интернет-провайдером или DDoS-провайдером,
  • какие контакты используются для экстренной связи,
  • какие сервисы являются критичными,
  • какие правила можно включить автоматически,
  • при каких условиях используется более жёсткая фильтрация,
  • как проверяется, что легитимный трафик продолжает проходить,
  • кто отвечает за коммуникацию с бизнесом.
CISA рекомендует заранее определить роли, каналы коммуникации и процедуры реагирования и восстановления.
Это особенно важно потому, что во время атаки цена каждого лишнего часа ручного согласования может быть высокой.

Почему защиту нужно тестировать заранее

Настроить Anti-DDoS во время атаки — крайне плохой выбор момента для экспериментов.
Правила фильтрации могут задевать легитимных пользователей. Слишком строгий rate limit способен заблокировать реальный всплеск спроса. Неправильно настроенный WAF может пропускать нежелательный трафик или, наоборот, блокировать нормальные запросы.
Поэтому защитный контур необходимо тестировать в штатном режиме.
Полезно заранее проверить:
  • какие типы трафика должны блокироваться,
  • какие запросы считаются легитимными,
  • какие лимиты допустимы для разных операций,
  • как работает WAF,
  • как быстро меняются правила,
  • куда приходят уведомления,
  • кто получает оповещения,
  • как работает взаимодействие с провайдером,
  • можно ли сохранить доступность критичных функций при повышенной нагрузке.

Как выглядит многоуровневая защита

В зрелой архитектуре разные механизмы не конкурируют друг с другом, а закрывают разные участки цепочки:
Интернет → Anti-DDoS / распределённый защитный контур → CDN / WAF → rate limiting / anti-bot → балансировщик → приложение → база данных
На каждом уровне решается своя задача:
  • Anti-DDoS принимает и отфильтровывает крупный объём сетевого трафика до того, как он перегрузит канал;
  • CDN и кэширование уменьшают количество запросов, доходящих до origin.
  • WAF анализирует веб-запросы и блокирует нежелательные или подозрительные обращения;
  • Rate limiting ограничивает интенсивность обращений к сервису и отдельным ресурсоёмким операциям;
  • Anti-bot помогает выявлять автоматизированное поведение;
  • Балансировка нагрузки распределяет оставшийся легитимный трафик между ресурсами приложения;
  • Мониторинг и автоматизация позволяют обнаруживать отклонения и оперативно применять необходимые меры.
При этом конкретный набор компонентов зависит от архитектуры сервиса, его критичности, объёма нормального трафика и потенциального масштаба атаки.
Главное правило: защищать нужно до того, как станет поздно
DDoS-атака проверяет не только возможности защитных средств, но и архитектуру самого сервиса.
Если единственное средство защиты — WAF на сервере, а проблема возникает на интернет-канале, фильтровать трафик уже поздно. Если origin-сервер доступен напрямую, атакующий может обойти CDN и WAF. Если для ресурсоёмкого API нет rate limiting, даже относительно небольшой объём запросов способен создать значительную нагрузку на приложение и базу данных.
Поэтому эффективная защита строится не вокруг одного инструмента, а вокруг нескольких уровней:
фильтрация крупного трафика → защита веб-приложения → ограничение интенсивности запросов → защита origin → распределение нагрузки → мониторинг и готовый план реагирования
Главный принцип здесь прост: DDoS нужно не только уметь отражать, но и быть готовым к нему до начала атаки.
Если требуется комплексно защитить веб-приложение и подобрать подходящую архитектуру защиты, обращайтесь в Крайон.