или заполните форму
DEVops
Как защитить сайт от DDoS-атак и не заблокировать клиентов: разбор на трех кейсах
Эдуард Грехов
Руководитель DevOps-направления KISLOROD
Защитить сайт от DDoS-атак без риска заблокировать клиентов можно только при многоуровневой фильтрации и настройке правил под конкретный профиль трафика. Во втором квартале 2026 года HTTP-флуд оставался самым распространенным вектором DDoS-атак и составлял 46,8% зафиксированных атак, по данным Qrator Labs. Но одна атака может сочетать несколько векторов, и универсальной настройки защиты нет.
В этой статье разберем, как защитить сайт от DDoS-атак и не заблокировать вместе с ботами покупателей, поисковых роботов и интеграции. На трех реальных кейсах покажем, как отличить атаку от нормального трафика, выбрать уровни фильтрации и сохранить доступ к критически важным функциям сайта.
Содержание
- Что такое DDoS-атака
- Как защитить сайт от DDoS: определить нормальный трафик
- Кейс: как поведение выдало разведку до основной атаки
- Защитить сайт от DDoS-атак на сетевом и прикладном уровнях
- Кейс: в одном периоде сработали HTTP- и сетевые фильтры
- Настроить правила отдельно для разных ресурсов
- Кейс: защитить сайт от DDoS-трафика, который имитировал браузеры
- Что делать, если DDoS-атака уже началась
- Чек-лист: как подготовить сайт
- Частые вопросы: защита сайта от DDoS
Что такое DDoS-атака
При DDoS-атаке сайт или сервер заваливают запросами с множества устройств, чтобы он перестал отвечать обычным пользователям. Одни атаки забивают канал и занимают все доступные соединения. Другие целятся в самые «тяжелые» функции сайта — например, поиск, авторизацию, API или корзину. Поэтому при защите важно смотреть не только на общий объём трафика: один запрос может почти не нагружать систему, а другой — запускать сразу несколько операций и требовать гораздо больше ресурсов.
1. Как защитить сайт от DDoS: определить нормальный трафик
Для каждого сайта аномальная нагрузка начинается со своей цифры. Для корпоративного сайта 100 запросов в секунду могут быть атакой, для интернет-магазина во время распродажи — обычным трафиком. Одного RPS для оценки мало. Нужно смотреть, откуда идут запросы, к каким страницам обращаются пользователи и как меняется трафик в течение дня.
Перед настройкой фильтров мы собираем профиль трафика:
- среднюю и пиковую нагрузку;
- географию посетителей;
- самые нагруженные URL;
- количество запросов к статике, динамическим страницам и API;
- периоды всплесков во время распродаж, рекламных кампаний и релизов;
- данные о платежных системах, службах доставки, CRM и других интеграциях.
Следующий шаг — определить функции, которые должны работать во время атаки. Для интернет-магазина это авторизация, поиск, корзина и оплата. Каталог можно временно отдавать из кэша, если это предусмотрено архитектурой. Заблокированное уведомление от платежной системы уже создаст проблему: оплаченный заказ останется в статусе «ожидает оплаты».
По этим данным мы настраиваем фильтры. На части страниц ставим CAPTCHA, для других задаем собственные лимиты. API и внешние интеграции защищаем с помощью проверки подписи, mTLS или разрешенных диапазонов IP-адресов. Тогда сайт принимает заказы даже во время атаки.
Кейс: как поведение выдало разведку до основной атаки
Клиент — интернет-магазин автотюнинга с доставкой по России. Покупатели — автомобилисты, которые подбирают детали под конкретную модель: от компонентов двигателя и турбонаддува до подвески, тормозов и внешнего тюнинга. Сайт принимает заказы круглосуточно, чтобы это обеспечить, нужно отсечь ботов и сохранить доступ для покупателей.
Что произошло
За час модуль CAPTCHA_WEB зарегистрировал больше 90 подозрительных запросов. IP-адреса были зарегистрированы в 15 странах, среди них Бангладеш, Бразилия, Пакистан, Венесуэла и Узбекистан. Геолокация показывает расположение узла, с которого пришел запрос: бот может работать через прокси или зараженное устройство.
Запросы приходили с разными значениями Host:
- lewis.tuningshop.kz;
- decorativ.tuningshop.kz;
- www.git.gitlab.mail.tuningshop.
Таких хостов в конфигурации проекта не было. Последовательный перебор имен походил на автоматическое сканирование виртуальных хостов. Бот проверяет, какие адреса принимает сервер и как на них отвечает. Это не DDoS-атака, но уже разведка инфраструктуры.
Что сделали
BitNinja отправляла подозрительные IP в challenge list. Посетитель мог пройти CAPTCHA и вернуться на сайт, автоматический клиент оставался на странице проверки. Такой сценарий позволяет не блокировать адрес сразу и снижает риск ложных срабатываний. Подробнее о challenge list в документации BitNinja.
В контрольной выборке 85 из 90 IP остались в challenge list. Еще пять событий с адреса 20.63.63.128 система записала в режиме Log only. Мы сохранили этот трафик для наблюдения и посмотрели, какие хосты запрашивает клиент и как часто повторяет обращения.
После разбора мы изменили правила:
- добавили подозрительные хосты в правила блокировки;
- настроили ограничение по числу неудачных проверок за короткий период;
- усилили фильтрацию для географии.
Результат
BitNinja автоматически отсекла 90% бот-трафика, при этом для обычных посетителей остался доступ к магазину. С помощью перебора несуществующих хостов смогли заметить разведку до основной атаки. После разбора мы добавили эти хосты в правила блокировки, ограничили повторные неудачные проверки CAPTCHA и усилили фильтрацию по географии.
Что рекомендуем бизнесу
Число заблокированных IP само по себе мало говорит о качестве защиты. Запросите у подрядчика сценарий атаки: какие адреса перебирали боты, на каком уровне их остановили и могли ли под фильтр попасть клиенты или интеграции.
2. Защитить сайт от DDoS-атак на сетевом и прикладном уровнях
DDoS-атаки различаются не только мощностью. Они расходуют разные ресурсы, поэтому и останавливать их нужно на разных участках.
WAF, или межсетевой экран для веб-приложений, видит HTTP-запрос и может отличить обращение к корзине от загрузки картинки. Но он не заменяет сетевую защиту от потока пакетов. Сетевой фильтр, в свою очередь, способен поглотить SYN-флуд, но не знает, что тысяча формально корректных запросов к поиску запускает дорогой запрос к базе данных.
Многоуровневая защита — не обязательно три подписки у разных поставщиков. Нужны разные функции: фильтрация на сетевом уровне, анализ HTTP-трафика, защита приложения и разгрузка основного сервера. Их может предоставлять один подрядчик, несколько сервисов или сочетание облачной защиты с собственным WAF. Резервный провайдер оправдан, если простой обходится дороже дополнительной инфраструктуры и команда действительно проверяет переключение.
Кейс: в одном периоде сработали HTTP- и сетевые фильтры
Клиент — бренд нижнего белья с интернет-магазином и доставкой по России. Основная аудитория — женщины, которые покупают базовое белье, модели для особых случаев, купальники и одежду для дома. В каталоге также есть мужские и детские коллекции. Через сайт покупатели выбирают, оплачивают и отслеживают заказы.
Что произошло
На сайте производителя белья StormWall зафиксировал за неделю более 250 инцидентов с IP-адресов из 35 стран.
Фрагмент журнала блокировок StormWall
Фрагмент журнала блокировок StormWall
На превышение лимита RPS пришлось 36% срабатываний, на географические правила — 32%, на SYN-флуд — 10%. Остальные события обнаружили другие детекторы.
Каждый сигнал указывал на свой тип нагрузки. Частые HTTP-запросы нагружали приложение, SYN-флуд создавал незавершённые TCP-соединения, а географический фильтр отсекал трафик из регионов, где компания не работает.
Как обнаружили атаки
StormWall отслеживал потоки в реальном времени через FlowSense. В мониторинге отдельно отображались:
- RPS — число HTTP-запросов в секунду;
- PPS — число сетевых пакетов в секунду;
- BPS — объём трафика в битах в секунду.
По этим показателям команда видела интенсивность атаки и уровень, на котором росла нагрузка. Если IP превышал заданный порог — например, 20 запросов в секунду, — система блокировала его автоматически.
Что сделали
Для прикладного уровня настроили разные лимиты RPS. Кэшируемая статика выдерживает больше запросов, поэтому для неё установили высокий порог. Для динамических страниц, которые сильнее нагружают сервер, — более строгий.
Запросы из регионов, где компания не работает, автоматически блокировала GeoIP-фильтрация.
Против SYN-флуда использовали Triple Filter. Трафик последовательно проходил через пограничные маршрутизаторы, аппаратные и Stateful-фильтры. Такая схема отсекала сетевую атаку до того, как она могла занять ресурсы сервера.
Что рекомендуем бизнесу
В договоре с подрядчиком проверяйте конкретный маршрут трафика, чтобы были ответы на вопросы, кто принимает сетевой флуд, где проверяются HTTP-запросы и что произойдет, если атакуют API, а не главную страницу.
3. Настроить правила отдельно для разных ресурсов
Единый лимит на весь сайт удобен только на этапе презентации. В рабочей системе он либо слишком мягкий для дорогих операций, либо слишком строгий для массовой статики.
Запрос картинки обычно дешевле поиска с фильтрами, который обращается к нескольким таблицам базы данных. Авторизация и восстановление пароля требуют более строгих ограничений из-за риска перебора. API партнера может отправлять много запросов с одного адреса и выглядеть как бот, хотя от него зависит оформление заказа.
Поэтому правила задают как минимум по четырем признакам:
- Ресурс. Статика, каталог, поиск, авторизация и API получают разные лимиты.
- Клиент. Для авторизованного пользователя, партнерского сервиса и неизвестного IP действуют разные сценарии.
- Поведение. Важна не только частота, но и последовательность действий: какие URL запрашивает клиент, выполняет ли JavaScript, проходит ли проверку.
- Стоимость запроса. Чем больше ресурсов приложения расходует операция, тем раньше система должна ограничить аномальную активность.
Лимит запросов по одному IP не останавливает распределенную бот-сеть: каждый узел может оставаться ниже порога. Поэтому ограничения дополняют репутацией адресов, поведенческими признаками, фильтрацией ASN и проверкой на уровне приложения. Блокировать ASN целиком стоит только после проверки: за одним номером автономной системы могут находиться и боты, и реальные пользователи.
Кейс: защитить сайт от DDoS-трафика, который имитировал браузеры
Клиент — интернет-магазин сантехники. В каталоге больше 80 тыс. позиций.
Что произошло
За полтора месяца DDoS-Guard зафиксировал на сайте магазина сантехники десятки миллионов HTTP-запросов. Среди самых востребованных адресов оказались не страницы каталога, а небольшие статические файлы:
- /favicon.ico — 126 тыс. запросов;
- /26.jpg, /vk.jpg и /ok.jpg — от 30 до 60 тыс. запросов к каждому.
Основной объём трафика пришёл из трёх стран:
Как обнаружили ботов
Запросы не выглядели подозрительно по User-Agent: клиенты представлялись обычными браузерами Chrome, Firefox и Safari. На эти данные нельзя полагаться — бот может указать любое название браузера.
DDoS-Guard считает HTTP-запросы и анализирует дальнейшее поведение клиента: загружает ли он связанные ресурсы, переходит ли между страницами, сохраняет ли cookies и как часто обращается к одним и тем же файлам. По совокупности признаков система определила, что 97% запросов к статике поступали от ботов.
Наибольший объем бот-трафика пришёл из трех автономных систем:
- AS25159 — 12,4 млн запросов;
- AS8359 — 1,7 млн;
- AS12389 — 1,3 млн.
Что сделали
Повторные запросы к одним и тем же изображениям не должны каждый раз доходить до основного сервера. Мы настроили кэширование статики на прокси: защитный контур сохранял файл после первого обращения и дальше отдавал его самостоятельно.
Дополнительно настроили фильтрацию по источникам и отдельные лимиты для статических URL. Бот-трафик остался на защитном контуре, а основной сервер продолжил обслуживать покупателей.
Результаты
Защиту собрали из трех частей. Повторные запросы к изображениям принимал прокси: после первого обращения он сохранял файл в кэше и дальше отдавал его без участия основного сервера. Источники бот-трафика блокировали по ASN, а для статических URL установили отдельные лимиты запросов.
За полтора месяца защитный контур отсек 20,6 млн запросов. Сайт не упал, основной сервер не тратил ресурсы на повторную отдачу одних и тех же файлов и продолжал обслуживать покупателей.
Что рекомендуем бизнесу
Если атака направлена на статику, наращивание мощности сервера лечит следствие. Сначала нужно вынести повторяемые ответы в кэш и проверить, доходит ли подозрительный трафик до основного сервера. Полезная бизнес-метрика здесь — доступность сайта и объем нагрузки, который защита сняла с основной инфраструктуры.
Что делать, если DDoS-атака уже началась
Если сайт уже испытывает аномальную нагрузку, определите, какой ресурс перегружен и до какого уровня доходит вредоносный трафик. Не рекомендуем сразу блокировать большие диапазоны IP или целые страны: это может затронуть клиентов, поисковых роботов и внешние интеграции.
- Проверьте доступность сайта и рост 5xx/тайм-аутов.
- Сравните текущие RPS, PPS и BPS с обычным профилем.
- Определите наиболее нагруженные URL и типы запросов.
- Проверьте источники трафика, ASN и географию.
- Посмотрите, доходит ли подозрительный трафик до origin-сервера.
- Включите подходящий уровень фильтрации: rate limiting, challenge, WAF или сетевую очистку.
- Проверьте работу авторизации, корзины, оплаты и API-интеграций.
- После стабилизации сохраните логи и скорректируйте правила защиты.
Главная задача во время атаки — сохранить работоспособность критических функций сайта для реальных пользователей.
Чек-лист: как подготовить сайт
Один всплеск трафика не доказывает атаку. Причин может быть много, например, рекламная кампания или сбой приложения. Но если вы зафиксировали несколько аномалий, которые появились одновременно и не объясняются событиями бизнеса, это повод подключить DevOps-команду.
Проверьте:
- Как сайт открывается у пользователей. Страницы загружаются дольше обычного, появляются тайм-ауты, ошибки 502 или 503. Картинки, стили и шрифты могут не загружаться.
- Как изменилось количество запросов. В логах сервера, CDN или панели защиты резко вырос RPS — число запросов в секунду. Сравнивать его лучше с показателями за тот же день недели и время суток, а не с универсальной «нормой».
- Не вырос ли сетевой трафик. Подозрение вызывает резкий скачок входящего трафика без распродажи, рекламной кампании или другого ожидаемого источника нагрузки.
- Хватает ли серверу ресурсов. Если CPU несколько минут держится на уровне 90–100%, оперативная память заполнена. Показатель нужно сопоставлять с запросами и ошибками.
- Какие HTTP-ошибки участились. Рост 5xx говорит, что сервер или приложение не справляются. Всплеск 404 и 403 может означать, что боты перебирают адреса или получают отказы от защитных правил.
- К каким страницам идут запросы. Боты могут нагружать поиск, фильтры, авторизацию, корзину, API или несуществующие URL. Такие обращения иногда создают большую нагрузку даже при сравнительно невысоком RPS.
- Откуда пришел новый трафик. Стоит проверить страны, IP-адреса, автономные системы и дата-центры. Необычная география — только один из сигналов: клиенты могут использовать VPN, а партнерские сервисы — зарубежную инфраструктуру.
- Повторяются ли запросы по одному сценарию. Одинаковые URL, интервалы, заголовки или последовательности действий часто указывают на автоматический трафик. При распределенной атаке запросы могут идти с тысяч разных IP.
- Что показывает система защиты. Сотни блокировок в час говорят о подозрительной активности. Если при этом сайт тормозит или CAPTCHA видят обычные покупатели, текущие правила не справляются либо фильтруют трафик слишком грубо.
- Как изменились бизнес-метрики. Резкое падение конверсии, заказов или успешных оплат при сохранении рекламного трафика может означать, что пользователи не доходят до целевых действий. Причину нужно искать вместе с техническими метриками.
Если исторических данных пока нет, зафиксируйте текущий RPS, долю ошибок, загрузку сервера, географию и конверсию. Без базового профиля отличить атаку от обычного пика гораздо сложнее.
Частые вопросы: защита сайта от DDoS
Как защитить сайт от DDoS-атак?
Начать нужно с определения нормального профиля трафика: RPS, географии, URL, нагрузки на сервер и поведения пользователей. Затем настроить многоуровневую защиту: сетевую фильтрацию для L3/L4-атак, WAF и rate limiting для HTTP-трафика, а также CDN и кэширование для разгрузки origin-сервера.
Как понять, что сайт атакуют, а не просто вырос трафик?
Сам по себе рост RPS не означает DDoS-атаку. Необходимо сопоставить всплеск запросов с рекламными кампаниями и другими событиями бизнеса, а затем проверить URL, источники трафика, повторяемость запросов, HTTP-ошибки, загрузку CPU и другие технические показатели.
Можно ли защитить сайт от DDoS без блокировки реальных клиентов?
Да. Для этого правила защиты не должны основываться только на IP-адресах. Можно учитывать поведение клиента, URL, частоту запросов, cookies, JavaScript, репутацию IP, ASN и другие признаки. Для сомнительного трафика вместо немедленной блокировки можно использовать CAPTCHA или challenge.
Помогает ли WAF против DDoS-атак?
WAF хорошо подходит для фильтрации HTTP-трафика и атак на уровне приложения, включая часть HTTP-flood атак. Однако WAF не заменяет сетевую защиту от объемных атак L3/L4, поэтому для надежной защиты сайта применяют несколько уровней фильтрации.
Нужно ли защищать API отдельно?
Да. API может иметь совершенно другой профиль нормальной нагрузки, чем обычные страницы сайта. Поэтому для API желательно задавать отдельные лимиты, правила аутентификации и проверки запросов, учитывая работу партнерских интеграций.
Поможет ли увеличение мощности сервера против DDoS?
Увеличение ресурсов сервера может повысить запас прочности, но само по себе не решает проблему. Если атака продолжает направлять большое количество запросов непосредственно на origin, дополнительные CPU и RAM лишь увеличивают стоимость инфраструктуры. Часть вредоносного трафика необходимо отсеивать до его попадания на основной сервер.
Получайте полезный контент от KISLOROD в любом из мессенджеров
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Рекомендованные статьи
Скачайте 17 точек роста и 100 + чекеров для роста конверсии и прибыли интернет-магазина
При переходе в одну из указанных социальных сетей вы автоматически даете согласие на обработку персональных данных и согласие на получение рекламной рассылки. Подробнее об обработке данных в Политике конфиденциальности.
Мы проанализировали ведущие интернет-магазины, результаты исследований, свой опыт и собрали важные моменты в одно руководство. Делаем e-commerce лучше, поэтому не только пользуемся сами, но и делимся с вами.
Выберите удобный мессенджер и получите чек-лист прямо сейчас:
