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

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

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

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

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

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

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

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

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

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

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

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

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

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 ГБ оперативной памяти значение nf_conntrack_max зачастую составляет 131072 записей. При потоке 50–100 тысяч пакетов в секунду таблица может заполниться за несколько секунд. После этого ядро начнет отбрасывать новые пакеты, включая подключения пользователей. В этом случае в журнале можно увидеть nf_conntrack: table full, dropping packet.

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

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 этот вид атак можно обнаружить по всплеску исходящего трафика: 

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 часто заканчивается 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 — консольный сниффер пакетов. Показывает, какие пакеты приходят на сервер, и помогает найти источники SYN flood, UDP flood или другого подозрительного трафика. 

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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