Ваш сайт тормозит или лежит? Как понять, что это DDoS-атака, и что делать

Вы просыпаетесь утром, открываете свой сайт, а он еле ворочается. Или вообще не открывается. Первая мысль: "Хостинг лёг, опять эти сбои..." Вторая: "Может кто-то добавил ссылку на сайт на Хабр? У нас просто наплыв посетителей". А третья, самая неприятная: "Кажется, нас атакуют". Как понять, что действительно происходит? Как отличить DDoS-атаку от обычного всплеска популярности или технического сбоя? Я сам через это проходил, и знаю, как трудно сохранять хладнокровие, когда сайт падает в самый неподходящий момент.

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

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

Самый ранний признак - это жалобы. Зазвонил телефон, в мессенджере написал постоянный клиент: "Ваш сайт не грузится", "Магазин открывается полминуты, я ушёл к конкуренту", "Вылетает ошибка 503". За первыми тремя звонками обычно стоят десятки или сотни молчаливых ушедших клиентов. Не игнорируйте этот сигнал. В отличие от планового технического обслуживания, DDoS-атака обычно накрывает внезапно - без предупреждения и в нерабочее время. Если сайт "лёг" в три часа ночи, вряд ли это из-за того, что сисадмин решил перезагрузить сервер.

Следующее, что вы заметите, - это аномалии в скорости. Страницы открываются не просто медленно, а с дикими задержками, падают отдельные запросы, изображения грузятся частями. Характерный симптом: TTFB (Time To First Byte - время до первого байта) растёт до нескольких секунд, хотя обычно он составлял 100-200 мс. Это верный признак, что сервер задыхается: очередь запросов переполнена, а ресурсы уходят на обработку мусора. Если при этом страницы частично отображаются, но зависают на "загрузке стилей" или "ожидании ответа от сервера" - стоит насторожиться.

И, наконец, обратите внимание на поведение вашей CRM или системы аналитики в реальном времени. Если в Яндекс.Метрике вы видите, что прямо сейчас на сайте 500 человек, а ваш движок еле дышит - это может быть как легитимный пик, так и ботнет. Ключевое отличие: при реальном наплыве людей обычно растёт и конверсия, и количество целевых действий. При DDoS-атаке - посетители есть, но они не совершают покупок, не заполняют формы, а их визиты длятся по 1-2 секунды (высокий процент отказов).

Ещё один ранний признак - появление ошибок 502 Bad Gateway или 504 Gateway Timeout, если ваш сайт использует reverse proxy (например, Nginx перед Apache). Такие ошибки возникают, когда вышестоящий сервер не успевает ответить из-за перегрузки. Это не всегда DDoS, но при отсутствии иных изменений в конфигурации - повод бить тревогу.

Если у вас настроены алерты через UptimeRobot или аналогов - вы получите уведомление о недоступности раньше, чем клиенты начнут звонить. Настройте проверку каждые 5 минут с нескольких точек мира, чтобы отличать локальные проблемы от глобальных.

Технические индикаторы: смотрим на сервер, логи и сеть

Когда вы уже заподозрили неладное, пора переходить от ощущений к фактам. Первым делом - зайдите в панель управления хостингом или на свой сервер (если у вас VPS/dedicated). Большинство современных панелей (ISPmanager, cPanel, HestiaCP) показывают графики нагрузки CPU, оперативной памяти и сетевого трафика. Если вы видите, что процессор на 100% утилизирован уже несколько часов, а раньше был на 20%, - это сильный аргумент в пользу атаки. Особенно если одновременно с этим сетевой трафик вырос в 5-10 раз.

Теперь переходим к логам. Самый ценный источник информации - логи доступа веб-сервера (access.log) для Apache/Nginx. Зайдите на сервер по SSH и выполните команду, которая покажет топ IP-адресов за последние 10 минут:

