Как защитить сайт от DDoS-атак

Природа DDoS-атак

DDoS-атака — это попытка сделать сайт или онлайн-сервис недоступным, направив на его инфраструктуру большое количество запросов или сетевого трафика. В отличие от обычной DoS-атаки, нагрузка поступает одновременно из множества источников — например, с зараженных компьютеров, серверов и IoT-устройств, объединенных в ботнет. Поэтому заблокировать атаку по одному IP-адресу невозможно.

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

Сетевые атаки L3/L4 и атаки на приложение L7

DDoS-атаки принято разделять по уровням модели OSI. На практике особенно важно отличать сетевые атаки уровней L3/L4 от атак на приложение уровня L7: для их обнаружения и нейтрализации нужны разные инструменты.

Атаки L3/L4 направлены на сетевую инфраструктуру и транспортные протоколы. Их задача — переполнить интернет-канал, исчерпать таблицу соединений или перегрузить маршрутизаторы, межсетевые экраны и балансировщики. К этой категории относятся объемные UDP-флуды, SYN-флуды и атаки с усилением трафика. Их характерный признак — резкий рост количества пакетов, соединений или общей пропускной способности. Даже если веб-сервер настроен правильно, сайт может стать недоступным из-за перегрузки канала связи. Защищаться от таких атак необходимо на стороне дата-центра, провайдера или облачного Anti-DDoS-сервиса: локальная фильтрация не поможет, если вредоносный трафик уже занял весь доступный канал.

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

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

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

Как злоумышленники находят слабые места

Перед атакой злоумышленники могут собирать общедоступные сведения об инфраструктуре сайта. Их интересуют реальные IP-адреса серверов, используемые технологии, DNS-записи, поддомены, открытые сетевые службы и особенности поведения приложения. Часть этой информации раскрывается через публичные реестры, поисковые системы, архивы DNS, заголовки HTTP и сообщения об ошибках.

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

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

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

Базовая подготовка и архитектура сервера

Устойчивость сайта к DDoS-атакам во многом зависит от решений, принятых еще до запуска проекта. Если сервер напрямую доступен из интернета, злоумышленник может атаковать его в обход CDN, WAF и других внешних средств фильтрации. Поэтому базовая задача — скрыть реальную инфраструктуру и выбрать площадку, способную отсеивать вредоносный трафик на сетевом уровне.

Сокрытие реального IP-адреса хостинга

Публичный IP-адрес основного сервера не должен отображаться в DNS-записях сайта. Между пользователем и сервером следует разместить обратный прокси, CDN или облачный сервис Anti-DDoS. В этом случае посетители подключаются к узлам защитной сети, где трафик анализируется и фильтруется, а на хостинг передаются только разрешенные запросы.

Однако одного проксирования недостаточно. IP-адрес origin-сервера может раскрыться через:

• Старые DNS-записи и историю изменений домена;
• Технические поддомены, подключенные напрямую к серверу;
• Записи для почты, FTP, панелей управления и API;
• Исходящие письма с сервера;
• Доступ по IPv6, если защита настроена только для IPv4;
• Ошибки конфигурации или размещение нескольких сервисов на одном адресе.

После подключения CDN или защитного прокси желательно сменить IP-адрес сервера, особенно если прежний адрес уже был публичным. На уровне межсетевого экрана необходимо разрешить входящие HTTP- и HTTPS-подключения только с IP-диапазонов используемого CDN или Anti-DDoS-провайдера. Административные порты следует закрыть для общего доступа: SSH и панель управления лучше открывать только через VPN либо для доверенных адресов.

Почтовые и другие вспомогательные сервисы целесообразно вынести на отдельные серверы. Такая изоляция уменьшает вероятность раскрытия origin-IP и не позволяет атаке на один компонент вывести из строя всю инфраструктуру. Важно также регулярно проверять DNS-записи, открытые порты и доступность сервера в обход прокси.

Выбор дата-центра с аппаратной Anti-DDoS-защитой

Даже правильно скрытый сервер нуждается в защите со стороны хостинг-провайдера. При масштабной атаке канал связи может быть переполнен раньше, чем трафик достигнет программного межсетевого экрана. Локальные настройки Nginx, iptables или операционной системы в такой ситуации уже не помогут. Фильтрация должна происходить на сетевой инфраструктуре дата-центра либо в специализированном центре очистки трафика.

