Как защитить сайт от DDoS-атак: CDN, WAF, лимиты и план восстановления

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

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

Защита от DDoS — это не одна настройка и не установка отдельного плагина. Нужна система из нескольких уровней: правильная архитектура, CDN, фильтрация трафика, ограничения запросов, мониторинг, резервный сценарий и понятный план действий при инциденте.

Что такое DDoS-атака и чем она опасна для сайта

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

Важно отличать DDoS от обычного всплеска посещаемости. Большой поток пользователей после рекламы, публикации в СМИ или запуска акции может быть легитимным. У него обычно есть понятный источник и логика поведения: люди открывают страницы, переходят по ссылкам, читают материалы, добавляют товары в корзину.

При атаке часто наблюдаются другие признаки:

• резкий рост запросов за короткий период;
• одинаковые или бессмысленные обращения к одному URL;
• много запросов с разных адресов и регионов;
• высокая доля обращений к тяжелым операциям;
• аномальное потребление CPU, памяти, соединений или пропускной способности;
• ошибки тайм-аута и временная недоступность сайта;
• необычное поведение по протоколам, портам или типам запросов.

DDoS-атаки условно делят на несколько групп. Сетевые атаки перегружают канал или сетевое оборудование. Протокольные атаки используют особенности обработки соединений. Атаки на уровень приложения создают запросы, похожие на обычные действия пользователя, но заставляют сайт выполнять дорогие операции: поиск по каталогу, фильтрацию, авторизацию или формирование отчета.

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

Какие уровни сайта нужно защищать

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

Сетевой уровень

На этом уровне защищают канал связи, IP-адреса и сетевые протоколы. Обычно используются фильтрация у провайдера, специализированные сервисы очистки трафика и распределенная инфраструктура, способная принять большой объем соединений.

Уровень веб-сервера

Веб-сервер должен ограничивать число одновременных соединений, размер заголовков, длительность ожидания и частоту запросов. Такие параметры помогают снизить влияние медленных или чрезмерно частых соединений.

Уровень приложения

Здесь защищают конкретные действия: вход в аккаунт, поиск, отправку формы, оформление заказа, загрузку файлов и обращение к API. Для каждой операции могут потребоваться свои лимиты, проверка сессии, CAPTCHA или дополнительная верификация.

Уровень инфраструктуры

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

Почему одного хостинга недостаточно

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

Еще одна проблема — общий IP-адрес. Если несколько проектов размещены на одном адресе, ограничения или атака могут затронуть соседние сайты. Для критически важного проекта стоит понимать, где находится точка входа, кто отвечает за фильтрацию и как провайдер действует при инциденте.

Перед запуском защиты уточните у хостинг-компании:

• есть ли базовая защита от сетевых атак;
• кто принимает решение о фильтрации вредного трафика;
• как сообщается об инциденте;
• какие ограничения действуют для входящего трафика;
• можно ли быстро изменить IP-адрес или маршрут;
• предоставляются ли журналы и статистика атак;
• какие действия считаются аварийными и оплачиваются отдельно.

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

Как CDN помогает защитить сайт

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

Через CDN обычно можно отдавать:

• изображения и видео;
• таблицы стилей;
• файлы JavaScript;
• шрифты;
• документы и другие публичные ресурсы;
• кешируемые страницы.

Однако CDN не является абсолютной защитой. Если все запросы передаются на исходный сервер без кеширования, распределенная сеть может лишь перенаправить нагрузку дальше. Эффективность зависит от настроек кеша, правил фильтрации, защиты DNS и способности CDN обрабатывать динамический трафик.

Что нужно настроить в CDN

1. Подключите домен к CDN. Обычно это делается через изменение DNS-записей или делегирование домена на указанные серверы имен.
2. Проверьте HTTPS. Сертификат должен корректно работать между посетителем и CDN, а также между CDN и исходным сервером, если используется защищенное соединение.
3. Настройте кеширование статики. Укажите сроки хранения файлов и правила обновления версий.
4. Определите, какие страницы можно кешировать. Публичные материалы подходят для кеша лучше, чем личные кабинеты, корзины и страницы с персональными данными.
5. Включите базовую фильтрацию. Используйте готовые правила для известных типов вредного трафика и подозрительных запросов.
6. Проверьте доступ к исходному серверу. Сервер не должен без необходимости принимать запросы напрямую из интернета.

Как скрыть исходный сервер

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

