DDoS на VPN-сервисе: что держит атаку, а что нет

Ваш сервер лежит, клиенты пишут «не подключается», а нагрузка на процессор нулевая. Это не парадокс. При атаке чаще заканчивается не мощность железа, а очередь в ядре, полоса канала или терпение хостера.

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

Сначала цифры, чтобы понимать масштаб

За 2025 год Cloudflare заблокировала 47,1 млн атак, это рост на 121% к 2024 году. Рекорд года: 31,4 Тбит/с, длительность 35 секунд. Средняя мощность атак по данным StormWall выросла с 71 до 116 Гбит/с за год, а число атак по России увеличилось в 1,8 раза.

Теперь сравните с вашим сервером. Обычный VPS имеет порт 1 Гбит/с, у младших тарифов 100 или 500 Мбит/с. Отсюда первый вывод, который меняет всё остальное:

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

Хорошая новость в том, что терабитные атаки прилетают не в вас. По данным Cloudflare за первый квартал 2025 года, 89% атак на сетевом уровне заканчиваются быстрее десяти минут, а самый частый вектор это банальный SYN-флуд. Против него работают бесплатные средства.

Угроза, которой нет в графиках хостера: флуд по вашей же ссылке

Объёмный флуд бьёт вслепую по IP. Но у VPN-сервиса есть цель, которой нет у обычного сайта: ваша же подписочная ссылка. В ней открытым текстом лежат адрес ноды, порт, протокол, Reality-параметры и путь. Этого достаточно, чтобы бить не по IP наугад, а прицельно в рабочий инбаунд.

Инструмент для этого существует и лежит в открытом доступе: deathcore (Go, поверх ядра Xray). Он берёт на вход целую VLESS-ссылку, сам вытаскивает все параметры и поднимает тысячи одновременных соединений — каждое живёт постоянно, режимы flood, http и grpc, полная поддержка Reality и XHTTP. В описании прямо сказано: «keeps pressure 24/7». Формально это «стресс-тест своих серверов», по факту — готовый флудер по VLESS-инфраструктуре.

Почему это опаснее слепого флуда: соединения валидные по форме, они доходят до Xray и заставляют его работать, а не отсекаются на границе как мусорные SYN. Поэтому:

• Прячьте реальный адрес ноды. Селфстил и CDN-фронт нужны не только против блокировок: за фронтом атакующий видит адрес фронта, а не ноды, и бьёт не по вам. Это разобрано в разделе про CDN-фронтинг и селфстил.
• Ротация подписки. Утекла ссылка — перевыпуск отвязывает старый адрес. Отсюда же польза короткого времени жизни DNS-записей и выдачи конфигов через подписку, а не файлом.
• Лимит соединений на входе, но с оглядкой на NAT (см. Уровень 2): за одним адресом оператора сидят десятки клиентов, поэтому режем общий поток, а не per-IP на самом туннеле.
• SYNPROXY и пороги ядра (Уровни 1-2) снимают часть нагрузки, но полностью такой флуд не закрывают: соединения проходят рукопожатие.

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

Уровень 0. Понять, что это атака

Половина «атак» оказывается наплывом клиентов после рекламы или зациклившимся клиентским приложением. Отличать надо по признакам, а не по ощущениям.

ss -s                      # сводка: сколько соединений и в каких состояниях
ss -tn state syn-recv | wc -l   # полуоткрытые: при SYN-флуде их сотни и тысячи
conntrack -C               # сколько записей в таблице соединений
vnstat -tr 10              # реальная полоса за 10 секунд

Атака: соединений много, полезного трафика мало, сотни записей в состоянии SYN_RECV, адреса разрозненные, нагрузка на процессор низкая.

Наплыв клиентов: соединения и трафик растут пропорционально, адреса повторяются, процессор загружен.

Наш собственный случай 5 августа 2026 года: SSH-флуд на порт 22, от 226 до 439 соединений в SYN_RECV при стандартной длине очереди 128, sshd перестал отвечать. При этом нагрузка сервера была 0,12. Более мощное железо не помогло бы, упёрлись в лимит очереди ядра.