При выборе площадки стоит уточнить:

• Какую максимальную мощность атаки способен обработать провайдер;
• Защищает ли сервис от атак уровней L3/L4, включая UDP-, SYN- и ICMP-флуд;
• Предусмотрена ли фильтрация атак на уровне приложения L7;
• Работает ли защита постоянно или включается только после обнаружения инцидента;
• Сколько времени занимает перенаправление трафика в центр очистки;
• Есть ли ограничения по объему легитимного трафика и числу запросов;
• Предоставляет ли провайдер отчеты, логи и оперативную техническую поддержку;
• Какие действия применяются при превышении заявленных лимитов — фильтрация, ограничение канала или блокировка IP.

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

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

Облачные сервисы фильтрации трафика

Облачная Anti-DDoS-платформа принимает запросы к сайту на себя, анализирует их и передает серверу только легитимный трафик. Благодаря распределенной инфраструктуре такой сервис способен поглощать нагрузку, которая значительно превышает возможности отдельного сервера или даже дата-центра. Однако простого подключения CDN недостаточно: необходимо правильно настроить DNS, проксирование, правила фильтрации и доступ к реальному серверу.

Использование CDN для распределения нагрузки

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

При выборе CDN следует учитывать не только количество точек присутствия, но и наличие полноценной Anti-DDoS-защиты. Важны пропускная способность сети, автоматическое обнаружение аномалий, фильтрация атак на уровнях L3/L4 и L7, доступность технической поддержки и возможность быстро изменить режим защиты.

Для эффективной работы CDN рекомендуется:

• Настроить кэширование статического контента на длительный срок;
• Включить кэширование страниц, которые не содержат персональных данных;
• Исключить из кэша личные кабинеты, корзину, формы авторизации и другие динамические разделы;
• Активировать сжатие и оптимизацию изображений, если такие функции предоставляет сервис;
• Ограничить размер запросов и загрузок;
• Настроить защиту от частых обращений к ресурсоемким URL.

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

Настройка WAF и проксирования

Web Application Firewall работает на прикладном уровне и анализирует содержимое HTTP- и HTTPS-запросов. В отличие от обычного сетевого экрана, WAF способен выявлять подозрительные обращения к страницам авторизации, поиску, API, формам и другим функциям сайта. Он помогает блокировать не только L7-флуд, но и попытки SQL-инъекций, внедрения скриптов, обхода путей и эксплуатации известных уязвимостей.

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

Слишком жесткие правила способны заблокировать поисковых роботов, мобильные приложения, платежные системы и реальных посетителей. Поэтому WAF лучше сначала запускать в режиме мониторинга. После анализа событий и устранения ложных срабатываний правила можно перевести в режим активной блокировки. Исключения следует создавать точечно — для конкретного URL, параметра или доверенного IP-адреса, а не для всего домена.

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

• Корректную работу HTTPS между пользователем, облачным сервисом и сервером;
• Передачу реального IP посетителя в доверенном заголовке;
• Поддержку WebSocket и других используемых протоколов;
• Ограничения для API и административной панели;
• Отсутствие DNS-записей, раскрывающих адрес сервера;
• Ведение и сохранение журналов заблокированных запросов.

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

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

Тюнинг веб-сервера (Nginx/Apache) для защиты от флуда

Грамотная настройка веб-сервера помогает сдерживать HTTP-флуд и атаки на уровне приложения (L7). Она не заменяет защиту дата-центра или облачную фильтрацию: если злоумышленники полностью забили канал связи, локальные правила уже не помогут. Однако тюнинг Nginx или Apache позволяет экономнее расходовать процессорное время и память, ограничивать агрессивных клиентов и сохранять доступность сайта при умеренной атаке.

Лимитирование запросов и подключений

Rate Limiting ограничивает частоту запросов от одного источника. При настройке важно учитывать не только IP-адрес, но и тип ресурса. Например, для страницы авторизации, формы поиска и API допустимый порог обычно ниже, чем для статических файлов.

В Nginx частоту запросов можно контролировать с помощью limit_req_zone и limit_req:

http {
    limit_req_zone $binary_remote_addr zone=per_ip:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=connections:10m;

    server {
        location / {
            limit_req zone=per_ip burst=20 nodelay;
            limit_conn connections 20;
        }

        location = /login {
            limit_req zone=per_ip burst=5;
        }
    }
}

