Посетитель не может открыть каталог, менеджер не получает заявки, а в общем чате уже пишут: «Нас атакуют». Пока причина неизвестна, самое полезное действие владельца сайта: связать хостинг и техническую команду, зафиксировать время сбоя и назвать функции, которые нужно восстановить в первую очередь.
В Гуси-Лебеди мы предлагаем готовиться к такой ситуации заранее. Ниже разбираем, чем DDoS отличается от обычной перегрузки, что сообщить поддержке, как проверить границы защиты и когда считать сайт восстановленным.
DDoS расшифровывается как Distributed Denial of Service, распределённый отказ в обслуживании. При такой атаке множество источников создаёт нагрузку, мешающую обычным пользователям получить услугу. Объектом может стать сетевой канал, обработка соединений или само веб-приложение. Но медленная страница ещё не объясняет, что произошло: похожий результат дают неудачное обновление, проблема базы данных и всплеск настоящих посетителей.
Если сбой происходит сейчас, не ждите окончания собственного расследования, чтобы обратиться к хостеру. Сообщите наблюдаемые симптомы и попросите проверить нагрузку и состояние защиты. Параллельно назначьте одного человека, который собирает ответы и координирует изменения.
Как отличать наблюдаемый сбой от предположения об атаке
Начните с конкретного адреса и действия. Главная страница может открываться, а поиск товаров зависать. Каталог может работать из кеша, хотя сервер уже не принимает заявки. Запись «сайт не работает» скрывает эти различия и затрудняет помощь.
Уточните время начала, часовой пояс, полученную ошибку и условия проверки. Если проблема воспроизводится только у одного сотрудника, проверьте другое разрешённое подключение и устройство. Для массового сбоя сопоставьте внешние проверки с состоянием сервера и ответом хостинга. Частые повторные запросы не заменяют диагностику и могут добавить нагрузку.
Что искать в данных. Технической команде пригодятся динамика запросов, ошибки сервера, длительность обработки, загрузка процессора и памяти, число соединений и состояние канала. Их сравнивают с обычной работой этого проекта. Универсального числа запросов, после которого любой сайт «точно атакуют», нет: страница с тяжёлым поиском и выдача статического файла требуют разных ресурсов.
Счётчики веб-аналитики дают часть картины, но не видят весь сетевой трафик. Запрос может быть остановлен до загрузки страницы и выполнения счётчика. Поэтому падение визитов в Метрике не опровергает атаку, а рост визитов сам по себе её не доказывает. Нужны сведения хостинга, защитного сервиса и приложения за один период.
Представим, что одновременно выросли обращения к поиску и время ответа базы. Это повод исследовать запросы и ресурсоёмкость поиска. Но такой график не позволяет сразу назвать виновника: нагрузку могла создать рекламная кампания, автоматический сбор каталога или атакующий трафик. Рабочий вывод должен объяснять, какие данные подтверждают выбранную причину и чего пока не хватает.
Не удаляйте журналы ради быстрого освобождения места, не сохранив нужный фрагмент. Если диск переполняется, администратор может организовать ротацию или архивирование и определить, что необходимо оставить для разбора. Пароли, токены и персональные сведения из логов не должны попадать в общий чат.
Как выяснять границы защиты сайта
Фраза «на хостинге есть anti-DDoS» полезна только вместе с описанием услуги. Сначала выясните, что именно защищается: IP-адрес, сеть, домен, HTTP-запросы или определённые функции приложения. Затем проверьте, как запрос посетителя проходит от домена до сервера.
| Участок | Какой вопрос задать исполнителю |
|---|---|
| Сеть и соединения, L3/L4 | Кто фильтрует нагрузку на канал и сетевые соединения? |
| Веб-приложение, L7 | Какие механизмы ограничивают вредоносные HTTP-запросы? |
| Основной сервер | Может ли трафик прийти к нему в обход защитного посредника? |
| DNS и внешние сервисы | Кто отвечает за их доступность и какие ограничения есть у услуги? |
Защита на L3/L4 и L7 решает разные задачи. Если перегружен канал до сервера, плагин внутри CMS не сможет очистить его заранее. Если нагрузку создают запросы к тяжёлой функции приложения, нужно разбирать обработку HTTP и поведение этой функции. В документации Cloudflare об охвате DDoS-защиты разделены сетевые и прикладные механизмы; охват зависит также от подключённого продукта.
WAF, ограничение частоты запросов и проверка посетителя могут входить в защиту приложения. Но наличие капчи на форме не доказывает защиту всего сайта: запросы к каталогу, поиску и API идут другими путями. Кеширование тоже помогает лишь там, где ответ можно безопасно повторно использовать. Личный кабинет, изменение заказа и отправку заявки нельзя превращать в общий кеш без разбора данных и поведения.
Отдельный вопрос: защищён ли основной сервер от прямых обращений. В рекомендациях Cloudflare по защите origin-сервера этому посвящён самостоятельный раздел. Конкретную схему доступа выбирает администратор с учётом интеграций и служебных подключений. Простое переключение домена на посредника не заменяет эту проверку.
Перед подключением попросите объяснить порядок активации, требования к DNS и сертификатам, доступные уведомления, режим поддержки и условия тарифа во время атаки. Уточните, кто сможет изменить правила и отменить временную меру. Это предметный разговор о защите и мониторинге сайта, а не выбор по самому громкому обещанию.
Как подготовить порядок действий при инциденте
План должен помещаться в документ, который команда найдёт даже при недоступном сайте. Храните там контакты хостинга, провайдера защиты, администратора и ответственного со стороны бизнеса. Доступы держите в согласованном защищённом хранилище, а не рядом с инструкцией в открытом чате.
Во время сбоя распределите работу:
- Координатор записывает время событий, собирает ответы и сообщает команде текущее состояние.
- Администратор и хостинг проверяют ресурсы, трафик и доступные защитные меры.
- Разработчик разбирает ошибки приложения, последние изменения и тяжёлые операции.
- Ответственный за клиентов сообщает, какие функции недоступны и как временно связаться с компанией.
Такой порядок не требует сразу назначать причину. Поддержке можно написать: «С [время и часовой пояс] не открывается [адрес], получаем [ошибка]. Проверили [условия]. Последнее изменение: [что и когда]. Просим проверить нагрузку, состояние сервера и защитного сервиса». Заполните поля фактическими наблюдениями и приложите безопасный фрагмент данных, если он нужен исполнителю.
Изменения проводите согласованно. Для каждой меры полезно записать цель, исполнителя, время включения и способ проверки. Например, ограничение запросов к поиску должно снижать нежелательную нагрузку и оставлять приемлемый путь для реального покупателя. Сначала задают эти условия, затем проверяют результат.
Не блокируйте большие группы посетителей только по географии и не перезагружайте сервер наугад. Такая мера может закрыть доступ клиентам или уничтожить часть наблюдений, не устранив источник перегрузки. Если специалист предлагает временно отключить функцию, заранее определите, как пользователь узнает об ограничении и чем её заменить.
Проверьте также интеграции: платёжный сервис, CRM, уведомления, API. Браузерная проверка посетителя, подходящая для страницы, может быть несовместима с машинным запросом. Поэтому после изменения фильтрации нужен отдельный разбор разрешённых обменов, а не только открытие сайта в браузере. Если нужно согласовать такую проверку с разработчиком, начните с нашего разбора запросов и ответов REST API: какой запрос отправляется, какой ответ ожидается и что происходит при ошибке.
Клиентам сообщайте то, что известно. Если причина ещё уточняется, достаточно объяснить, какая функция недоступна, какой канал связи работает и где появится обновление. Объявлять взлом или утечку на основании одной недоступной страницы не следует. Разместить сообщение лучше и на независимом от сайта канале, который компания уже использует.
Как подтверждать восстановление и разбирать результат
Сайт открылся у администратора. Теперь нужно пройти путь посетителя: открыть каталог, выполнить поиск, отправить тестовую заявку и проверить её получение. Для магазина добавьте корзину и согласованную проверку оплаты; для кабинета проверьте вход и нужную операцию. Набор зависит от функций вашего проекта.
Сопоставьте эти действия с ошибками и нагрузкой за тот же период. Успешная главная страница из кеша ещё не означает, что приложение вернулось к нормальной работе. Важно понять, восстановлены ли критичные функции и не отсекает ли усиленная защита обычных пользователей.
Временные правила не оставляйте без владельца. Для каждого ограничения зафиксируйте, кто проверяет необходимость и при каких условиях оно пересматривается. Отменять все меры сразу после одного успешного открытия тоже не стоит: решение принимают по наблюдениям и согласованному плану.
После инцидента составьте короткую хронологию: когда заметили сбой, что подтвердили, какие меры приняли и как проверили восстановление. Если причина осталась неизвестной, так и запишите. Следующая задача тогда состоит в улучшении наблюдения, а не в уверенном рассказе о неустановленной атаке.
Разбор должен закончиться конкретными задачами для технического сопровождения сайта: настроить уведомление, уточнить охват защиты, исправить тяжёлый запрос, проверить передачу заявки или обновить контакты. Для каждой задачи нужны ответственный и понятный способ приёмки.
Мы в Гуси-Лебеди предлагаем оценивать готовность простым вопросом: если сайт перестанет принимать обращения, кто увидит проблему, кому позвонит и как поймёт, что работа восстановлена? Ответ связывает защитный сервис, техническую команду и реальные задачи бизнеса.