DDoS-защита и WAF на хостинге: какие задачи они закрывают

Как оценить DDoS-защиту и WAF по покрытию услуги, подготовить DNS и TLS, проверить обычные запросы и вебхуки, разобрать ложную блокировку и сохранить ограниченный план возврата.

Разделите слои

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

У Beget официально заявлена защита L3/L4; дополнительные прикладные сервисы рассматриваются отдельно. Не распространяйте формулировку с одной страницы на все возможные угрозы и не выдавайте заявление поставщика за независимый тест HOSTIO.

Что выяснить у поставщика

Составьте модель доступности своего приложения

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

Покрытие L3/L4, указанное поставщиком, не следует представлять как подтверждённую фильтрацию всех прикладных угроз. На странице VPS Beget заявлена постоянная сетевая и транспортная защита; это заявление продукта, а не независимое испытание HOSTIO. Для другого продукта и дополнительных опций нужны отдельные документы и цена.

Подготовьте подключение

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

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

Подготовьте маршрутизацию и доверенные признаки клиента

При работе через прокси приложение может видеть адрес промежуточного узла вместо посетителя. Правила доверия к переданным заголовкам должны соответствовать документированной сети поставщика; нельзя принимать произвольный X-Forwarded-For от любого источника как достоверную личность. Иначе ограничения и журнал будут опираться на подставляемое значение. Настройку выполняет администратор по реальной схеме.

Для origin согласуйте допустимые пути доступа и аварийного управления. Не публикуйте скрытый адрес сервера в открытом отчёте о защите. При этом ограничение origin не должно случайно отрезать согласованный мониторинг, обновление сертификата или резервирование. Каждое исключение имеет назначение, владельца и минимальную область, а не общий принцип «доверять всему».

Изменение: защитный сервис и версия правил
Маршруты: публичные / кабинет / API / callback
TLS: проверен на нужных участках
DNS: исходная зона сохранена
Журнал: доступен ответственному
Исключения: конкретное правило и область
Возврат: подтверждённая процедура поставщика

Проверьте нормальный трафик

Откройте сайт с разных допустимых клиентов и проверьте форму, вход, поиск и заказ в тестовом режиме. Следите за заблокированными запросами и причиной правила. Разрешение должно опираться на конкретный сценарий, а не на случайный User-Agent, который легко подделать.

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

Разберите ложное срабатывание по идентификатору

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

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

1. Подтвердите, что запрос легитимен и разрешён этой роли.
2. Сохраните обезличенную запись блокировки.
3. Определите правило, маршрут и конкретный параметр.
4. Согласуйте минимальное исключение штатным способом.
5. Повторите исходный запрос и соседние функции.
6. Убедитесь, что исключение не расширилось на посторонние маршруты.

Проверка интеграций без имитации атаки

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

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

План инцидента

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

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

Отличайте защитное событие от медленного приложения

Рост 403 может отражать блокировки, но рост времени ответа может происходить из-за SQL, очередей или внешнего API. Сопоставляйте журнал WAF, веб-сервера и приложения по времени. Увеличение чувствительности фильтра не исправляет обработчик импорта, который занимает весь пул PHP. Не называйте любой пик запросов атакой без анализа источников и поведения.

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

Возврат и контроль временных исключений

Сохраните исходные DNS и TLS-настройки и проверьте процедуру отключения или смены режима сервиса. Возврат не должен внезапно открыть origin или сломать сертификат. При изменении NS восстановление затрагивает всю зону, включая почту; это требует полной подготовленной схемы. Согласуйте порядок с ответственным администратором до рабочего переключения.

После инцидента пересмотрите добавленные исключения и подтвердите, что легитимные события не потеряны. Для webhook после тайм-аута сначала сверяйте состояние, затем повтор по правилам идемпотентности. Зафиксируйте, что именно проверено: нормальная работа маршрутов, настройка правил или отдельное разрешённое испытание. Эти виды доказательств нельзя смешивать.

FAQ и результат

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

Источники и дата

• OWASP: Web Application Firewall
• OWASP CRS: ложные срабатывания
• Beget: заявленная защита VPS
• Beget — описание инфраструктуры
• Beget — дополнительная защита

Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.