Что происходит при DDoS и как отличить атаку от нагрузки

Почти каждый, кто админит VDS/VPS, хоть раз перезагружал сервер при DDoS-атаках или при подозрительно резком росте трафика. Это не помогает, ну а что ещё делать… Для того, чтобы этого не было, в статье под катом разберу, что происходит при разных видах DDoS, как правильно их диагностировать и с помощью чего можно отличить атаку от органического роста. 

Кто атакует в 2026 году и зачем

Начну с основ. DDoS-атака — это отправка большого количества запросов на ресурс, в результате чего может произойти прекращение работы ресурса («отказ в обслуживании» или DoS). 

Источники такой атаки можно разделить на две категории: 

• Самые распространённые — это ботнеты ^[1] из заражённых IoT-устройств (даже солнечных батарей) и роутеров. Сейчас в даркнете такую атаку на несколько часов можно купить за несколько долларов, при этом технические навыки для её организации не нужны.

• Вторая по распространённости — организованные группы (конкуренты, вымогатели и хактивисты). Конкуренты атакуют перед пиковыми продажами, вымогатели сначала дудосят, а потом шлют письмо с требованием выкупа. В свою очередь, хактивисты атакуют политические сайты, СМИ, госсектор в основном по идеологическим мотивам.

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

Зачастую главная цель атаки на VDS ^[2] — это веб-сервер, SSH, почтовый сервис, DNS или API-эндпоинт. То есть во всех случаях это конкретный сервис, но бывают и многовекторные атаки. Также иногда злоумышленники меняют цель в процессе, например, сначала бьют по 80-му порту, видят защиту, переключаются на 443-й, потом на API, а потом на поддомен. Это нормально, потому что они ищут самое слабое звено.

Виды DDoS-атак и что при них происходит

По данным Cloudflare, в 2025 году в мире было зафиксировано ^[3]около 47,1 млн DDoS-атак (рост на 121% за год). Рекорд мощности единичной атаки достиг 31,4 Тбит/с — атака длилась всего около 35 секунд. Однако виды таких атак разнятся.

Объёмные атаки 

Это тот самый сценарий, который большинство представляет при слове DDoS. В этом случае на ваш IP льётся трафик, который превышает ширину канала VDS ^[2]. Обычно это UDP-флуд, ICMP-флуд или DNS amplification (DNS-усиление). В такой атаке злоумышленник шлёт пакеты с поддельным source IP, и ваш сервер либо тратит CPU на обработку, либо канал забивается настолько, что легитимные пакеты просто не доходят.

На VDS ^[2] такие атаки чаще всего фильтруются провайдером на уровне сети, потому что иначе страдают все соседи по стойке. Для понимания того, не была ли она узконаправленной, посмотрите на статистику интерфейса через:

ip -s link show eth0

Если проблема действительно на уровне сети, увидите огромный объём входящего трафика. Дополнительно могут расти счётчики dropped-пакетов. Также для быстрой оценки текущей картины удобно использовать:

iftop -i eth0

Грустная новость: проблема в этом случае вне вашей зоны ответственности, и самостоятельно отбить её невозможно. 

Атаки на протоколы

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

ss -s

И проверяем состояние conntrack (таблицы записей о потоках, которую ведёт модуль nf_conntrack):

cat /proc/sys/net/netfilter/nf_conntrack_count 

cat /proc/sys/net/netfilter/nf_conntrack_max 

Дальше разберу по подвидам. При SYN-флуде атакующий отправляет SYN-пакеты с поддельными адресами источника. Для каждого такого запроса сервер выделяет ресурсы, отвечает SYN-ACK и ждёт завершающий ACK, который так и не приходит. В результате соединение остаётся в состоянии SYN-RECV до истечения таймаута (около 60 сек.).

Такая DDoS-атака заметна даже при небольшом потоке трафика. Если сервер получает 1000 SYN-пакетов в секунду, за минуту накапливается около 60 тыс. полуоткрытых соединений. Дальше в игру вступает подсистема conntrack.

На VDS ^[2] с 2 ГБ оперативной памяти значение nf_conntrack_max зачастую составляет 131072 записей. При потоке 50–100 тысяч пакетов в секунду таблица может заполниться за несколько секунд. После этого ядро начнет отбрасывать новые пакеты, включая подключения пользователей. В этом случае в журнале можно увидеть nf_conntrack: table full, dropping packet.

При этом CPU может быть загружен меньше чем на 20 %, а процессы продолжат работать, но новые подключения уже не пройдут. Всё это из-за того, что отбрасывание происходит ещё на уровне сетевого стека. Для защиты можно (и нужно) использовать SYN cookies ^[4]. Чтобы включить их, выполните команду:

