DDoS-защита сайта: что уточнить у хостинга до и во время атаки

Чем подтвердить, что сайт атакуют

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

Недоступность ещё не называет причину. Тот же внешний симптом возможен при ошибке приложения, проблеме сервера или перегрузке, поэтому сообщение в поддержку должно содержать наблюдаемые факты: адрес, время начала, доступность разных разделов и изменения, которые происходили перед сбоем. Время указывают с часовым поясом. Поддержка сопоставляет его со своими данными, а разработчик — с журналом работ на сайте.

Просить подтверждение атаки полезнее, чем спорить с её названием. Хостинг может показать изменение входящего потока, срабатывание фильтрации и затронутый ресурс. Разработчик объяснит, как в этот момент отвечает приложение. Если сведения ещё собираются, в рабочей записи так и отмечают: причина уточняется, ответственный назначен, следующий контакт известен. Уверенная версия без данных не помогает выбрать действие и способна задержать исправление обычной ошибки сайта.

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

Защита канала и защита приложения

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

В документации Yandex DDoS Protection базовая защита относится к сетевому и транспортному уровням L3 и L4. Отдельный сервис Smart Web Security работает на уровне приложения L7. Эти обозначения полезны в запросе хостингу: они позволяют обсуждать конкретный состав услуги. Покупать защиту только по слову «DDoS» в тарифе недостаточно, если у сайта уязвимое место связано с обработкой обычных веб-запросов.

Уровни дополняют друг друга.

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

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

Что именно входит в услугу

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

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

В описании запроса расширенной защиты Yandex Cloud среди сведений фигурируют число ресурсов, необходимость защиты HTTPS и критичное время недоступности. Для обычного трафика собирают максимальную частоту пакетов PPS и запросов RPS. PPS — количество сетевых пакетов в секунду, RPS — количество запросов в секунду. Это разные единицы, поэтому сравнивать предложения по безымянному «числу запросов» неудобно: сначала выясняют, что именно измерено.

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

Ответ поддержки не означает восстановления сайта.

Границы сайта и подключение фильтрации

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

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

Прямой доступ тоже обсуждают заранее.

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

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

Когда защита мешает покупателю

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

Просмотр формы не подтверждает отправку. Поэтому её проходят с тестовыми ответами, а не только открывают на экране.

В Smart Web Security разные инструменты выполняют разные задачи: WAF защищает от эксплуатации уязвимостей приложения, а ARL ограничивает количество запросов по заданным условиям. В обзоре сервиса также описана возможность направить запрос на дополнительную проверку через SmartCaptcha. Подрядчик показывает, где используется каждый инструмент и как он отличает блокировку нежелательного обращения от помехи реальному клиенту. Отдельно выбирают действия для приёмки после изменения правил. Владелец сайта знает, кто пройдёт форму и кто посмотрит результат внешнего уведомления.

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

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

Порядок действий при недоступности

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

У каждого действия есть автор. Это позволяет остановить противоречащие друг другу работы.

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

В карточке инцидента фиксируют начало, затронутые функции и подтверждённую причину либо текущую гипотезу. Изменения записывают по мере выполнения, со временем и ответственным. Рядом сохраняют результат внешней проверки. Неудавшееся действие тоже остаётся в хронологии: следующему специалисту полезно знать, что уже пробовали и какой ответ получили. Координатор хранит хронологию рядом с обращением в поддержку. После восстановления по этой записи определяют, каких данных или контактов не хватило для более быстрого решения.

Если часть сайта доступна, приоритет задают по рабочим операциям. Каталог, отправка обращения и получение внешнего уведомления могут восстанавливаться по-разному. Решение о временном ограничении функции согласуют с владельцем её бизнес-результата и объясняют клиенту понятным сообщением на доступном участке сайта.

Возвращение к обычной работе

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

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

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

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

Карточка услуги для владельца сайта

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

Ответственность должна быть названа прямо.

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

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