Что вы увидите? Если один и тот же IP (или небольшая группа IP) делает тысячи запросов в минуту, - классическая DoS-атака с одного источника. Но при настоящем DDoS вы увидите десятки и сотни разных IP, каждый из которых генерирует умеренное количество запросов, но в сумме даёт огромную нагрузку. Обратите внимание на User-Agent. Если в логах мелькают строки вроде "python-requests/2.25.1", "curl/7.68.0", "Mozilla/5.0 (compatible; AhrefsBot/7.0; ...)" - это могут быть как легитимные парсеры (например, Ahrefs), так и боты. Отличаются они частотой: поисковые роботы соблюдают паузы, а боты долбят без остановки.

Ещё один яркий симптом - статусы ответов. Нормальный сайт отдаёт в основном 200 (OK), 301/302 (редиректы), 404 (не найдено) в небольших количествах. При DDoS-атаке вы увидите вал 499 (Client Closed Request) в Nginx - это когда сервер уже отправил ответ, но клиент (бот) закрыл соединение, или 503 (Service Unavailable) - когда сервер перегружен и отказывается обрабатывать запросы. Если атака нацелена на уязвимость, могут появиться странные статусы вроде 400 Bad Request или 405 Method Not Allowed.

Не забывайте про системные логи: syslog, kernel.log, mysql.log. Там могут быть записи о том, что количество соединений к базе данных превысило лимит, или о нехватке памяти. Например, атака на WordPress через xmlrpc.php создаёт тысячи одновременных подключений к БД, и вы увидите ошибки "Too many connections" в логах MySQL. В системном логе может появиться запись "kernel: possible SYN flooding on port 80. Sending cookies." - это прямое указание на SYN-флуд.

Также полезно смотреть сетевую статистику через netstat. Команда

покажет распределение состояний TCP-соединений. В норме большинство соединений должны быть в состоянии ESTABLISHED (установлены) или TIME_WAIT. Если вы видите тысячи соединений в состоянии SYN_RECV (полуоткрытых) - это SYN-флуд. Если много соединений в CLOSE_WAIT - возможно, медленная атака.

Специализированные инструменты: как увидеть атаку невооружённым глазом

Ручной анализ логов - это хорошо, но когда атака уже идёт, каждая секунда на вес золота. Используйте готовые утилиты. На сервере под Linux запустите iftop - он покажет, какие IP и куда отдают больше всего трафика. Если вы видите, что десятки адресов из Вьетнама, Бразилии или Индии качают с вашего сервера терабайты данных, хотя ваш сайт - локальная пекарня, - сомнений нет.

Утилита nethogs покажет нагрузку по процессам. Если вы увидите, что процесс Apache или PHP-FPM пожирает 100% CPU, а других процессов почти нет - атака идёт на уровне приложений (L7). tcpdump - для продвинутых: можно захватить несколько пакетов и посмотреть их структуру. Например, вы увидите тысячи TCP-пакетов с флагом SYN, но без последующего ACK - это SYN-флуд. Или увидите огромное количество UDP-пакетов разного размера - возможно, UDP-флуд.

Пример захвата tcpdump на 5 секунд с фильтром по порту 80:

Если вы видите только SYN-пакеты, идущие с разных IP, - это SYN-флуд. Если видите HTTP GET запросы, повторяющиеся с разными IP, - HTTP-флуд. Если видите ICMP echo requests - атака "пинг смерти".

Многие хостинг-провайдеры предоставляют графики в панели. Ищите графики входящего трафика (incoming traffic) и пакетов в секунду (packets per second, PPS). Если входящий трафик резко взлетел, а исходящий остался на месте - скорее всего, это атака на сетевое оборудование. Если взлетел и исходящий - возможно, ваш сервер стал участником амплификационной атаки (используют ваши ресурсы для атаки на других).

Для пользователей облачных сервисов (AWS, DigitalOcean, Vultr) есть встроенный мониторинг сетевых интерфейсов. Там же можно настроить алерты: например, если входящий трафик превысил 100 Мбит/с на 5 минут - слать уведомление в Telegram. Это помогает не проспать начало атаки.

Полезным инструментом является goaccess - анализатор логов в реальном времени. Он показывает статистику по запросам, кодам ответа, посещаемым страницам. Запустив goaccess на access.log, вы сразу увидите, какие URL атакуют чаще всего, с каких IP приходит основная нагрузка.

Как отличить DDoS от других проблем: типичные ловушки