sysctl -w net.ipv4.tcp_syncookies=1

Так настройка будет работать до первой перезагрузки. Для включения SYN cookies перманентно, нужно внести в конфиг /etc/sysctl.conf или в файл /etc/sysctl.d/: 

net.ipv4.tcp_syncookies = 1

И применить настройки. Если у вас будет включён tcp_syncookies, вместо хранения состояния для каждого полуоткрытого соединения ядро будет кодировать параметры подключения непосредственно в поле sequence number пакета SYN-ACK. Когда клиент пришлёт ACK, ядро проверит куки и восстановит состояние соединения. Однако полностью проблему такая защита не решает, ведь если узким местом стал сам conntrack, записи для отслеживания соединений всё равно продолжат создаваться.

При UDP-флуде протокол UDP не использует процедуру установления соединения и не хранит состояние в привычном для TCP виде. Однако conntrack по умолчанию всё равно пытается отслеживать UDP-потоки, и каждый пакет с уникальным набором адресов и портов создаёт новую запись в таблице. Проверить это можно через:

mpstat -P ALL 1

Или:

cat /proc/softirqs

Из-за отсутствия рукопожатий заполнение conntrack в этом случае происходит быстрее, чем при TCP-флуде. Если сервер не использует NAT и stateful-фильтрацию для UDP, отслеживание таких пакетов лучше отключить через NOTRACK.

ICMP-флуд устроен ещё проще. Тут сервер получает огромное количество ICMP Echo Request и вынужден обрабатывать их на уровне ядра. В большинстве случаев подобные атаки отсекаются ещё на стороне провайдера, поэтому владельцы виртуалок сталкиваются с ними сравнительно редко.

Атаки на уровне приложений (L7-атаки) 

В этом случае происходит TCP-рукопожатие, а также есть корректный HTTP-запрос, но… с вредоносной семантикой. Такие атаки проходят через защиту транспортного уровня и падают уже на вашем сервере, поэтому сетевые метрики тут уже не помогут, нужно открывать логи приложения и веб-сервера. Первое, что стоит проверить:

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

И:

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

Если нужно быстро понять, какие URL получают больше всего запросов, поможет:

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

А для анализа трафика в реальном времени удобно использовать:

goaccess /var/log/nginx/access.log

Самый распространённый вариант L7-атаки — HTTP-флуд. В этом случае бот отправляет вполне валидные GET- или POST-запросы на ресурсоёмкие эндпоинты. Каждый такой запрос занимает процессорное время, обращается к базе данных и может создавать дополнительную нагрузку на диск. 

Другой популярный сценарий — Slowloris. Тут атакующий открывает множество соединений и начинает отправлять HTTP-заголовки чрезвычайно медленно, иногда буквально по одному байту каждые несколько секунд. nginx продолжает ждать завершения заголовков и удерживает соединение открытым. 

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

ss -tan | grep ESTAB | wc -l

А более подробную картину покажет:

ss -tnp

При Slowloris обычно видно большое количество соединений в состоянии ESTABLISHED, которые существуют долгое время, но практически не передают данные.

Похожим образом работает атака RUDY (R-U-Dead-Yet). Однако в этом случае бот отправляет не заголовки, а тело POST-запроса. Сначала сервер получает огромный Content-Length и готовится принять большой объём данных, после чего злоумышленник начинает передавать тело запроса крайне медленно. В результате веб-сервер или приложение продолжают ждать оставшиеся данные и удерживают ресурсы занятыми.

Есть и обратная техника под названием Slow Read. Здесь запрос отправляется быстро и без ошибок, но клиент начинает чрезвычайно медленно читать ответ сервера. Из-за этого соединение остаётся открытым, а сервер продолжает хранить данные в буферах и обслуживать клиента, который фактически ничего не делает.

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

Amplification и reflection

В этом случае ваш сервер становится промежуточным звеном в атаке на кого-то другого. Атакующий шлёт запрос с поддельным source IP на открытый DNS/NTP/SSDP, и тот отвечает жертве. На VDS ^[2] этот вид атак можно обнаружить по всплеску исходящего трафика: 

iftop -i eth0

После проверьте, какой процесс генерирует трафик:

nethogs

Полезно также оценить статистику интерфейса:

ip -s link show eth0

И накопленные объёмы передачи данных:

vnstat -i eth0

Лечится такая атака закрытием порта на файрволе или отключением сервиса. 

Сканеры 

Отдельно упомяну сканеры. Массовое сканирование портов и веб-приложений также принимают за DDoS-атаку, особенно если сервер новый или админ впервые смотрит логи. У таких ботов нет цели «положить» ваш сервис, они ищут открытые сервисы, панели управления и разные уязвимости.

