DDoS-атака на сайт: как распознать и что делать владельцу
DDoS-атака на сайт — это попытка нарушить доступность сервиса с помощью распределённой нагрузки. Для владельца бизнеса последствия выглядят просто: страницы открываются медленно, заявки не отправляются, покупатели не могут оформить заказ. Но такие же симптомы возникают при ошибке приложения, сбое хостинга или удачной рекламной кампании. Поэтому сначала нужно определить, где возникла проблема, и согласовать защитные действия с провайдером.
Если сайт недоступен прямо сейчас, зафиксируйте время начала, проверьте сообщения хостинга и сервиса защиты, откройте обращение в поддержку и назначьте ответственного за изменения. Параллельно выясняйте, что перегружено: канал связи, сетевое оборудование, веб-сервер или приложение. Правильная мера должна уменьшать вредоносную нагрузку и сохранять доступ настоящим посетителям.
Ниже — практический порядок действий для владельца и администратора. Он помогает проверить подозрение на ддос-атаку на сайт, выбрать уровень защиты, не потерять рабочие интеграции и оценить результат по доступности бизнеса.
Что такое DDoS-атака простыми словами
DDoS расшифровывается как Distributed Denial of Service — распределённый отказ в обслуживании. Смысл атаки в том, чтобы занять ограниченные ресурсы и помешать нормальной работе сервиса. Для этого не обязательно получать пароль администратора или изменять файлы сайта. Недоступность сама по себе не доказывает взлом, а отсутствие посторонних файлов не исключает атаку на доступность.
Защита зависит от того, какой ресурс испытывает нагрузку. В обзоре Cloudflare выделены объёмные, протокольные и прикладные атаки. Владельцу достаточно понимать практическую разницу между ними.
| Уровень проблемы | Что может пострадать | Куда направлять диагностику |
|---|---|---|
| Канал связи | Сервер теряет возможность принимать нормальный трафик | К провайдеру сети и сервису фильтрации до канала |
| Сетевые соединения и оборудование | Исчерпываются возможности обработки соединений и пакетов | К сетевым специалистам и инфраструктурной защите |
| Веб-приложение | Не справляются обработчики, база данных, поиск или другие функции | К HTTP-защите, разработчику и настройкам приложения |
Одновременно могут проявляться несколько уровней. Название тарифа «защита от DDoS» ещё не объясняет, какие протоколы и ресурсы он покрывает. Это нужно уточнять для конкретной схемы сайта.
Как определить DDoS-атаку: признаки и проверка
Типичные сигналы — недоступность, необычный рост запросов или трафика, обращения, не похожие на привычное поведение посетителей. Именно такие признаки перечисляет официальная инструкция Cloudflare. Каждый из них требует сопоставления с другими данными: один график не устанавливает причину.
Сначала сравните нагрузку с обычной работой
Посмотрите тот же день недели и сопоставимое время, учтите рекламу, рассылки, публикации и сезонность. Разберите, какие страницы и методы получают запросы, где выросло время ответа, какие ошибки появились. Важны также нагрузка процессора, память, соединения, очереди приложения и состояние базы. Большое число запросов к лёгким кешируемым ресурсам и меньшая нагрузка на тяжёлую функцию могут иметь разные последствия.
Проверьте последние изменения: выпуск кода, настройки кеша, импорты, фоновые задания, интеграции. Если нагрузка выросла сразу после обновления, это основание проверить обновление, но не готовый вывод. Несколько причин могут совпасть.
Сопоставьте наблюдения на разных участках
Используйте мониторинг извне, статистику CDN, данные хостинга и журналы приложения. Счётчик веб-аналитики может не учитывать запросы, которые не выполняют JavaScript, а серверный журнал не увидит пакеты, отброшенные раньше. Поэтому отсутствие всплеска в аналитике не подтверждает отсутствие сетевой атаки.
Проверьте, затронуты ли весь сайт, отдельная функция, несколько поддоменов или только конкретная сеть посетителей. Ошибки 502, 503 и тайм-ауты показывают сбой обслуживания, но не называют его причину. Много разных IP-адресов также не является самостоятельным доказательством: так выглядит и обычная массовая аудитория.
До подтверждения называйте ситуацию подозрением на атаку. Уточняйте у провайдера, какие сетевые или прикладные признаки поддерживают этот вывод, какие альтернативные причины проверены и где находится узкое место. Это помогает выбрать меру, соответствующую наблюдаемой проблеме.
Что делать владельцу сайта в первые минуты
Организуйте работу так, чтобы срочные действия не мешали друг другу. Один человек координирует изменения, технические специалисты проверяют инфраструктуру, а ответственный за продажи оценивает, какие операции уже недоступны клиентам. Запишите действующие настройки перед их изменением и заранее определите способ возврата.
| Действие | Что получить | Как избежать лишнего ущерба |
|---|---|---|
| Зафиксировать начало и симптомы | Время с часовым поясом, адреса страниц, ошибки | Не ограничиваться сообщением «всё лежит» |
| Обратиться к провайдеру | Подтверждение уровня проблемы и план фильтрации | Использовать официальный канал и известные контакты |
| Оценить критичные функции | Список затронутых форм, заказов, оплат, API | Не проверять оплату случайными реальными списаниями |
| Применить согласованную меру | Уменьшение нагрузки на проблемном участке | Записать правило, время, автора и условие отката |
| Проверить результат | Доступность для посетителей и состояние сервера | Следить за ложными блокировками и очередями |
Если публичная часть работает нестабильно, подготовьте понятное сообщение о временных затруднениях и проверенный альтернативный способ обращения. Размещайте его на доступном ресурсе: сообщение в перегруженной CMS посетитель может не увидеть. Не обещайте время восстановления, которого техническая команда ещё не подтвердила.
Остановку рекламного трафика и временное ограничение отдельных функций согласуйте с бизнесом. Решение зависит от того, работает ли целевая страница и может ли посетитель завершить действие. Массовое отключение всех каналов без проверки способно увеличить потери.
Что написать хостингу и сервису защиты
Хорошее обращение ускоряет диагностику. Передайте домен, идентификатор услуги, время начала с часовым поясом, доступные графики, примеры ошибок и перечень последних изменений. Уточните, наблюдается ли проблема постоянно или волнами и какие функции продолжают работать.
Полезный шаблон: «С указанного времени наблюдаем недоступность этих адресов и рост таких показателей. Проверили эти изменения и внешние точки доступа. Просим определить уровень перегрузки, подтвердить или исключить признаки DDoS и предложить меры с учётом работы форм и платёжных уведомлений». Заполняйте его фактическими данными, не заменяя измерения предположением об атакующем.
Задайте конкретные вопросы: доходит ли нежелательный трафик до сервера, насыщен ли канал, где сейчас выполняется фильтрация, что уже блокируется, есть ли ограничения услуги или временное отключение адреса. Если провайдер применил блокировку всего трафика к ресурсу, уточните последствия, условия снятия и доступный вариант фильтрации полезных запросов.
Не публикуйте журналы целиком в открытом чате. Передавайте минимально необходимые фрагменты через согласованный канал, скрывая пароли, токены и данные клиентов. OWASP рекомендует защищать журналы и исключать из обычных записей секреты и чувствительные значения.
Защита канала, DNS и исходного сервера
Если трафик уже заполнил внешний канал, правило внутри CMS не освободит этот канал. Нужна помощь на участке, через который нагрузка приходит раньше: у оператора, хостинга или сервиса сетевой фильтрации. Подход с распределённой защитой на внешнем периметре описан в рекомендациях AWS по устойчивости к DDoS. Конкретное решение выбирают под инфраструктуру и протоколы.
Убедитесь, что трафик действительно проходит через защиту
Сам факт переноса DNS к сервису защиты не означает включение фильтрации веб-запросов. Например, в Cloudflare режим Proxied направляет HTTP/HTTPS через сеть Cloudflare, а DNS-only — непосредственно к исходному серверу. Проверяйте состояние каждого нужного имени: основного домена, www, API и других поддоменов. Не переносите этот принцип на любые протоколы автоматически.
Не переключайте записи во время инцидента наугад. Администратор должен учесть сертификаты, DNSSEC при изменениях DNS-инфраструктуры, совместимость портов и интеграций. Изменения DNS распространяются с учётом кеширования; обещать мгновенное переключение всех посетителей нельзя.
Закройте обход внешней защиты
Origin — это исходный сервер, на котором работает сайт. Если он остаётся доступен напрямую, часть трафика может идти в обход CDN. Скрытый в текущей DNS-записи адрес не обязательно неизвестен: он мог сохраниться в исторических данных или использоваться другим сервисом.
В руководстве по защите origin рассмотрены ограничения доступа, туннель и проверка соединений от защитной сети. Способ выбирает администратор, учитывая возможности хостинга. Проверьте также IPv6, служебные имена и доступы, нужные для мониторинга и обслуживания. Правила должны сохранять легитимные зависимости, а доверие к общей сети провайдера не заменяет проверку запросов приложения.
WAF, ограничения запросов и кеширование: разные задачи
На уровне сайта обычно сочетают несколько мер. WAF фильтрует веб-запросы по правилам, ограничение частоты уменьшает чрезмерную активность, а кеш снижает число обращений к исходному серверу. Наличие одной из этих функций не означает, что все узкие места закрыты. Доступные возможности и детализация настройки зависят от сервиса и тарифа.
WAF: начинайте с признака, который можете объяснить
Подбирайте правило по наблюдаемой проблеме: затронутому пути, методу, типу клиента или сочетанию признаков. Для каждого изменения сформулируйте ожидаемый эффект и способ проверки. Если сервис поддерживает наблюдение без блокировки и ситуация позволяет, оцените совпадения перед включением жёсткого действия. Во время срочного реагирования отслеживайте первые результаты сразу после применения.
Блокировка страны или крупной сети без анализа может отрезать клиентов, партнёров и пользователей VPN. Назначайте срок пересмотра временных правил. Не превращайте экстренные ограничения в постоянную конфигурацию по забывчивости.
Ограничение частоты: считайте подходящие запросы
Универсального безопасного числа запросов в минуту нет. Порог выбирают по обычному поведению конкретной функции и её стоимости для приложения. Загрузка каталога, отправка формы и обмен с учётной системой требуют разных условий. Cloudflare предлагает оценивать влияние выбранного порога на наблюдаемый трафик.
При подсчёте только по IP несколько людей за офисным или мобильным шлюзом могут попасть в один лимит. Эта проблема отражена в описании параметров rate limiting. Продумайте ключ подсчёта, область правила и допустимые повторы. Возможности разных продуктов отличаются; не копируйте настройку из чужого примера без проверки.
После подключения прокси сервер может видеть адрес прокси вместо посетителя. Восстановление клиентского IP требует корректной настройки доверенных промежуточных узлов. По документации MDN, произвольному значению X-Forwarded-For нельзя доверять для ограничения доступа. Иначе правило способно блокировать не тех пользователей или принимать подставленные значения.
Кеш: снижайте нагрузку без утечки персональных данных
Кешируйте подходящие общедоступные ресурсы и проверяйте фактические попадания в кеш. Наличие CDN не означает кеширование всего сайта: например, Cloudflare не кеширует HTML по умолчанию. Динамические действия продолжат обращаться к приложению, если для них не предусмотрена другая архитектура.
Нельзя бездумно включать общий кеш для личного кабинета, корзины, заказов и страниц с пользовательскими данными. Учитывайте cookies, авторизацию, параметры URL и актуальность ответа. Правила поведения кеша зависят от заголовков и настроек; принудительное переопределение требует проверки разработчиком. Игнорирование всех параметров запроса может изменить содержимое, которое получает посетитель.
Когда включать Under Attack Mode и проверки браузера
Under Attack Mode в Cloudflare предназначен для дополнительного противодействия атакам прикладного уровня. Он показывает промежуточную страницу с проверкой браузера и рассматривается как одна из крайних мер во время атаки. Такой режим влияет на доступ посетителей и аналитику; его не следует включать бессрочно без оценки последствий.
Если требуется проверка только части сайта, рассмотрите ограниченную область применения в рамках возможностей сервиса. Назначьте ответственного за отмену режима и проверьте доступ с обычных устройств целевой аудитории. Важно увидеть не только открытие главной, но и прохождение полезного сценария до конца.
Браузерная проверка подходит не каждому запросу. Документация Challenge Pages предупреждает: возвращаемая HTML-страница нарушает обращения AJAX и API, которые ожидают другой формат. Сервер платёжного провайдера также не является посетителем, способным пройти обычный браузерный сценарий. Для таких каналов нужны совместимые меры: проверка подлинности, ограничение частоты и точные правила по назначению.
Не делайте широкое исключение из всех защит для любого запроса к API. Исключение должно устранять конкретную несовместимую проверку, сохраняя контроль доступа и остальные необходимые ограничения.
Как сохранить заявки, оплату и работу интеграций
Успех защиты измеряется тем, что реальные клиенты снова могут пользоваться сайтом. График заблокированных запросов не показывает, принимаются ли заказы. Составьте короткий список критичных сценариев и проверяйте его после каждого существенного изменения.
| Сценарий | Что проверить | Признак скрытой проблемы |
|---|---|---|
| Обратная связь | Отправку, сохранение заявки и получение ответственным | Появляется сообщение об успехе, но заявки нет |
| Вход и кабинет | Авторизацию, переходы, завершение сеанса | Повторные проверки браузера или чужое кешированное содержимое |
| Заказ и оплата | Создание заказа и согласованный тест интеграции | Статусы сайта и платёжного провайдера расходятся |
| API и вебхуки | Формат ответа, аутентификацию, доставку уведомлений | Вместо ожидаемого ответа возвращается HTML проверки |
| Мониторинг и поисковые роботы | Доступ нужных проверенных клиентов | Сайт кажется восстановленным только из одного браузера |
Проверки оплаты проводите в предусмотренном тестовом режиме и согласуйте с ответственным за интеграцию. Если во время сбоя накопились уведомления или заказы с неопределённым статусом, сопоставьте их с подтверждёнными данными провайдера. Повторная обработка не должна дублировать списание, отгрузку или сообщение покупателю.
Учебный пример: после включения общей проверки браузера главная страница магазина открывается, но уведомления об оплате перестают доходить. Технически сервер доступен, однако бизнес-процесс нарушен. Решение — проверить журнал блокировок, уточнить доверенный способ подтверждения уведомлений и изменить именно несовместимое правило. Простое отключение всей защиты создаёт новую неопределённость.
Как понять, что работа восстановлена
Сравнивайте показатели до изменений и после них: доступность, время ответа, ошибки, нагрузку origin, очередь задач и результаты критичных сценариев. Уточняйте, почему стало меньше запросов на сервере: их мог отфильтровать сервис защиты, но они могли исчезнуть и из-за недоступности DNS или случайной блокировки всех посетителей.
Период наблюдения выбирайте с учётом характера инцидента и обычного цикла работы. Одного удачного открытия страницы недостаточно. Проверяйте разные сети и устройства, повторные обращения клиентов и состояние интеграций. Если атака продолжается на внешнем периметре, а сайт устойчиво работает, это отличается от полного прекращения нежелательного трафика.
Снимайте временные ограничения по согласованному плану, сохраняя наблюдение. Зафиксируйте, какие правила остаются, кто их сопровождает и когда пересматриваются исключения. После возврата доступности проверьте рекламные посадочные страницы, мониторинг и отчёты поисковых систем.
Длительные ошибки сервера могут повлиять на обход и индексирование. Google описывает снижение частоты обхода при 5xx и 429 и последствия устойчивых ошибок для индекса. Не подменяйте все страницы одинаковой заглушкой с успешным статусом и не обещайте автоматическое сохранение прежних позиций.
Отдельно проверьте, не попали ли нужные поисковые роботы под новое правило. В рекомендациях Google по CDN предлагается посмотреть результат проверки URL в Search Console: робот должен получать страницу сайта, а не экран проверки или ошибку. Устраняйте найденную блокировку адресно, по подтверждённому источнику запросов; одного названия робота в User-Agent недостаточно для широкого исключения.
Что подготовить заранее для защиты сайта от DDoS
Зафиксируйте схему: где обслуживается DNS, какие домены проходят через прокси, где находится origin, какие протоколы и внешние интеграции используются. У списка должны быть ответственный и дата проверки. Поддерживайте актуальные контакты хостинга, регистратора, сервиса защиты и разработчика.
До покупки услуги выясните, что входит в покрытие: сетевые и прикладные атаки, нужные адреса и протоколы, постоянная или подключаемая фильтрация, журналы, уведомления и помощь во время инцидента. Отдельно обсудите ограничения пропускной способности, порядок реагирования, возможное отключение адреса и модель оплаты. Не переносите характеристики одного тарифа на все продукты провайдера.
До окончательного выбора проверьте доступность маршрута через защиту из регионов и сетей вашей аудитории. Убедитесь, что поддерживаются используемые протоколы, сертификаты и способы обращения интеграций. Важны реальные условия обслуживания проекта, доступность поддержки и возможность сопровождать настройки. Общее описание продукта не заменяет проверку конкретного сайта в согласованной конфигурации.
Оцените цену недоступности на собственных данных: потерянные обращения, расходы на рекламу, работу сотрудников и восстановление операций. Сопоставляйте её со стоимостью защиты и обслуживания. Автоматическое увеличение мощности требует контроля расходов и не заменяет фильтрацию нежелательной нагрузки.
Подготовьте резервный канал связи с клиентами, инструкции изменения правил и проверенные способы отката. Проводите согласованные тренировки на своей инфраструктуре в установленных пределах, без неожиданной нагрузки на рабочий сервис. Полезный результат тренировки — понятные роли, доступные контакты и проверенный порядок решений.
После инцидента подготовьте короткую карточку результата: время начала и восстановления, подтверждённый уровень проблемы, выполненные изменения, затронутые операции и оставшиеся вопросы. Отметьте, какие гипотезы не подтвердились и какие данные оказались недоступны. У каждого следующего действия должны быть исполнитель и срок: исправить мониторинг, проверить исключение, согласовать резервный контакт или пересмотреть условия услуги. Так команда получает конкретный план улучшений и не начинает следующий разбор с тех же догадок.
Какие действия чаще всего мешают восстановлению
Избегайте изменений, эффект которых невозможно оценить. Одновременный перенос DNS, смена хостинга, отключение кеша и установка нескольких защитных модулей усложняют поиск причины. Каждую существенную меру связывайте с наблюдаемым узким местом и проверяемым результатом.
- Бесконечно перезагружать сервер. Это не объясняет причину нагрузки и может мешать обработке очередей и диагностике.
- Блокировать адрес прокси как источник атаки. За ним могут находиться все реальные посетители.
- Кешировать всё подряд. Доступность нельзя улучшать ценой выдачи чужих данных.
- Добавлять широкие исключения. Необходимо понимать, какие именно проверки они обходят.
- Считать отсутствие жалоб доказательством успеха. Посетители могут уйти, не сообщив о проблеме.
- Удалять наблюдения после восстановления. Хронология и результаты изменений нужны для разбора причин и подготовки к повторению.
Частые вопросы о DDoS-атаках на сайт
Как проверить сайт на DDoS онлайн?
Внешний мониторинг помогает увидеть доступность и время ответа, но не устанавливает причину сбоя. Для подтверждения нужны данные провайдера, защитного сервиса и приложения. Один публичный сервис проверки не видит все участки вашей инфраструктуры.
Может ли DDoS-атака начаться на небольшом сайте?
Размер аудитории сам по себе не определяет необходимый уровень защиты. Оценивайте зависимость бизнеса от сайта, доступные ресурсы, состав интеграций и возможности провайдера. Даже краткая недоступность бывает существенна, если через сайт проходят важные обращения.
Спасёт ли более мощный сервер?
Он может устранить подтверждённый дефицит ресурсов, но не решает любую проблему. Если ограничение находится в канале, сетевом оборудовании или архитектуре приложения, увеличение мощности одного сервера может не дать нужного результата.
Достаточно ли установить плагин безопасности?
Плагин может выполнять отдельные проверки внутри приложения. Он не обеспечивает фильтрацию до внешнего канала и не заменяет сетевую защиту. Сначала определите уровень перегрузки и место, где нежелательный трафик должен отсекаться.
Нужно ли менять домен или IP-адрес?
Смена домена обычно не устраняет причину недоступности. Изменение адреса origin иногда входит в согласованный план защиты, но требует проверки маршрутов, доступов и зависимостей. Новый адрес не должен снова оставаться открытым в обход выбранной схемы.
Можно ли гарантировать, что атаки больше не будет?
Гарантировать отсутствие попыток нельзя. Практическая цель — снизить последствия, быстро обнаруживать изменения и поддерживать рабочие сценарии для посетителей. Условия доступности и ответственности нужно оценивать по конкретной архитектуре и договору.
После настройки защиты продолжайте следить за доступностью сайта и временем ответа из внешней точки. Для регулярного мониторинга оцените возможности SiteGuard. Сопоставляйте обнаруженные сбои с журналами хостинга и сервиса защиты, чтобы команда могла определить причину и выбрать нужное действие.