Причина в самой природе DDoS-атаки. Сервер получает настолько много запросов, что тратит ресурсы не на работу с реальными пользователями, а на обработку потока, который создаёт атакующий.
Для интернет-магазина это особенно неприятный сценарий. Пока специалисты разбираются с причиной сбоя, покупатели не могут открыть каталог, добавить товар в корзину или оформить заказ. Поэтому защиту от DDoS лучше настраивать заранее, а не после первого инцидента.
Что такое DDoS-атака
DDoS (Distributed Denial of Service) — это распределённая атака на отказ в обслуживании. Злоумышленник организует большое количество запросов или сетевого трафика, чтобы занять доступные ресурсы сайта и сделать его недоступным для обычных посетителей.
Для атаки могут использоваться тысячи и даже миллионы устройств. Заражённые компьютеры, серверы, роутеры и другие устройства объединяются в ботнет и одновременно отправляют запросы на выбранный ресурс.
При этом DDoS не всегда означает огромный объём трафика. Иногда достаточно относительно небольшого количества обращений к «тяжёлой» функции сайта. Если каждый такой запрос запускает сложный поиск в базе данных или другую ресурсоёмкую операцию, сервер может оказаться перегружен и без гигабитного потока.
При DDoS важен не только объём трафика. Не меньшее значение имеет то, что происходит с инфраструктурой после получения каждого запроса.
Какие бывают DDoS-атаки
Условно атаки можно разделить на несколько групп. Одни направлены непосредственно на сетевую инфраструктуру, другие имитируют обычное поведение посетителей и бьют уже по веб-приложению.
Атаки на сетевом уровне
- SYN Flood. Сервер получает большое количество запросов на установку TCP-соединений. Если таких соединений становится слишком много, доступные ресурсы могут быстро закончиться.
- UDP Flood. На сервер или сетевое оборудование направляется большое количество UDP-пакетов. В зависимости от архитектуры это может привести к перегрузке канала или самого оборудования.
- ICMP Flood. Атакующий отправляет большое количество ICMP-пакетов. Сейчас такой сценарий не всегда используется отдельно, но он относится к классическим сетевым атакам.
Атаки на уровне приложения
- HTTP Flood. Сервер получает большое количество обычных HTTP-запросов. Снаружи они могут выглядеть вполне нормально, поэтому простая блокировка «плохих» пакетов здесь не поможет.
- Slow-rate атаки. Соединения поддерживаются достаточно долго и постепенно расходуют доступные ресурсы сервера. Объём трафика при этом может быть сравнительно небольшим.
- Атаки на отдельные функции. Например, злоумышленник может постоянно обращаться к поиску, авторизации или API. Если эти операции требуют обращения к базе данных, нагрузка на сайт быстро возрастает.
На практике разные типы атак могут использоваться одновременно. Поэтому строить защиту только под один сценарий не имеет смысла.
Как понять, что сайт атакуют
Высокая нагрузка сама по себе ещё не означает DDoS. Интернет-магазин может получить в несколько раз больше посетителей после запуска рекламы или публикации у популярного блогера. И в этом случае рост нагрузки будет вполне естественным.
Первое, на что стоит посмотреть, — соотношение технических и бизнес-показателей. Если вместе с ростом количества запросов увеличивается число просмотров, заказов и других действий пользователей, скорее всего, сайт просто переживает пик посещаемости.
Если же запросов стало значительно больше, а реальных действий почти нет, стоит разобраться подробнее.
- резко выросло количество запросов или соединений;
- увеличилось время ответа сервера;
- появились ошибки 502, 503 или 504;
- CPU или оперативная память постоянно находятся под высокой нагрузкой;
- база данных получает заметно больше запросов, чем обычно;
- сетевой канал приближается к пределу пропускной способности;
- большая часть запросов приходится на один или несколько URL;
- одни пользователи могут работать с сайтом, а другие регулярно получают таймауты.
Здесь очень помогает история метрик. Если команда знает обычный уровень нагрузки, заметить отклонение гораздо проще. Для одного проекта 500 запросов в секунду будут обычным значением, для другого — поводом немедленно проверить инфраструктуру.
Почему нельзя просто поставить сервер мощнее
Увеличить ресурсы сервера иногда действительно полезно. Но от DDoS это не универсальное лекарство.
Представим, что сервер упирается в CPU. В этом случае переход на более производительную конфигурацию даст некоторый запас. Но если атакующий продолжит увеличивать нагрузку, проблема вернётся.
Другая ситуация — когда забит сам сетевой канал. Сервер может иметь сколько угодно процессоров и памяти, но если лишний трафик уже занял весь доступный канал, до приложения он просто не дойдёт.
Поэтому основную фильтрацию желательно выполнять до того, как запрос попадёт на origin-сервер.
Как построить защиту сайта
Хорошая защита обычно состоит не из одного инструмента, а из нескольких уровней. Каждый из них решает свою задачу.
CDN
CDN принимает запросы пользователей на своей стороне и позволяет не отправлять каждый из них непосредственно на основной сервер. Кроме того, статический контент — изображения, стили, скрипты и другие файлы — можно отдавать из кэша.
Это снижает нагрузку на origin и оставляет серверу больше ресурсов для действительно динамических операций.
При этом важно правильно настроить саму схему. Если настоящий IP origin-сервера остаётся доступен напрямую, атакующий может попытаться обойти CDN и отправлять трафик непосредственно на него.
WAF
Web Application Firewall работает уже на уровне веб-приложения. Он анализирует HTTP-запросы и позволяет задавать правила для различных сценариев.
Например, можно ограничить подозрительные запросы к административной части сайта, отдельно контролировать API или блокировать известные вредоносные шаблоны.
WAF полезен и против некоторых DDoS-атак на уровне приложения, но не стоит считать его полной заменой сетевой DDoS-защите. Это разные уровни, и на практике они дополняют друг друга.
Ограничение количества запросов
Rate limiting — один из самых простых и полезных механизмов защиты. Его задача — не позволить одному клиенту отправлять неограниченное количество запросов.
Но правило «100 запросов в минуту на IP» далеко не всегда будет правильным. Для главной страницы, формы авторизации и ресурсоёмкого API нужны разные ограничения.
Слишком строгие лимиты тоже опасны. Например, во время рекламной кампании на сайт действительно может прийти много пользователей с одних и тех же сетей. Если ограничения настроены неправильно, под них попадут обычные посетители.
Кэширование
Чем больше запросов можно обслужить из кэша, тем меньше работы приходится выполнять приложению.
Особенно это важно для каталогов, новостей, статических страниц и других разделов, содержание которых не меняется после каждого запроса.
Для динамических страниц подход сложнее, но даже там можно найти данные, которые нет смысла пересчитывать при каждом обращении.
Мониторинг
Защита без мониторинга работает почти вслепую. Нужно понимать, сколько запросов получает сайт, какие URL наиболее нагружены, сколько соединений открыто, как ведёт себя база данных и где появляются ошибки.
Не менее важно настроить уведомления. Если сервер начинает перегружаться ночью, команда должна узнать об этом автоматически, а не утром из сообщения клиента.
Что делать, если атака уже началась
Когда сайт уже находится под атакой, главное — не менять настройки наугад. Сначала нужно определить, какой именно ресурс стал узким местом.
Если проблема в пропускной способности канала, серверные настройки не решат её. Если же перегружено конкретное API, может помочь временное ограничение запросов к нему.
Действовать можно по следующему плану:
- зафиксировать момент начала проблемы;
- сравнить текущую нагрузку с обычными значениями;
- посмотреть, какие URL и сервисы получают больше всего запросов;
- проверить загрузку сети, серверов и базы данных;
- усилить фильтрацию на внешнем уровне;
- при необходимости ужесточить rate limiting для проблемных endpoint;
- временно отключить необязательные ресурсоёмкие функции;
- контролировать доступность основных сценариев для пользователей.
Последний пункт особенно важен для интернет-магазина. Во время атаки не всегда нужно любой ценой сохранить абсолютно все функции сайта. Иногда лучше временно убрать рекомендации или сложный поиск, но оставить каталог, корзину, авторизацию и оформление заказа.
Какие сервисы можно использовать
Выбор конкретного решения зависит от масштаба проекта и его архитектуры. Для небольшого сайта и крупного интернет-магазина требования будут совершенно разными.
Cloudflare, Akamai и другие CDN
Облачные платформы позволяют вынести часть инфраструктуры за пределы собственного сервера и использовать готовые механизмы защиты. В зависимости от тарифа и конфигурации это могут быть DDoS mitigation, WAF, rate limiting, защита от ботов и другие функции.
При выборе сервиса имеет смысл смотреть не только на количество функций в тарифе. Важнее понять, как он будет работать именно с вашей архитектурой: где находится origin, какие запросы нельзя кэшировать, как настраивается WAF и что произойдёт при крупной атаке.
Серверные инструменты
Nginx, Apache, nftables и другие системные инструменты тоже могут использоваться для ограничения нагрузки.
Они особенно полезны как дополнительный уровень защиты. Например, можно ограничить слишком большое количество соединений или закрыть ненужные сетевые порты.
Но использовать сервер как единственную линию обороны против крупной DDoS-атаки не стоит. Если трафик уже дошёл до вашего сервера, значительная часть ресурсов сети могла быть потрачена ещё до применения этих правил.
Что проверить заранее
Самая полезная работа по защите от DDoS выполняется до инцидента. Когда сайт уже недоступен, времени на проектирование архитектуры практически нет.
Минимальный чек-лист выглядит так:
- IP-адрес origin не должен быть доступен без необходимости;
- CDN и WAF должны быть настроены и протестированы;
- для авторизации и других чувствительных endpoint должны действовать отдельные лимиты;
- ключевые метрики должны собираться постоянно;
- уведомления о резком росте нагрузки должны приходить ответственным сотрудникам;
- должен быть понятный план действий при атаке;
- после инцидента нужно иметь возможность быстро вернуть изменённые правила в штатное состояние.
Полезно периодически пересматривать эти настройки. Сайт меняется: появляются новые API, интеграции, способы авторизации, рекламные кампании. Защита, которая хорошо работала год назад, после нескольких изменений в архитектуре может оказаться недостаточной.
Итог
DDoS-защита — это не попытка сделать так, чтобы на сайт вообще никогда не пришёл вредоносный трафик. Такая задача практически невыполнима.
Задача состоит в другом: не дать этому трафику вывести из строя критичные элементы инфраструктуры и сохранить работу основных функций сайта.
Для одного проекта достаточно CDN, WAF, rate limiting и нормального мониторинга. Для другого потребуется специализированная защита, резервирование и отдельный план реагирования. Универсального набора настроек здесь нет.
Главное — понимать собственную инфраструктуру. Где находится origin, какие запросы самые дорогие, сколько нагрузки выдерживает база данных, какие функции можно временно отключить и кто будет принимать решения во время инцидента.
Хорошая защита от DDoS начинается не с выбора сервиса, а с понимания того, что именно нужно защищать.
Если эти вопросы продуманы заранее, атака не превращается в ситуацию, когда команда в панике пытается понять, почему сайт перестал отвечать. Есть мониторинг, понятная схема защиты и заранее определённый порядок действий — а значит, гораздо больше шансов сохранить работоспособность проекта.