Уровень 1. Настройки ядра, 15 минут и бесплатно

Первое, что стоит сделать на любом сервере.

# /etc/sysctl.d/99-antiddos.conf
net.ipv4.tcp_syncookies = 1          # при переполнении очереди состояние
                                     # кодируется в ответе, а не хранится в памяти
net.ipv4.tcp_max_syn_backlog = 8192  # длина очереди полуоткрытых, дефолт 128
net.core.somaxconn = 8192            # очередь принятых соединений
net.ipv4.tcp_synack_retries = 2      # быстрее отпускать зависшие, дефолт 5
net.netfilter.nf_conntrack_max = 262144

Что даёт: сервер переживает SYN-флуд средней силы и не отваливается по таймауту. Чего не даёт: ничего против забитого канала и против UDP-флуда.

Уровень 2. Фильтр в ядре: nftables и SYNPROXY

Дальше режем поток до того, как он дойдёт до приложения.

SYNPROXY подтверждает рукопожатие сам и создаёт запись о соединении только для тех, кто ответил. Флуд из подделанных адресов до сервиса не доходит вообще.

# лимит новых соединений с одного адреса
nft add rule inet filter input tcp flags syn \
  meter syn-per-ip { ip saddr limit rate 30/second burst 60 packets } accept

⛔Важно для VPN. На порт самого туннеля жёсткий лимит с одного адреса ставить нельзя: за одним адресом оператора сидят десятки ваших клиентов через NAT, и вы отрежете их вместе с атакой. У нас поэтому два профиля: для сайта режем 30 SYN в секунду с адреса, для ноды per-IP не режем вовсе, только общий поток 8000 в секунду, и отдельно жёстко ограничиваем SSH шестью подключениями в минуту.

Что даёт: держит типовой SYN-флуд без нагрузки на процессор. Чего не даёт: не работает для WireGuard и других UDP-протоколов, там нет рукопожатия, которое можно проверить.

Уровень 3. Приложение: панель, подписка, вход

Панель управления и страница подписки это отдельные цели, и по ним чаще прилетает не объёмная атака, а перебор.

nginx, встроенные лимиты. У нас на боевом стоят: вход 10 запросов в минуту, регистрация и коды 30 в минуту, внутренний API 20 в минуту, всем превысившим отдаётся 429.

limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;
location /login { limit_req zone=login burst=5 nodelay; }

fail2ban (18,4 тыс. звёзд, живой) читает логи и банит по факту. У нас три правила: SSH, сканеры по логу nginx, перебор входа. Сейчас в бане 141 адрес.

CrowdSec (14,5 тыс. звёзд, живой) это тот же принцип, но с общим списком угроз от всех участников сети. Движок и базовый список бесплатны, платные только расширенные подписки. Ставится рядом с nginx через готовый компонент cs-nginx-bouncer.

Что даёт: закрывает перебор паролей, сканеры, наплыв на форму входа. Чего не даёт: реагирует постфактум, по логам. При валовом флуде не успевает.

Уровень 4. Видеть атаку

Без этого предыдущие уровни настраиваются вслепую.

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

FastNetMon Community (3,7 тыс. звёзд): детектор объёмных атак, умеет автоматически отправлять адрес в blackhole по BGP. Бесплатная версия без веб-интерфейса, настройка через файл. Платная от 115 долларов в месяц. Осмысленно от десятка серверов.

Уровень 5. Провайдер и хостер, единственное, что держит объём

Здесь начинается защита, которая работает против того, что не влезает в ваш канал.

Ключевой вывод по Cloudflare, потому что на нём спотыкаются чаще всего: спрятать за бесплатным Cloudflare сайт и панель можно и нужно, спрятать сам VPN-туннель нельзя.

Что делать, когда атака уже идёт

Порядок именно такой, по убыванию скорости эффекта.

