Главная/Блог/DDoS-атака на сайт: как отличить её от сбоя хостинга и настроить защиту заранее

DDoS-атака на сайт: как отличить её от сбоя хостинга и настроить защиту заранее

DDoS-атака на сайт: как отличить её от сбоя хостинга и настроить защиту заранее
Сайт внезапно перестал открываться, поддержка хостинга разводит руками, а графики аналитики показывают обрыв трафика в ноль. В такой ситуации важно быстро понять: это случайный сбой или целенаправленная атака — от ответа зависит план действий. Заказать «завал» чужого сайта на чёрном рынке стоит от нескольких тысяч рублей, а мотивом может быть что угодно: вымогательство, месть уволенного сотрудника или действия конкурентов. Хорошая новость в том, что многослойная защита позволяет автоматически отбивать подавляющее большинство атак. Разберём, как диагностировать проблему, какие меры реально работают и что нужно настроить до того, как прилетит первый запрос с ботнета.

Атака или сбой хостинга: сравниваем симптомы

Для посетителя результат одинаков — сайт не открывается. Но в логах и метриках разница видна почти сразу, и именно она определяет дальнейшие шаги. Типичные признаки DDoS-атаки:
  • Трафик вырос в разы или десятки раз за считаные минуты, причём запросы идут к одной странице или API-эндпоинту.
  • Тысячи уникальных IP-адресов, часто из неожиданных стран или из диапазонов дата-центров, а не мобильных операторов.
  • Массовые ошибки 502, 503 и 504 при живом сервере: процессы запущены, но не успевают отвечать на поток запросов.
  • Аномальное число сетевых соединений — netstat показывает тысячи одновременных подключений.
Типичные признаки сбоя хостинга:
  • Проблема подтверждена на статус-странице провайдера или затрагивает соседние сайты на том же сервере.
  • Ошибки начались сразу после деплоя или обновления и нарастали плавно, без резкого скачка.
  • В логах нет всплеска запросов: нагрузка обычная, но сервис не отвечает.
Подключите внешний мониторинг доступности (UptimeRobot, Freshping) заранее: он зафиксирует недоступность извне, даже если собственная панель хостинга тоже лежит.

Первые 30 минут инцидента: пошаговый план

Когда диагноз ясен или время поджимает, действуйте по заранее готовому сценарию, а не изобретайте его в панике:
  1. Зафиксируйте доказательства: сохраните логи, скриншоты графиков трафика и переписку с вымогателями, если она есть. DDoS квалифицируется по ст. 272 УК РФ, но без логов заявление не имеет веса.
  2. Свяжитесь с хостингом и уточните характер проблемы — у многих провайдеров есть базовая анти-DDoS-защита, которую нужно просто активировать.
  3. Выведите статическую заглушку «Скоро вернёмся» с контактами и поставьте платные рекламные кампании на паузу: платить за трафик на лежащий сайт — двойные потери.
  4. Временно закройте админку, формы и регистрацию по белому списку IP — часто атаки бьют именно по этим точкам.
  5. Подключите облачную защиту: если DNS заранее делегирован провайдеру, переключение занимает от 15 минут до пары часов.
Назначьте ответственных заранее: кто звонит хостингу, кто включает заглушку, кто пишет в поддержку анти-DDoS-провайдера. Чёткое распределение ролей экономит больше времени, чем любой инструмент.

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-провайдера и ответственные люди.
  • Сценарий прорепетирован хотя бы на тестовом окружении — так вы найдёте слабые места до реального инцидента.
Пунктами «мониторинг» и «логи» часто пренебрегают, а именно они превращают хаос в управляемый процесс: вы сразу видите масштаб, характер и источник проблемы.

Сколько стоит защита и как считать окупаемость

Базовые тарифы CDN с анти-DDoS стоят от 20–30 $ в месяц или от 2–5 тыс. ₽ специализированная защита с SLA и гарантированным отражением атак — от 15–30 тыс. ₽ в месяц и выше. Теперь сравните с ценой простоя: если интернет-магазин делает 300 тыс. ₽ выручки в день, каждый час офлайна стоит 12–25 тыс. ₽ недополученной прибыли, плюс «сгоревший» рекламный бюджет и просевшие позиции в поиске. Атака на 6–12 часов легко перекрывает годовой бюджет защиты, а при этом у атакующего экономика всегда на его стороне — если вы не готовы. Отдельная строка расходов — реагирование: если штатного администратора нет, выбирайте тариф с поддержкой провайдера, который сам переключит трафик и поможет с настройкой при инциденте.

Итог

DDoS — это не «проблема хостинга», а вопрос непрерывности бизнеса, и решается он слоями, а не одним инструментом. Rate limiting отрезает дешёвые атаки и брутфорс, CDN держит удар объёмом, WAF фильтрует умных ботов и атаки на приложение — вместе они закрывают подавляющее большинство сценариев. Главное — настроить всё до инцидента: спрятать origin, делегировать DNS, включить мониторинг и написать план реагирования. Если не уверены в текущей конфигурации, начните с аудита защиты: один день работы специалистов дешевле даже часа простоя интернет-магазина, а план действий на случай атаки должен лежать под рукой так же, как план эвакуации при пожаре.

Нужна разработка?

Оставьте заявку — обсудим ваш проект и предложим решение