Как понять, что на сайт идет DDoS-атака: 20 признаков, чек-лист и инструкция по диагностике

Что такое DDoS-атака простыми словами

DDoS (Distributed Denial of Service) — распределенная атака, цель которой сделать сайт, приложение или API недоступными для пользователей. Обычно злоумышленник не пытается украсть данные: он создает столько соединений или запросов, что инфраструктура перестает обслуживать настоящих посетителей.

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

Интерактивная схема: как развивается DDoS-атака

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

Почему современные атаки сложно обнаружить

Примитивный поток одинаковых запросов с нескольких адресов обнаружить легко. Современные ботнеты меняют User-Agent, используют реальные браузеры и residential IP, выполняют JavaScript, сохраняют Cookie и имитируют переходы по страницам. Внешне такой трафик может напоминать рекламную кампанию или вирусный рост посещаемости.

Поэтому количества запросов недостаточно. Нужно одновременно оценивать:

• скорость и равномерность запросов;
• целевые URL и HTTP-методы;
• географию, ASN и тип сети;
• User-Agent, заголовки, Cookie и выполнение JavaScript;
• глубину просмотра, длительность сессий и конверсию;
• нагрузку на CPU, RAM, сеть, диск, приложение и базу данных.

Какие бывают DDoS-атаки

L7-атака часто опаснее для диагностики: запрос GET /catalog сам по себе не выглядит вредоносным. Проблема возникает, когда десятки тысяч клиентов повторяют его одновременно и вынуждают приложение выполнять дорогие операции.

20 признаков DDoS-атаки

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

1. Сайт неожиданно стал медленно работать

Страница, которая обычно отвечала за 500–700 мс, без релиза и маркетинговой активности загружается 5–15 секунд. Сначала проверьте origin, базу данных и внешние API: медленный сайт не всегда атакуют.

2. Массово появляются ошибки 502, 503 и 504

3. CPU постоянно загружен на 90–100%

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

4. Load Average вырос в несколько раз

Load Average отражает число процессов, выполняющихся или ожидающих ресурсы. Сравнивайте значение не с универсальным числом, а с количеством CPU-ядер и собственной базовой линией. Например, скачок с 0,8–1,1 до 15–40 без плановой задачи требует расследования.

5. Резко выросло количество HTTP-запросов

Скачок с десятков до сотен или тысяч запросов в секунду за короткий интервал подозрителен, особенно ночью или без рекламной кампании. Но абсолютный порог индивидуален: 500 RPS могут быть критичны для небольшого WordPress и нормальны для кешируемой статики.

6. Посещаемость выросла, а продаж и заявок больше не стало

Если число «посетителей» увеличилось в десять раз, но заказов столько же или меньше, проверьте качество трафика. Падение конверсии может объясняться ботами либо тем, что реальные клиенты не могут пользоваться перегруженным сайтом.

7. В логах тысячи одинаковых запросов

Повторяющиеся обращения к /wp-login.php, /xmlrpc.php, /.env, /.git/config или одному API-методу — сильный сигнал автоматизации. Однако сканирование уязвимостей и DDoS — не одно и то же: оцените интенсивность и влияние на ресурсы.

8. Большинство запросов сосредоточено на нескольких URL

Живые пользователи открывают карточки, статьи, корзину и формы. Атакующий выбирает дешевые для него, но дорогие для сервера точки: главную, поиск, фильтры, авторизацию, XML-RPC или API.

9. Резко выросло количество уникальных IP

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

10. Значительная доля IP принадлежит дата-центрам

Анализируйте ASN и тип сети. Поток из hosting/cloud-сетей может указывать на арендованные серверы или прокси. Но блокировать весь AWS, Google Cloud или Hetzner без контекста опасно: там могут находиться партнеры, API и полезные роботы.

11. Изменилась география трафика

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

12. User-Agent выглядит подозрительно