1. Убедиться, что это атака. Команды из уровня 0, тридцать секунд.
2. Проверить, упёрлись ли в полосу. Если канал забит под завязку, все действия на сервере бесполезны, сразу к пункту 5.
3. Поднять пороги ядра и включить лимиты, если их ещё нет. У нас для этого готовый скрипт с двумя профилями.
4. Закрыть лишнее. Панель и SSH переводятся на доступ только со своих адресов, посторонние протоколы отбиваются.
5. Позвать хостера. В тикете сразу: точное время начала, порт и протокол, объём в мегабитах и пакетах в секунду, адрес жертвы. Конкретика ускоряет ответ в разы.
6. Переезд на другой адрес это крайняя мера. Сработает, только если у вас заранее готов механизм смены адреса у клиентов: короткое время жизни записей DNS или обновление конфигов через подписку.

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

Абуз подписки: шеринг, торренты, перепродажа

Это не атака извне, а свои же клиенты, которые бьют по экономике сервиса. Один купил, раздал ссылку десяти знакомым. Кто-то повесил на подписку торрент-качалку и выжирает канал ноды. Кто-то перепродаёт ваш доступ дешевле. Отдельного «удара» тут нет, но нода деградирует, а прибыль утекает.

Лимит устройств по HWID (Remnawave). Панель ограничивает число устройств на подписку по заголовку x-hwid, который шлёт клиент. Больше лимита — устройство не регистрируется, ссылку не размножить бесконтрольно. Лимит задаётся полем hwidDeviceLimit в настройках, можно персонально на юзера, иначе берётся общий.

⚠️ Две честные оговорки. Во-первых, HWID шлёт клиентское приложение, а не сервер: клиент без поддержки HWID лимит не увидит, а hwidDeviceLimit: null вообще ломает выдачу («App not supported»). Во-вторых, в ранних версиях бэкенда была гонка (advisory GHSA-985p-44h5-v3pq), позволявшая проскочить лимит одновременными запросами — лечится обновлением панели. Это не пуленепробиваемый замок, а планка, которая отсекает бытовой шеринг.

Торренты. Два уровня, лучше вместе.

Первый — средствами самого Xray: включить сниффинг на инбаунде и завернуть протокол bittorrent в блок.

"sniffing": { "enabled": true, "destOverride": ["http", "tls", "quic"] }

{ "type": "field", "protocol": ["bittorrent"], "outboundTag": "block" }

Ограничение честное: шифрованные торрент-клиенты гонят трафик под видом TLS, и такой поток сниффер не всегда распознаёт. Поэтому второй уровень — xray-torrent-blocker (kutovoys, Go, 327 звёзд, живой): читает логи Xray, ловит записи с тегом торрента, банит IP нарушителя через iptables или nftables и рвёт соединения через conntrack для мгновенного эффекта. Бан временный (по умолчанию 10 минут, настраивается), есть вебхуки для оповещения в Telegram. Поддерживает Remnawave и Marzban из коробки, нужно указать путь к логам и подстроить regex имени.

Перегруз соединениями от одного клиента режется на уровне ядра, но аккуратно — помним про NAT оператора (Уровень 2). Жёсткий per-IP лимит ставим на панель и SSH, на сам туннель — только общий потолок потока.

Антивирус на ноде: зачем и как не убить сервер

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

Установка (Ubuntu/Debian).

apt install clamav clamav-daemon clamav-freshclam -y
# freshclam обновляет базы сигнатур в фоне (демоном), проверьте что он активен:
systemctl enable --now clamav-freshclam

⚠️ Главное про ресурсы, иначе положите ноду. Демон clamd держит всю базу сигнатур в оперативной памяти — это около 1 ГБ постоянно, вне зависимости от того, сканирует он сейчас или нет. На ноде с 1-2 ГБ RAM запускать clamd демоном нельзя, он съест память под Xray. Там оставляют только разовый скан по расписанию (clamscan, базу читает с диска, медленнее, но без резидентной памяти). Резидентный демон и постоянное сканирование — для панели и машин от 4 ГБ.

Скан по расписанию, чтобы не мешать работе.

# /etc/cron.d/clamav-scan — ночью, с низшим приоритетом CPU и диска
30 4 * * *  root  ionice -c3 nice -n19 clamscan -ri /var /home /tmp \
  --exclude-dir='^/var/lib/clamav' --log=/var/log/clamav/scan.log

