Начните с модели угроз и критичных функций

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

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

Сопоставьте обычную нагрузку и известные пики, посмотрите журналы и сетевые ограничения сервера. Если обычная рекламная кампания уже приводит к очередям и ошибкам, сначала нужно устранить проблемы масштабирования и приложения. Анти-DDoS не заменяет работу с узкими местами.

Разместите фильтрацию перед ограниченными ресурсами

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

Схема зависит от типа услуги и архитектуры. Это может быть обратный прокси для веб-трафика, защищённый DNS или фильтрация на сетевом уровне. Проверьте, какие протоколы и порты защищаются, как обрабатываются API и WebSocket, где завершается TLS и кто управляет правилами.

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

Закройте прямой доступ к исходному серверу

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

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

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

Настройте фильтры с учётом реальных пользователей

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

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

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

Проверьте план, не создавая опасную нагрузку

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

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

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