Параметр rate=10r/s разрешает в среднем десять запросов в секунду с одного IP. burst допускает кратковременный всплеск, а limit_conn ограничивает число одновременных подключений. Пороговые значения следует подбирать по журналам реального трафика: слишком жесткие лимиты способны заблокировать обычных посетителей, корпоративные сети и пользователей мобильных операторов, выходящих в интернет через общий адрес.

Если Nginx работает за CDN или обратным прокси, сначала необходимо корректно восстановить IP клиента через модуль Real IP. Доверять заголовкам X-Forwarded-For или аналогам можно только от известных адресов прокси-сервиса — иначе злоумышленник сможет подменить источник запроса.

В Apache для аналогичных задач применяют модули mod_evasive, mod_security и правила WAF. Ограничить количество рабочих процессов и соединений помогают директивы MaxRequestWorkers, ServerLimit и KeepAlive. Значения должны соответствовать объему оперативной памяти и используемой модели MPM. Бесконтрольное увеличение числа воркеров часто ухудшает ситуацию: под флудом сервер быстрее исчерпывает ресурсы.

Лимиты желательно вводить поэтапно. Сначала правила запускают в режиме мониторинга, анализируют число срабатываний, а затем включают блокировку или возврат кодов 429 Too Many Requests и 503 Service Unavailable.

Управление таймаутами

Медленные атаки, включая Slowloris, удерживают соединения открытыми и постепенно передают данные, занимая доступные воркеры. Снизить эффективность таких атак позволяют разумные таймауты.

Для Nginx можно настроить:

server {
    client_header_timeout 10s;
    client_body_timeout 10s;
    send_timeout 15s;

    keepalive_timeout 15s;
    keepalive_requests 100;

    client_max_body_size 10m;
    reset_timedout_connection on;
}

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

В Apache следует пересмотреть параметры Timeout и KeepAliveTimeout, а также включить mod_reqtimeout. Например:

RequestReadTimeout header=10-20,MinRate=500 body=10,MinRate=500
KeepAlive On
KeepAliveTimeout 3
MaxKeepAliveRequests 100

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

GeoIP-блокировки

Если сайт работает только с определенными странами, трафик из остальных регионов можно ограничить по данным GeoIP. Более безопасный подход — применять географические правила избирательно: например, закрывать доступ к административной панели, форме авторизации или API, а не ко всему сайту.

В Nginx географические ограничения настраивают через GeoIP2-модуль и базу адресов, например MaxMind GeoLite2. На практике правило может выглядеть так:

map $geoip2_data_country_code $blocked_country {
    default 1;
    RU 0;
    KZ 0;
    BY 0;
}

server {
    location /admin/ {
        if ($blocked_country) {
            return 403;
        }

        proxy_pass http://backend;
    }
}

Конкретный синтаксис зависит от сборки Nginx и установленного GeoIP-модуля. В Apache географическую фильтрацию можно реализовать с помощью mod_maxminddb, Require и правил доступа.

GeoIP нельзя считать безошибочной защитой. Атакующие используют прокси, VPN и зараженные устройства в разрешенных регионах, а географические базы иногда определяют адрес неверно. Кроме того, массовая проверка геолокации непосредственно веб-сервером создает дополнительную нагрузку. Поэтому при крупной атаке эффективнее выполнять такую фильтрацию на стороне CDN, WAF или провайдера Anti-DDoS.

После любых изменений конфигурацию необходимо проверить командами nginx -t или apachectl configtest, а затем применить без разрыва активных соединений. Одновременно следует контролировать коды ответов, задержки, загрузку CPU, расход памяти и количество ложных блокировок. Наилучший результат дает сочетание лимитов, корректных таймаутов, кэширования и внешней фильтрации трафика.

Оптимизация работы приложения

Даже правильно настроенный веб-сервер не всегда выдерживает DDoS-атаку на уровне приложения. Каждый запрос к динамической странице может запускать PHP-скрипты, обращения к базе данных, проверку сессии и работу сторонних модулей. Злоумышленнику достаточно многократно запрашивать ресурсоемкие URL, чтобы исчерпать процессорное время, оперативную память или пул подключений к СУБД. Поэтому важно уменьшить стоимость обработки одного запроса.

Агрессивное кэширование статики и динамики