On-access, если ресурсы позволяют. На панели можно ловить заражение в момент записи файла: демон clamonacc через fanotify следит за каталогами и просит clamd проверить всё, что появляется. Задаётся каталог наблюдения и путь карантина, исключения снижают накладные расходы. Это уже нагрузка, включайте осознанно.

Чего ClamAV не делает. Он ловит известные сигнатуры, а не 0-day и не целевой взлом под вас. Ложные срабатывания на своих же скриптах бывают. Это дополнительный слой поверх харднинга и закрытых портов, не замена им. Антивирус, нашедший веб-шелл, означает, что вас уже пробили: разбирайтесь, как зашли.

Меньше видно — реже бьют: спрятать порты и домен

Половина мусорного трафика — это боты, которые сканируют весь интернет по портам. Что не отвечает, то и не попадает в их списки целей. Два приёма из практики (спасибо за наводку в сообществе).

Port knocking для SSH. Порт SSH закрыт для всех и невидим сканеру, пока клиент не подаст «условный стук». Два варианта, разница принципиальная:

• knockd — стук это последовательность обращений на заранее оговорённые порты. Просто, но последовательность видна в трафике, её можно перехватить и повторить: это заслон от ботов, не от целевого атакующего.
• fwknop (SPA, single packet authorization) — стук это один зашифрованный пакет с HMAC, неповторяемый и подписанный. Для nmap порт не существует вовсе, даже с 0-day по SSH бить некуда, потому что порта не видно. Это уже настоящая защита периметра.

⛔ Риск, о котором молчат гайды. Демон стука упал или не поднялся после ребута — вы заперты снаружи собственного сервера. Обязателен резервный вход: доступ с доверенного адреса, консоль хостера или KVM. И помните, что легитимные мониторинг и бэкап-скрипты «стучать» не умеют, для них нужен отдельный путь. Port knocking — это сокрытие, а не аутентификация: он снимает фоновый шум сканеров, но не отменяет ключи SSH и fail2ban.

DNS-01 вместо открытого порта под сертификат. Обычный выпуск Let's Encrypt (HTTP-01, TLS-ALPN-01) требует, чтобы наружу смотрел открытый 80 или 443 — сканер по нему находит домен и сервис. Проверка DNS-01 подтверждает владение доменом через запись в DNS, порт наружу открывать не нужно. Плюсом — можно выпустить wildcard на весь домен.

В Caddy это делается родным конфигом, но нужен билд с DNS-плагином вашего провайдера:

xcaddy build --with github.com/caddy-dns/cloudflare

example.com {
    tls {
        dns cloudflare {env.CF_API_TOKEN}
    }
    reverse_proxy localhost:8080
}

⚠️ Риск. На сервере лежит API-токен вашего DNS-провайдера. Дайте ему права только на нужную зону, не на весь аккаунт: если сервер скомпрометируют, украдут ограниченный токен, а не управление всеми доменами. Протух токен — перевыпуск сертификата встанет, следите за сроком.

Автобан сканеров: считать соединения, а не читать логи

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

Ключевой выбор здесь — по чему детектировать. Разбор логов Xray выглядит соблазнительно, но формат разный у Xray, sing-box и 3x-ui, меняется от версии к версии, и защита ломается ровно тогда, когда вы обновили ядро. Счётчики соединений в ядре одинаковы всегда. Поэтому надёжнее считать их, а логи не трогать вовсе.

Логика простая: адрес открыл больше N новых соединений за минуту — в бан на час.

новое соединение на 443
        │
        ├─ established/related ────────────────► пропустить
        ├─ адрес в белом списке ───────────────► пропустить
        ├─ адрес в бане ───────────────────────► drop
        └─ больше 60 новых за минуту ──────────► в бан на час, drop

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

Три правила, без которых автобан опаснее сканеров