Ошибка многих новичков: "сайт не открывается - значит, DDoS". Но на самом деле причин масса. Самая распространённая - проблемы с DNS. Попробуйте пропинговать IP сервера. Если пинг проходит, а сайт не открывается - возможно, проблема в самом сервере или приложении. Если пинг не проходит - может быть, провайдер режет трафик или сервер выключился. Используйте онлайн-сервисы для проверки доступности из разных точек, например - ping-admin.com.

Вторая ловушка - неправильные настройки кэша. Если у вас включён агрессивный кэш страниц, но он не инвалидируется после обновлений, посетители могут видеть старые версии. Но это не замедляет работу. А вот если кэш отключён, а база данных не оптимизирована, то даже 100 одновременных пользователей положат сайт. Это не атака, а плохая архитектура. Но симптомы похожи: долгое время ответа, высокий CPU, ошибки таймаутов.

Третья ловушка - проблемы с хостингом. На shared-хостинге сосед по серверу может запустить тяжёлый скрипт, и ваш сайт будет тормозить. Или хостинг сам ограничивает количество запросов. Как отличить? Если проблема только у вас, а все остальные сайты на том же сервере работают - скорее всего, атака именно на ваш ресурс. Если падают все - возможно, проблемы на стороне хостинга. Но бывает и атака на весь IP-диапазон хостинг-провайдера - тогда упадут все.

Четвёртая, самая частая для CMS - брутфорс административной панели. При этом нагрузка на сервер не всегда огромная, но вы видите в логах тысячи запросов к wp-login.php или /administrator/index.php с разными логинами и паролями. Это тоже DDoS? Формально - нет, но результат тот же: сайт может стать недоступным из-за того, что пул PHP-воркеров занят проверкой паролей. Отличить можно по типу запросов: в брутфорсе обычно POST с параметрами log и pwd, а в DDoS - GET или POST с большим объемом мусора.

Как окончательно убедиться? Попробуйте зайти на сайт через анонимайзер или прокси из другой страны. Если с другой точки доступ есть, а из вашей сети нет - возможно, атака идёт на уровне вашего провайдера (например, на канал). Если нет ниоткуда - с большой вероятностью атака на уровне приложения или сервера.

Ещё один тест - попробуйте выполнить запрос к статическому файлу (например, robots.txt или favicon.ico). Если статика грузится быстро, а динамическая страница нет - атака идёт на бэкенд (PHP, база данных). Если и статика грузится медленно - атака на сетевом уровне или перегружен канал.

Инструменты внешнего мониторинга: не держите всё в себе

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

Более продвинутые платформы типа Cloudflare, DDoS-Guard, StormWall в своих панелях показывают не только статус, но и графики отражённых атак. Вы увидите, сколько запросов заблокировано, какие типы атак преобладают, какие страны-источники. При включённой защите вы можете даже не заметить атаку, но отчёты покажут её масштабы.

Для тех, кто хочет копнуть глубже, подойдёт ELK-стек (Elasticsearch, Logstash, Kibana). Вы загружаете логи веб-сервера в Elasticsearch, и Kibana строит красивые дашборды. Можно настроить аномалии: например, если частота ошибок 5xx превысила 5% от общего числа запросов, отправлять алерт. Это уже уровень профессионального обнаружения, не для новичков, но как цель - очень достойная.

Хорошей альтернативой ELK является Grafana + Loki - более лёгкий и быстрый стек для сбора и визуализации логов. С его помощью можно настроить оповещения на аномалии в реальном времени.

Если вы используете облачные серверы, не пренебрегайте встроенными инструментами мониторинга. Например, DigitalOcean предоставляет графики CPU, диска и сети. AWS CloudWatch позволяет настроить алерты на превышение порогов. Google Cloud Monitoring умеет коррелировать метрики и даже предлагать возможные причины сбоев.

Важно иметь резервный канал связи: если ваш основной провайдер падает, вы должны получать уведомления через резервный (например, через SIM-карту в 3G-модеме). Иначе вы можете и не узнать об атаке, пока не придут первые жалобы от клиентов.

Реальные примеры: как выглядит атака в логах