Статические файлы — изображения, стили, JavaScript, шрифты и документы — следует отдавать через CDN или непосредственно веб-сервером, не подключая CMS. Для них настраивают длительный срок хранения в браузере и на промежуточных узлах. При обновлении файлов используют версионирование имен или параметров URL, чтобы посетители своевременно получали актуальную версию.

Динамические страницы также желательно кэшировать. В зависимости от архитектуры сайта можно применять:

• Полностраничный кэш — для страниц, одинаковых для большинства пользователей;
• Микрокэширование — на несколько секунд для часто запрашиваемых URL;
• Объектный кэш — Redis или Memcached для результатов запросов и вычислений;
• Кэширование ответов API, если данные не должны обновляться в реальном времени;
• Предварительную генерацию страниц — для каталогов, публикаций и других публичных разделов.

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

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

Отключение тяжелых модулей

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

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

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

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

Блокировка вредоносных User-Agent

Анализ журналов может показать, что значительная часть подозрительных запросов поступает с одинаковым или явно некорректным User-Agent. Такие обращения можно блокировать на уровне WAF, Nginx, Apache или CMS. Также имеет смысл ограничить устаревших ботов и сканеры, которые создают лишнюю нагрузку.

Однако User-Agent легко подделать, поэтому этот признак нельзя использовать как единственный критерий. Эффективнее учитывать совокупность факторов: частоту запросов, IP-адрес и автономную систему, географию, наличие cookies, поведение клиента, запрашиваемые URL и корректность HTTP-заголовков. Блокировки необходимо регулярно пересматривать, чтобы не закрыть доступ поисковым роботам, системам мониторинга и обычным посетителям.

Оптимизация CMS и базы данных не заменяет CDN, WAF и сетевую Anti-DDoS-защиту, но значительно увеличивает запас прочности приложения. Чем меньше ресурсов требуется для обработки одного запроса, тем сложнее злоумышленнику вывести сайт из строя даже при интенсивном флуде.

План реагирования: что делать прямо сейчас, если сайт «лежит»

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

Анализ логов для выявления паттернов атаки

Основные источники информации — журналы доступа и ошибок Nginx или Apache, логи приложения, WAF и CDN. Обратите внимание на следующие признаки:

• Резкое увеличение количества запросов в секунду;
• Множество обращений с одних и тех же IP-адресов или подсетей;
• Массовые запросы к ресурсоемким страницам: поиску, авторизации, API, формам, оформлению заказа;
• Необычные HTTP-методы, URL с длинными параметрами и повторяющиеся запросы;
• Большое число ответов с кодами 404, 429, 502, 503 и 504;
• Одинаковые или подозрительные значения User-Agent;
• Аномальный трафик из регионов, где у сайта обычно нет аудитории.

Для первичного анализа журнала Nginx можно использовать стандартные Linux-команды:

IP-адреса с наибольшим числом запросов
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Наиболее часто запрашиваемые URL
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

Распределение кодов ответа
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

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

Активация режима Under Attack и связь с хостером

Если сайт подключен к CDN или облачному сервису защиты, активируйте режим Under Attack либо его аналог. В этом режиме каждый новый посетитель проходит дополнительную проверку, а подозрительные автоматические запросы блокируются на стороне провайдера, не достигая сервера. Одновременно можно временно повысить уровень безопасности WAF, включить проверку JavaScript, ужесточить Rate Limiting и ограничить доступ к административным разделам.

Перед включением защиты убедитесь, что реальный IP-адрес сервера не доступен напрямую. Иначе злоумышленники смогут обойти CDN и продолжить атаку на хостинг. Разрешите входящие HTTP- и HTTPS-соединения к origin-серверу только с доверенных адресов прокси-сервиса, но заранее сохраните доступ по SSH через отдельный разрешенный IP или VPN.

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

• IP-адрес атакуемого сервера и домен;
• время начала и продолжительность атаки;
• примерный объем и тип трафика;
• атакуемые порты и URL;
• фрагменты логов и список подозрительных подсетей;
• информацию об уже принятых мерах.

Попросите активировать Anti-DDoS-фильтрацию, перенаправить трафик через центр очистки или применить временные сетевые правила. Не соглашайтесь на блокировку IP сервера без уточнения условий: blackhole остановит атаку на инфраструктуру, но одновременно сделает сайт полностью недоступным.

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