В логах могут появиться curl, python-requests, Go-http-client, старые версии браузеров или сотни тысяч полностью одинаковых строк. User-Agent легко подделать, поэтому проверяйте согласованность заголовков, TLS/HTTP fingerprint и поведение клиента.

13. Один IP выполняет сотни запросов в секунду

Человек редко генерирует сотни запросов каждую секунду с идеально равными интервалами. Исключения возможны для NAT, корпоративных сетей, API-клиентов и поисковых роботов — лимит должен учитывать назначение endpoint.

14. Клиенты не загружают CSS, JavaScript и изображения

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

15. Отсутствуют Cookie и устойчивые сессии

Простые боты игнорируют Cookie и каждый запрос начинают как новый клиент. Современные инструменты умеют поддерживать сессии, поэтому отсутствие Cookie — лишь один из сигналов.

16. Клиенты не выполняют JavaScript

JS-проверка отделяет часть простых HTTP-клиентов от браузеров. Но она не является абсолютным доказательством: поисковые роботы могут выполнять JavaScript, продвинутые боты используют headless-браузеры, а у реальных пользователей скрипты иногда заблокированы.

17. Нагрузка появляется ночью или в нетипичное время

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

18. Хостинг сообщает о превышении лимитов

Предупреждения о CPU, количестве процессов, соединениях или трафике часто становятся первым заметным сигналом. Запросите у провайдера сетевые графики и уточните, какой ресурс исчерпан.

19. Веб-сервер или приложение перезапускаются

OOM Killer, исчерпание workers и health-check могут вызывать рестарты nginx, Apache, PHP-FPM или контейнеров. Обязательно исключите утечку памяти, ошибочный deploy и внутреннюю задачу.

20. Поведение посетителей неестественно однообразно

Тысячи клиентов открывают один URL, проводят на нем доли секунды, не переходят по ссылкам и не взаимодействуют с формами. Чем больше независимых IP повторяют одинаковую последовательность, тем выше вероятность координированной автоматизации.

Как проверить, действительно ли на сайт идет DDoS-атака

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

Ниже — пошаговый алгоритм, который используют специалисты по информационной безопасности. Все этапы раскрыты по умолчанию; ненужные карточки можно свернуть нажатием на заголовок.

top
# или
htop

uptime
# или
cat /proc/loadavg

tail -f /var/log/nginx/access.log

tail -f /var/log/apache2/access.log

185.xxx.xxx.xxx GET /wp-login.php
185.xxx.xxx.xxx GET /wp-login.php
185.xxx.xxx.xxx GET /wp-login.php

GET /.env
GET /.env
GET /.git/config

awk '{print $1}' access.log | sort | uniq -c | sort -nr | head

awk '{print $7}' access.log | sort | uniq -c | sort -nr | head

Chrome/120
Chrome/120
Chrome/120
Chrome/120

Как отличить DDoS от сканирования сайта

Не вся подозрительная активность является DDoS. Массовые сканеры ищут панели администратора, резервные копии, открытые Git-репозитории, конфигурационные файлы, уязвимости CMS и забытые API.

Ключевое различие — не название URL, а объем, продолжительность и влияние на доступность. Один сканер может искать уязвимости, не создавая заметной нагрузки; распределенный поток тех же запросов способен превратиться в DDoS.

Что чаще всего ищут злоумышленники

Разбираем реальные ситуации

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

Ошибки диагностики

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

Самодиагностика за пять минут

Этот экспресс-тест не заменяет расследование, но помогает быстро понять, в какую сторону двигаться.

KPI здорового сайта

📊 Анатомия одной DDoS-атаки

Рассмотрим, как типичная L7-атака развивается по минутам — от первых ботов до пика нагрузки.

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

Как отличить DDoS от обычного роста посещаемости

Чек-лист: находится ли сайт под DDoS-атакой

Количество совпадений — ориентир, а не математическая модель. Вес признаков различается: кратный рост 5xx и исчерпание канала важнее одного необычного User-Agent.

