Сайт внезапно перестал открываться, поддержка хостинга разводит руками, а графики аналитики показывают обрыв трафика в ноль. В такой ситуации важно быстро понять: это случайный сбой или целенаправленная атака — от ответа зависит план действий. Заказать «завал» чужого сайта на чёрном рынке стоит от нескольких тысяч рублей, а мотивом может быть что угодно: вымогательство, месть уволенного сотрудника или действия конкурентов. Хорошая новость в том, что многослойная защита позволяет автоматически отбивать подавляющее большинство атак. Разберём, как диагностировать проблему, какие меры реально работают и что нужно настроить до того, как прилетит первый запрос с ботнета.
Атака или сбой хостинга: сравниваем симптомы
Для посетителя результат одинаков — сайт не открывается. Но в логах и метриках разница видна почти сразу, и именно она определяет дальнейшие шаги. Типичные признаки DDoS-атаки:- Трафик вырос в разы или десятки раз за считаные минуты, причём запросы идут к одной странице или API-эндпоинту.
- Тысячи уникальных IP-адресов, часто из неожиданных стран или из диапазонов дата-центров, а не мобильных операторов.
- Массовые ошибки 502, 503 и 504 при живом сервере: процессы запущены, но не успевают отвечать на поток запросов.
- Аномальное число сетевых соединений — netstat показывает тысячи одновременных подключений.
- Проблема подтверждена на статус-странице провайдера или затрагивает соседние сайты на том же сервере.
- Ошибки начались сразу после деплоя или обновления и нарастали плавно, без резкого скачка.
- В логах нет всплеска запросов: нагрузка обычная, но сервис не отвечает.
Первые 30 минут инцидента: пошаговый план
Когда диагноз ясен или время поджимает, действуйте по заранее готовому сценарию, а не изобретайте его в панике:- Зафиксируйте доказательства: сохраните логи, скриншоты графиков трафика и переписку с вымогателями, если она есть. DDoS квалифицируется по ст. 272 УК РФ, но без логов заявление не имеет веса.
- Свяжитесь с хостингом и уточните характер проблемы — у многих провайдеров есть базовая анти-DDoS-защита, которую нужно просто активировать.
- Выведите статическую заглушку «Скоро вернёмся» с контактами и поставьте платные рекламные кампании на паузу: платить за трафик на лежащий сайт — двойные потери.
- Временно закройте админку, формы и регистрацию по белому списку IP — часто атаки бьют именно по этим точкам.
- Подключите облачную защиту: если DNS заранее делегирован провайдеру, переключение занимает от 15 минут до пары часов.
Rate limiting: первая линия обороны
Rate limiting ограничивает количество запросов от одного пользователя за период времени и отрезает самые дешёвые атаки ещё на подлёте. Практичные ориентиры для бизнес-сайта: 30–60 запросов в минуту с одного IP на обычные страницы, не более 5 попыток входа в минуту на POST /login, не более 5–10 отправок формы заявки в час с одного адреса. При превышении сервер отдаёт код 429 Too Many Requests, а подозрительных клиентов можно отправлять на капчу вместо полной блокировки. На уровне Nginx это настраивается директивой limit_req, в Cloudflare и аналогичных сервисах — через правила без правок кода. Важно понимать ограничение метода: распределённая атака с ботнета из тысяч IP обойдёт лимиты по одному адресу, поэтому rate limiting работает только в связке с CDN и WAF.CDN: рассеять объёмную атаку
Против атак, которые просто «заливают» канал гигабитами трафика, работает только распределённая инфраструктура. CDN-провайдер с анти-DDoS принимает трафик на собственной сети (технология Anycast), размазывает атаку по десяткам точек присутствия и фильтрует мусор — до вашего сервера доходит уже очищенный поток. Бонус: статика отдаётся из кэша, поэтому при кэш-попадании 80–90% атака часто вообще не долетает до origin, а часть сайта продолжает работать даже во время инцидента. Ключевое условие — скрыть реальный IP сервера: если атакующий узнаёт адрес origin, он обойдёт CDN ударом напрямую. Настройте файрвол так, чтобы сервер принимал входящие соединения только с диапазонов CDN, и проверьте, что IP не «светится» в старых DNS-записях, субдоменах и заголовках почты. Для российского бизнеса рабочие варианты — DDoS-Guard, StormWall, Qrator Labs и защита уровня хостинга; выбор зависит от географии аудитории и требований к хранению данных.WAF: фильтр содержимого запросов
Если CDN борется с объёмом, то WAF (Web Application Firewall) анализирует содержимое каждого запроса. Он отбивает атаки прикладного уровня (L7), где боты имитируют поведение реальных пользователей, а также SQL-инъекции, XSS и перебор паролей — то, что часто идёт под прикрытием DDoS. Типовые механизмы: JS-челлендж, который браузер выполняет, а примитивный бот — нет, проверка репутации IP, сигнатурные правила и отдельные лимиты на конкретные эндпоинты. На практике связка CDN + WAF закрывает около 90% типовых атак на корпоративный сайт и интернет-магазин, а сложные таргетированные атаки остаются зоной контракта с анти-DDoS-провайдером и SLA. Настраивайте WAF аккуратно: начните с режима «только логирование», отладьте правила на реальном трафике и лишь потом включайте блокировку, чтобы не резать запросы настоящих покупателей.Что настроить заранее: чек-лист подготовки
Защита работает тогда, когда она готова до атаки, а не во время неё. Пройдите по списку и отметьте, что у вас уже закрыто:- DNS делегирован облачному провайдеру защиты — переключение под атакой займёт часы, которых у вас не будет.
- IP origin-сервера скрыт, файрвол принимает трафик только с диапазонов CDN.
- Rate limiting включён на входе, регистрации, формах, поиске и API.
- Внешний мониторинг отправляет алерты в Telegram — узнавать о лежащем сайте от клиента худший сценарий.
- Логи хранятся 30–90 дней: без них не восстановить картину атаки и не доказать её правоохранителям.
- Есть письменный план реагирования на полстраницы: контакты хостинга, анти-DDoS-провайдера и ответственные люди.
- Сценарий прорепетирован хотя бы на тестовом окружении — так вы найдёте слабые места до реального инцидента.