На исходном сервере желательно разрешить входящие веб-запросы только от адресов CDN или доверенного балансировщика. Список таких адресов должен поддерживаться в актуальном состоянии. Если разрешить доступ для всех, CDN перестанет быть полноценным барьером.

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

WAF: защита веб-приложения от вредных запросов

WAF, или веб-файрвол, анализирует HTTP-запросы и применяет правила к URL, параметрам, заголовкам, cookie и другим признакам. Он может блокировать известные шаблоны атак, ограничивать подозрительную активность и требовать дополнительную проверку.

WAF полезен не только против DDoS. Он помогает снизить риск эксплуатации распространенных ошибок веб-приложений, блокировать вредные боты и защищать отдельные чувствительные маршруты.

Какие правила стоит рассмотреть

• ограничение частоты запросов с одного адреса или сессии;
• защита страниц входа и восстановления пароля;
• отдельные лимиты для поиска и фильтров;
• проверка подозрительных параметров URL;
• блокировка явно некорректных методов и форматов запросов;
• защита API по ключам, токенам и допустимым источникам;
• временная проверка браузера для аномального трафика;
• правила для известных автоматизированных клиентов.

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

Как настроить rate limiting

Rate limiting ограничивает частоту обращений к ресурсу. Это один из самых практичных механизмов защиты, но универсального лимита для всего сайта не существует. Главная страница, форма входа и API поиска имеют разную нормальную нагрузку.

Лимиты можно применять по нескольким признакам:

• IP-адрес;
• идентификатор пользователя;
• сессия;
• API-ключ;
• маршрут;
• тип HTTP-метода;
• комбинация признаков.

Для публичной страницы обычно подходит более мягкое ограничение. Для входа, отправки формы или запроса восстановления пароля правила должны быть строже. Для авторизованных клиентов можно учитывать учетную запись, а не только IP-адрес, поскольку многие пользователи могут находиться за одним корпоративным или мобильным адресом.

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

Что нельзя делать при настройке лимитов

• назначать одинаковые ограничения для всех URL;
• учитывать только IP-адрес;
• полностью блокировать мобильные и корпоративные сети;
• забывать об API и внутренних фоновых запросах;
• возвращать слишком подробное описание причины блокировки;
• не контролировать количество одновременных соединений;
• не тестировать правила на реальных сценариях пользователей.

Как защитить тяжелые операции

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

Такие операции необходимо оптимизировать и ограничивать отдельно. Практические меры:

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

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

Защита DNS и домена

Даже идеально защищенный сервер не поможет, если злоумышленник изменит DNS-настройки или получит контроль над аккаунтом регистратора. Доступ к домену нужно защищать так же внимательно, как доступ к админке сайта.

Рекомендуется:

• использовать уникальный пароль для аккаунта регистратора и DNS-провайдера;
• включить многофакторную аутентификацию;
• ограничить круг сотрудников с правом изменения DNS;
• включить уведомления об изменении записей;
• проверять резервные email-адреса и номера для восстановления;
• хранить список актуальных DNS-записей;
• удалить неиспользуемые поддомены и старые записи;
• проверять настройки делегирования домена.

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

Мониторинг: как заметить атаку вовремя

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

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

• открытие страниц каталога и услуг;
• отправку формы заявки;
• вход в личный кабинет;
• добавление товара в корзину;
• переход к оплате;
• работу API;
• подключение к базе данных;
• время ответа исходного сервера.

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

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

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

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

1. Проверьте доступность. Убедитесь, что проблема наблюдается из разных сетей и не связана с локальным интернетом, ошибкой DNS или одним конкретным провайдером.
2. Определите масштаб. Сравните текущие показатели с обычными значениями: запросы, ошибки, нагрузка, соединения и трафик.
3. Свяжитесь с хостингом и провайдером защиты. Передайте время начала инцидента, домен, затронутые адреса и доступные журналы.
4. Включите усиленный режим фильтрации. Используйте заранее подготовленные правила, проверку браузера или временное ограничение части маршрутов.
5. Закройте необязательные функции. Если тяжелая операция не критична для бизнеса, ее можно временно ограничить.
6. Сохраните логи. Они помогут понять тип атаки и скорректировать защиту.
7. Проверяйте работу ключевых сценариев. Сайт может открываться, но формы или оплата при этом оставаться недоступными.
8. Сообщите клиентам только проверенную информацию. Не публикуйте технические детали, которые могут помочь атакующему.

Не следует отключать все ограничения ради того,