Давайте разберём конкретные строчки из реального access.log, чтобы вы знали врага в лицо.

Пример 1: SYN-флуд (в логах может не отображаться, т.к. это атака до уровня приложения, но вы увидите в netstat):

Если это число тысячи, а соединения в состоянии ESTABLISHED мало, - SYN-флуд.

Пример 2: HTTP-флуд на главную страницу:

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

Пример 3: Атака на xmlrpc.php (WordPress):

Тысячи POST-запросов к этому файлу. В логах также могут быть записи о том, что сервер отвечает 200 OK, но нагрузка на CPU бешеная.

Пример 4: Медленная атака Slowloris: В логах access почти нет записей, потому что соединения висят в состоянии "запрос не завершён". Зато в netstat вы увидите много соединений в состоянии ESTABLISHED с маленьким объёмом переданных данных. Это коварный тип, его сложно обнаружить без поведенческого анализа.

Пример 5: Амплификационная атака (DNS amplification): Вы не увидите её в access.log, потому что она идёт на DNS-сервер, а не на веб-сервер. Зато вы увидите в iftop или nload, что входящий трафик на порту 53 (DNS) достигает сотен мегабит. Это означает, что ваш сервер используется как отражатель. Проверить можно, посмотрев на исходящий трафик: он будет несоизмеримо мал.

Что делать после обнаружения: краткий алгоритм действий

Обнаружили атаку? Не паникуйте. Следуйте плану. Он не панацея, но даст вам время на принятие решений.

• Ограничьте ресурсы: Временно выключите тяжёлые функции на сайте (поиск, комментарии, фильтры). Можно переключить сайт в режим "только чтение" или отдавать кэшированную версию. Если у вас есть возможность, измените настройки PHP: уменьшите максимальное время выполнения скриптов (max_execution_time) и количество одновременно выполняемых процессов (max_children).
• Используйте rate limiting: Если ваш хостинг позволяет, настройте ограничение количества запросов с одного IP. Например, 10 запросов в минуту. Это не остановит DDoS, но снизит нагрузку. В Nginx это делается через директивы limit_req_zone и limit_req. В Apache - через mod_evasive.
• Добавьте правила для блокировки подозрительных IP прямо в .htaccess или конфиг веб-сервера: Если вы выявили IP-диапазоны, откуда идёт основная атака, временно заблокируйте их. В Nginx можно использовать deny, в .htaccess - Deny from. Это поможет, только если атакующих немного.
• Подключите облачную защиту: Если у вас нет активного анти-DDoS-сервиса, сейчас самое время. Например, Cloudflare (бесплатный тариф), StormWall (есть пробный период) или DDoS-Guard. Измените DNS, чтобы трафик пошёл через них. Даже базовая защита отфильтрует значительную часть ботнетов.
• Сообщите хостинг-провайдеру: На shared-хостинге они тоже увидят атаку и могут помочь фильтровать трафик на своём уровне. Некоторые провайдеры предлагают услугу "защита от DDoS" как опцию, которую можно включить в любой момент.
• Пишите чёрные списки: Выберите самые активные IP-адреса из логов (top 10 по числу запросов) и временно заблокируйте их через файрвол. Это даст небольшую передышку. Если атака с ботнета, то этих IP будет много, но заблокировав самые активные, вы снизите нагрузку.
• Не забывайте про базу данных: При HTTP-флуде часто страдает именно БД. Попробуйте временно перевести сайт в режим "только для чтения" или отключить необязательные модули (комментарии, поиск). Проверьте, не заполнены ли временные таблицы.

После того как атака закончится (а она закончится, потому что атакующий платит за трафик), проведите разбор полётов: проанализируйте логи, найдите уязвимости, усильте защиту.

Заключение: бдительность - основа безопасности

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

Главное, что нужно вынести из этой статьи: не ждите, пока сайт полностью упадёт. Следите за метриками, анализируйте логи хотя бы раз в день, особенно перед важными событиями. Используйте внешние системы мониторинга. И обязательно имейте план действий на случай атаки. Тогда DDoS-атака не застанет вас врасплох, и вы сможете не только обнаружить её, но и минимизировать последствия.