Что делать в первые 10 минут

Не перезагружайте сервер сразу

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

Убедитесь, что ресурсы потребляет внешний трафик

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

Включите Rate Limiting

Начинайте с чувствительных URL и разумных лимитов. Учитывайте NAT и легитимные API-клиенты. Для распределенного low-rate HTTP Flood ограничения только по IP может быть недостаточно — комбинируйте их с сессиями, fingerprint, ASN и поведенческими сигналами.

Активируйте WAF и Reverse Proxy

Фильтрация должна происходить до origin. Закройте прямой доступ к реальному IP сервера, иначе атакующий сможет обойти защитный контур. Кешируйте безопасные ответы и ограничьте дорогие endpoint.

Какие показатели нужно контролировать постоянно

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

Считайте 5xx как долю от всех ответов и отслеживайте p95/p99 latency. Десять ошибок на десяти запросах опаснее десяти ошибок на миллионе.

🌍 Какие страны чаще становятся источниками подозрительного трафика

Ниже — не выдуманный пример, а снимок базы IP Reputation TrafficVeil на 12 июля 2026 года: 165 695 профилей с категориями suspicious или malicious. Проценты показывают долю IP-профилей, а не долю всех запросов.

📡 Какие сети чаще используются ботами

Оценка ниже отражает типичный уровень риска, а не автоматический вердикт для каждого адреса. Residential и mobile IP также могут входить в ботнет, а hosting-сеть может обслуживать полезный API.

🤖 Как отличить человека от бота

Матрица помогает отвечать на запросы «как отличить бота от человека», «как определить ботов» и «какие вредные боты заходят на сайт», но надежная классификация всегда использует сочетание признаков.

🚨 Наиболее часто запрашиваемые чувствительные URL

Рейтинг построен по реальным proxy-логам TrafficVeil за последние 24 часа на момент подготовки статьи. Это все обращения к шаблонам URL: среди них могут быть сканеры, боты и небольшая доля легитимных запросов, поэтому значения не следует трактовать как число подтвержденных DDoS-событий.

Источник: обезличенные данные сети TrafficVeil, окно 24 часа, снимок 12.07.2026. Всего за период обработано 4 038 337 запросов.

Как TrafficVeil обнаруживает аномальный трафик

TrafficVeil анализирует запросы на reverse proxy до их отправки на origin. Решение может учитывать сразу несколько групп сигналов:

• частоту запросов и повторяемость действий;
• страну, ASN, hosting/residential/mobile/proxy/VPN-сети;
• репутацию IP и известные источники угроз;
• User-Agent и согласованность HTTP-заголовков;
• работу с Cookie и выполнение JavaScript;
• обращения к чувствительным URL;
• срабатывания WAF, GeoIP, ASN-фильтров и bot detection.

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

Частые ошибки при реагировании

1. Блокировать целые страны без анализа. Это может отсечь клиентов, поисковых роботов и партнерские сервисы. Сочетайте GeoIP с ASN, репутацией и поведением.
2. Полностью отключать сайт. Если фильтрация доступна, сохраняйте обслуживание легитимных пользователей.
3. Игнорировать логи. Без top URL, IP, ASN, кодов ответа и User-Agent команда будет менять правила вслепую.
4. Полагаться только на IP. Распределенные атаки используют множество адресов, а один адрес может скрывать корпоративную сеть.
5. Не иметь плана реагирования. Контакты провайдера, доступ к метрикам и безопасные профили защиты должны быть подготовлены заранее.

Мифы о DDoS

Заключение

Современный DDoS редко выглядит как «миллион запросов с одного IP». Чаще это распределенный поток, похожий на обычных посетителей. Поэтому смотрите не на один график, а на связку сигналов: RPS и задержки, URL и коды ответа, ASN и географию, Cookie и JavaScript, поведение пользователей и состояние origin.