Белый список проверяется первым. Не после бана, а первым правилом цепочки. И в нём обязан быть CGNAT 100.64.0.0/10 — за ним сидят мобильные операторы. Один забаненный адрес там отрезает не одного человека, а всех, кто в этот момент вышел через тот же узел оператора.

Бан только по одному адресу. Никаких подсетей: один сканер в /16 провайдера — и без доступа остаётся весь дом вместе с вашими платящими клиентами. Молча, без ответа, до тех пор пока кто-то не пожалуется.

У бана обязателен срок. Забанили ошибочно — через час отпустит само. Вечный бан требует, чтобы кто-то заметил ошибку и пришёл её чинить, а этого не происходит.

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

Готовая реализация

Мы собрали это в HUBGuard — один bash-скрипт, MIT, все четыре правила выше заложены в основу и покрыты тестами.

git clone https://github.com/qwe8nxtroud/HUBGuard.git
cd HUBGuard
sudo ./hubguard.sh plan     # показать, что будет, ничего не меняя
sudo ./hubguard.sh apply

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

Посмотреть, кто попался: hubguard.sh top. Разбанить руками: hubguard.sh unban <ip>.

Готовый комплект

Один или два сервера, бюджет ноль. Настройки ядра, nftables с лимитами по профилю, fail2ban, netdata, панель и подписка за бесплатным Cloudflare. Закрывает перебор и типовой SYN-флуд. Плюс базовая гигиена абуза: HWID-лимит устройств в панели и блок торрентов сниффингом Xray, разовый clamscan по крону (без резидентного демона, память нужна Xray). Против объёмной атаки остаётся только защита хостера, поэтому выбирайте хостера, у которого она включена изначально.

От трёх до десяти серверов, работающий сервис. То же самое плюс CrowdSec вместо fail2ban ради общего списка угроз, отдельный сервер под панель, у клиентов несколько адресов подключения. Добавьте xray-torrent-blocker для активного бана качалок, fwknop на SSH и DNS-01 под сертификаты, чтобы не светить порты и домен сканерам. Ноды прячьте за селфстилом или CDN-фронтом — это главная защита от прицельного флуда по подписке. Смена адреса без потери клиентов важнее любой фильтрации.

Больше десяти серверов, атаки повторяются. FastNetMon для автоматического отсечения, фильтр на XDP, если атаки регулярные, платная очистка трафика для критичных узлов. Резидентный clamd с on-access на панели и служебных машинах (память там есть), централизованный сбор логов торрент-блокера. На этом уровне считайте деньги: сутки простоя обычно дороже месяца защиты.

Плюсы и минусы, коротко

Рекомендованная связка

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

Каждый слой закрывает свою угрозу: периметр — объём, сокрытие — прицельный флуд по подписке, приложение — перебор, абуз-слой — своих же нарушителей. Дырка в любом уровне не рушит остальные, поэтому и строим стеком, а не одной стеной.

Чего не стоит ставить

В интернете популярны скрипты, которые давно мертвы. ddos-deflate не обновлялся с 2021 года, anti-DDoS-iptables с того же времени. Они написаны под старые ядра и iptables, на современном сервере создают ложное чувство защиты.

Отдельно — про модные «блокировщики сканеров» с готовыми списками. Их несколько, они выглядят солидно и обещают умную защиту. Разберите такой скрипт перед установкой и проверьте три вещи.

Во-первых, есть ли там детекция вообще. Часто «умная защита» — это iptables-DROP по членству адреса в скачанном текстовом файле. Никакого анализа трафика, никакой эвристики: сканером считается тот, кто заранее попал в чужой список.

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

В-третьих, чем блокирует. Блокировка по hash:net, то есть подсетями — и один список госсетей на 12 тысяч подсетей уровня /16–/24 спокойно накрывает провайдеров, за которыми сидят живые люди.

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

Главное, что стоит запомнить. Защита от DDoS это не одна кнопка, а слои. Внизу бесплатные настройки, которые обязаны быть у всех. Наверху деньги за чужой канал. Между ними умение за тридцать секунд понять, что именно происходит.

Дальше по теме: Защита панели и доступов · Инфраструктура и харднинг · Мониторинг и бэкапы