Вы обнаружили, что сайт недоступен или работает очень медленно. Панель управления хостингом показывает аномальный трафик, а в логах — тысячи запросов в секунду. С вероятностью 90% это DDoS-атака (распределённая атака типа «отказ в обслуживании»). Что делать? Главное — не паниковать и следовать чёткому алгоритму. Разберём действия по шагам: от диагностики до восстановления и профилактики.
Шаг первый — подтверждение атаки
Убедитесь, что проблема не в вашем локальном соединении, не в обновлении CMS и не в ошибке конфигурации. Проверьте доступность сайта через сторонние сервисы. Зайдите в панель управления сервером или хостингом и посмотрите графики трафика, загрузки CPU, количество соединений. Если показатели взлетели в десятки раз — это DDoS. Также характерный признак: атака может идти волнами, с паузами.
Шаг второй — свяжитесь с техподдержкой хостинг-провайдера
Не тратьте время на самостоятельную борьбу, если у вас нет опыта. У хорошего провайдера есть круглосуточная поддержка и протоколы реакции на DDoS. Предоставьте им IP-адрес вашего сервера, время начала атаки, примерную интенсивность (если видите). Провайдер может включить фильтрацию на своём сетевом оборудовании, изменить маршрутизацию или временно заблокировать вредоносные IP-адреса. Это самый эффективный шаг.
Шаг третий — активируйте защитные механизмы на вашей стороне
Если вы используете CDN (Cloudflare, Akamai, Qrator), переключите режим в «I’m Under Attack». Это включит дополнительную проверку посетителей (например, JavaScript-вычисления) и отсечёт ботов. На уровне сервера (если есть доступ к панели или SSH) можно ограничить число запросов с одного IP с помощью rate limiting в Nginx или fail2ban. Также временно отключите ресурсоёмкие функции: поиск, форму комментариев, API. Если атака идёт на конкретную страницу — можно временно заменить её статической заглушкой.
Шаг четвёртый — примите решение о смене IP-адреса
Если атака идёт непосредственно на IP вашего сервера (а не на доменное имя), и провайдер не может её отфильтровать, попросите выделить новый IP. Но будьте готовы, что через DNS (обычно за 5-30 минут) трафик перейдёт на новый адрес. Однако умные ботнеты могут узнать новый IP через DNS-записи, поэтому смена IP работает только в связке с сокрытием реального адреса за CDN или прокси.
Шаг пятый — не платите вымогателям
Атаки часто сопровождаются письмами с требованием выкупа. Платеж не гарантирует прекращения атаки — напротив, вы показываете уязвимость. Вместо этого фиксируйте доказательства (логи, письма) и при необходимости обращайтесь в правоохранительные органы. В России действует статья 272 УК РФ (неправомерный доступ к компьютерной информации) и 273 (создание вредоносных программ).
После того как атака стихла (обычно через несколько часов или дней), проведите анализ. Посмотрите логи, определите тип атаки: объёмная (забивает канал), протокольная (истощает ресурсы TCP/IP) или прикладная (имитирует запросы к базе данных). Каждый тип требует своей стратегии защиты. Обновите конфигурацию веб-сервера — например, настройте лимиты на размер буфера, таймауты, количество одновременных соединений. Установите модуль mod_evasive для Apache или limit_req_zone для Nginx.
Что делать, чтобы атака не повторилась?
Профилактика включает несколько этапов. Во-первых, используйте CDN с защитой от DDoS. Во-вторых, не светите реальный IP сервера; все DNS-записи должны указывать на CDN. В-третьих, настройте автоматический мониторинг и оповещения при резком скачке трафика. В-четвёртых, имейте план аварийного восстановления и контакты техподдержки под рукой. И наконец, регулярно обновляйте всё ПО — через уязвимости веб-приложений часто запускают прикладные DDoS.
Кстати, выбирая хостинг-провайдера, обращайте внимание на наличие встроенной защиты от DDoS. Некоторые облачные платформы, такие как CloudX, предоставляют базовую фильтрацию на уровне сети, а также могут предложить аренду дополнительных IP-адресов для распределения нагрузки.
Помните: DDoS-атака — это не приговор. Большинство проектов успешно отражают атаки, если действуют быстро и скоординированно. Подготовьтесь заранее: продумайте, кто звонит в техподдержку, кто принимает решение о смене IP, кто общается с клиентами. И тогда реальный инцидент пройдёт без паники и с минимальным ущербом.