В этом случае в логах вы увидите большое количество коротких соединений или запросов к типовым URL вроде /wp-admin, /phpmyadmin и /.env. Нагрузка и потребление ресурсов при этом будут низкие. 

Как отличить атаку от нагрузки

Начинайте с TCP-состояний (команда ss -s). При нормальной нагрузке соотношение ESTAB к другим состояниям будет 10:1 и выше. При SYN-флуде SYN-RECV взлетает до тысяч. При Slowloris и других L7-атаках будет высокий ESTAB, но не будет пользовательского трафика. Дальше смотрите conntrack (команда выше). 

В нормальной ситуации текущее количество записей редко превышает несколько процентов от лимита. При SYN-флуде это соотношение стремится к 100%. Также помните, что каждая запись занимает примерно 300–400 байт памяти, поэтому бесконтрольное увеличение nf_conntrack_max на небольших VPS ^[2] часто заканчивается OOM Killer. 

Дальше смотрим на интерфейсные счётчики:

ip -s link show eth0 

При пакетном флуде увидите рост RX dropped. При обычной нагрузке объёмы входящего и исходящего трафика будут симметричны. 

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

journalctl -k

Или:

dmesg

Там можно встретить подсказки вроде «nf_conntrack: table full, dropping packet» или «possible SYN flooding on port».

Если же система начала испытывать нехватку памяти, в журнале появятся сообщения OOM Killer с указанием завершённого процесса и объёма занятой памяти. 

Хорошо помогает и анализ загрузки CPU по типам времени: 

mpstat -P ALL 1

При сетевом флуде растёт системное время sy (пользовательское us остаётся низким). Всё из-за того, что процессор занят обработкой пакетов и softirq. Во время L7-атак пользовательское время растёт вместе с нагрузкой на nginx, PHP, Python или другое приложение.

Много информации даёт и распределение соединений по IP-адресам.

ss -tan | awk 'NR>1 {split($5,a,":"); print a[1]}' | sort | uniq -c | sort -nr | head

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

Окончательно разобраться помогают HTTP-метрики и access-логи:

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

Если один и тот же URL внезапно начинает получать тысячи запросов с одинаковым User-Agent, это 100% бот. Также на это указывает всплеск ошибок 400 Bad Request или большое количество ответов с кодом 499.

И помните, органический трафик отличителен пользовательским поведением. Боты примитивны, поэтому бесконечно обращаются к одному URL, игнорируют статические ресурсы или перебирают страницы по шаблону.

Также для оценки можно использовать утилиты: 

• tcpdump ^[5] — консольный сниффер пакетов. Показывает, какие пакеты приходят на сервер, и помогает найти источники SYN flood, UDP flood или другого подозрительного трафика. 

• Wireshark ^[6]— графический анализатор pcap-файлов. Полезен, когда нужно детально разобрать трафик после инцидента и посмотреть содержимое пакетов вплоть до прикладного уровня.

• iftop ^[7] — показывает самые активные соединения в реальном времени. Особенно удобен в ситуациях, когда нужно быстро понять, кто сейчас забивает канал.

• nload ^[8]— отображает текущие объёмы входящего и исходящего трафика и позволяет за несколько секунд понять, есть ли аномальный всплеск нагрузки. 

• nethogs ^[9] — группирует сетевую активность по процессам.

• mtr ^[10] — гибрид ping и traceroute. Полезен, когда нужно понять, проблема находится на сервере или где-то по пути до него.

• vnStat ^[11]— демон учёта трафика по интерфейсам с накоплением. Покажет, когда начался аномальный рост.

• Suricata ^[12]— работает как IDS/IPS-система и умеет находить известные паттерны атак по сигнатурам.

• CrowdSec ^[13] — анализирует логи сервисов, выявляет подозрительную активность и автоматически блокирует источники атак. 

• bcc-tools ^[14] — предоставляет набор утилит на базе eBPF для глубокой диагностики ядра.

И как обычно рекомендую Netdata ^[15]. После её установки сервер получает веб-интерфейс с графиками conntrack, TCP-состояний, сетевых ошибок, загрузки CPU и десятков других метрик. Наконец, никуда не делись iptables и nftables. 

Важно!

DDoS начинается с роста conntrack_count, поэтому смотрите метрики до того, как таблица заполнится. Чем раньше вы заметите атаку, тем меньше времени потеряете на перезагрузки и догадки.

Делитесь в комментариях, как понимали, что вас дудосят, и что делали потом. 

© 2026 ООО «МТ ФИНАНС»