Торренты на ноде: закрываем P2P через nDPI + Suricata

Сценарий, который проходит почти каждый: сервис работает, клиентов прибавляется, и вдруг письмо от хостера: abuse complaint. Правообладатель зафиксировал раздачу с вашего IP. Первое письмо обычно предупреждение, второе: блокировка сервера. Иногда без второго.

Проблема не только в жалобах. Торренты съедают канал: несколько человек на раздаче выжирают трафик, за который платите вы, а остальные клиенты получают тормоза.

Разберём, как это закрывается на уровне ноды.

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

Первое, что приходит в голову: закрыть «торрент-порты» 6881–6889. Не поможет: современные клиенты выбирают порт случайно, умеют работать через UPnP и вообще прекрасно живут на 443.

Второй вариант: блокировать по спискам IP трекеров. Тоже мимо: DHT работает без трекеров вообще, а списки устаревают за недели.

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

Два уровня защиты

nDPI: первый уровень, режет сам протокол

nDPI это открытая библиотека глубокого анализа пакетов от команды ntop. Она умеет опознавать больше трёхсот протоколов по сигнатурам: как выглядит рукопожатие, какие поля в каких местах, какие размеры пакетов.

Для нас важна связка ndpi-netfilter: модуль ядра Linux, который подключает nDPI прямо к netfilter. Тогда правило выглядит так: «если nDPI определил протокол как BitTorrent, то дропнуть». Пакет не доходит никуда, соединение не устанавливается.

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

Suricata: второй уровень, ловит то, что прошло

Suricata это система обнаружения и предотвращения вторжений (IDS/IPS). Работает по правилам: тысячи сигнатур, описывающих подозрительную активность.

По торрентам она ловит то, что nDPI мог пропустить: обращения к трекерам (announce-запросы), DHT-пакеты, характерные HTTP-запросы клиентов, обмен с известными пирами.

Работает в двух режимах, и разница принципиальная:

• IDS: только смотрит и пишет в лог. Ничего не блокирует. Безопасно, подходит чтобы «посмотреть, что вообще происходит».
• IPS: стоит в разрыве трафика через NFQUEUE и дропает пакеты по правилам. Эффективно, но при ошибке в настройке можно положить весь трафик ноды.

Связка «nDPI режет основное + Suricata добивает остатки» даёт результат, которого не даёт ни один инструмент по отдельности.

Готовое решение: ds-guard от DoubleServers

Команда DoubleServers выложила свой внутренний инструмент, который разворачивает обе системы одной командой:

curl -fsSL https://doubleservers.com/6eaygszz4o2yjlwfqs7lu5iw/k3coxnqhumw4fhcyzoh334hj -o ds-guard && chmod +x ds-guard && ./ds-guard

Что заявляют авторы:

• автоматически определяет версию ядра и собирает nDPI под неё;
• поддерживает кастомные ядра (например, XanMod), но сами признают, что полноценно это не тестировали;
• дополнительно блокирует IPIDEA и BadBox;
• установка 2–3 минуты на быстром сервере, около 10 минут на Hetzner;
• после установки проверяет развёртывание и выводит команды управления;
• работает на 2 vCPU / 2 ГБ RAM без заметной нагрузки;
• по их наблюдениям, потребление трафика на нодах упало примерно в полтора раза: вместо P2P через сервер идёт обычный трафик.

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

⚠️ Что вы на самом деле запускаете

Авторы называют это «скриптом». Это не скрипт. Проверяется за десять секунд:

curl -fsSL https://doubleservers.com/6eaygszz4o2yjlwfqs7lu5iw/k3coxnqhumw4fhcyzoh334hj -o ds-guard
file ds-guard

Ответ:

ds-guard: ELF 64-bit LSB pie executable, x86-64, dynamically linked, stripped

Это скомпилированный бинарник, а не текстовый файл, который можно прочитать. Копаем дальше:

strings ds-guard | grep "neither argv"

E: neither argv[0] nor $_ works.

Это фирменное сообщение об ошибке из shc, Shell Script Compiler. Инструмент берёт обычный bash-скрипт, шифрует его и заворачивает в ELF-обёртку. При запуске обёртка расшифровывает содержимое в память и скармливает его /bin/sh.

Подтверждается энтропией: вторая половина файла даёт 7.74 из 8.0, то есть зашифрованные данные. А из системных вызовов бинарник умеет ровно то, что нужно загрузчику: execvp, getenv, putenv, stat.

Вывод: исходник намеренно закрыт. Вы не можете посмотреть, что именно попадёт на сервер, а запускается это под root.

Чем рискуете

Инструмент под root может всё: поставить любой пакет, добавить ключ в authorized_keys, изменить конфиги, отправить наружу что угодно. Я не утверждаю, что ds-guard это делает: судя по отзывам, он делает ровно заявленное. Но проверить это невозможно, и решение принимаете вы.

Отдельно: shc не даёт стойкой защиты: содержимое извлекается известными способами. То есть от конкурента исходник не защищён, а вот для вас как для пользователя он закрыт. Такая асимметрия сама по себе повод задуматься.

Как снизить риск, если решили ставить

1. Никогда не на боевую ноду первой. Возьмите пустой VPS за пару долларов, поставьте туда.
2. Снимите снапшот до установки: у любого нормального хостера это одна кнопка.
3. После установки посмотрите, что появилось в системе (команды ниже).
4. Погоняйте сутки, проверьте, что клиенты подключаются и скорость не просела.
5. Только потом переносите на боевые, по одной, с интервалом.

Что проверить после установки

Инструмент выводит свои команды управления в конце установки. Сохраните этот вывод, другого источника нет. Если потеряли, восстановить картину можно самому.

Что появилось в системе:

# новые и изменённые службы
systemctl list-units --type=service --state=running | grep -iE "suricata|ndpi|guard"

# что вообще ставилось последним
grep -E " install " /var/log/dpkg.log | tail -40

# правила фильтрации: куда воткнулась защита
nft list ruleset | head -60
iptables -L -n -v --line-numbers | head -40

Suricata, жива ли и что видит:

systemctl status suricata --no-pager
suricata --build-info | head -20            # с какими опциями собрана
tail -f /var/log/suricata/fast.log          # срабатывания правил в реальном времени
tail -f /var/log/suricata/stats.log         # счётчики: дропы, пропуски

Модуль nDPI в ядре:

lsmod | grep -i ndpi
dmesg | grep -i ndpi | tail -20

Кто слушает порты, не появилось ли лишнего:

ss -tulpn | sort -k5

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

Связка с Remnawave: не сломает ли VPN

Главный вопрос: не порежет ли фильтрация ваш собственный VLESS/Reality.

Логика такая. Ваш VPN-трафик снаружи выглядит как TLS-соединение на 443, и nDPI опознаёт его как TLS, не как BitTorrent. Резать будет то, что внутри туннеля, то есть трафик клиентов после расшифровки на ноде, а это ровно та точка, где P2P и нужно ловить.

Но есть нюансы, за которыми нужно следить:

1. Ложные срабатывания. Правила Suricata пишутся широко. Часть сигнатур ловит не только торренты, но и, например, WebRTC (видеозвонки) или нестандартные QUIC-соединения. Клиент пожалуется не «у меня не работает торрент», а «Zoom отваливается». Первым делом смотрите fast.log: там видно, какое правило сработало.

2. Нагрузка на CPU. Suricata в IPS-режиме прогоняет через себя весь трафик. На 2 vCPU это нормально до определённой полосы; когда нода уезжает под сотни мегабит, процессор может стать узким местом. Смотрите top в час пик и stats.log: там счётчик потерянных пакетов.

3. Пересборка при обновлении ядра. nDPI собран под конкретное ядро. Прилетело обновление, сервер перезагрузился, модуль не загрузится, защита тихо отвалится. Проверяйте lsmod | grep ndpi после каждого апдейта, а лучше зафиксируйте версию ядра:

apt-mark hold linux-image-$(uname -r)

4. Каскады и цепочки. Если у вас связка «вход в РФ → выход за границей» (см. Каскад: вход в РФ, чистый выход), ставить фильтр надо на выходной ноде: именно с её IP уходит трафик наружу и именно на неё придёт abuse. На входной ноде толку не будет: там всё зашифровано.

5. Проверка после внедрения. Самый честный тест: реальное подключение:

# с ноды: xray живой, слушает свои порты
docker logs remnanode --tail 50 | grep -iE "error|fail"
ss -tulpn | grep -E ":443|:8443"

А со стороны клиента просто подключитесь и погоняйте обычные сайты, видеозвонок и скачивание файла. Если всё летает, а торрент-клиент висит на нуле пиров, цель достигнута.

Как откатить

Если что-то пошло не так:

# 1. остановить фильтрацию
systemctl stop suricata && systemctl disable suricata

# 2. снять правила, которые заворачивали трафик в очередь
nft list ruleset | grep -n queue          # найти строки с NFQUEUE
# удалить найденные правила или, если сомневаетесь, откатить ruleset целиком:
nft flush ruleset && systemctl restart nftables

# 3. выгрузить модуль ядра
modprobe -r xt_ndpi 2>/dev/null || rmmod xt_ndpi

# 4. проверить, что трафик ходит
curl -s -o /dev/null -w "%{http_code}\n" https://ya.ru

Если после nft flush ruleset пропал доступ по SSH: вот зачем нужен снапшот и доступ к консоли хостера.

Альтернатива: собрать самому, без закрытых бинарников

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

Шаг 1. Suricata из репозитория.

apt update && apt install -y suricata
suricata-update                    # подтянуть правила ET Open
systemctl enable --now suricata

Шаг 2. Сначала только наблюдение (IDS). Пусть сутки просто смотрит, ничего не блокируя:

# в /etc/suricata/suricata.yaml укажите свой интерфейс
ip -o -4 addr show | awk '{print $2}'      # узнать имя интерфейса
sed -i 's/^  - interface: .*/  - interface: eth0/' /etc/suricata/suricata.yaml
systemctl restart suricata
tail -f /var/log/suricata/fast.log

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

Шаг 3. Свои правила против P2P. Создайте /etc/suricata/rules/local.rules:

# BitTorrent handshake
alert tcp any any -> any any (msg:"P2P BitTorrent handshake"; content:"|13|BitTorrent protocol"; depth:20; sid:9000001; rev:1;)
# DHT (поиск пиров без трекера)
alert udp any any -> any any (msg:"P2P DHT ping"; content:"d1:ad2:id20:"; depth:16; sid:9000002; rev:1;)
# запрос к трекеру
alert http any any -> any any (msg:"P2P tracker announce"; http.uri; content:"/announce"; sid:9000003; rev:1;)

Подключите файл в suricata.yaml в секции rule-files и перезапустите. Пока это alert: только логирование.

Шаг 4. Перевод в блокировку. Когда убедились, что ложных срабатываний нет, меняете alert на drop, заворачиваете трафик в очередь и запускаете Suricata в IPS-режиме:

nft add table inet filter 2>/dev/null
nft add chain inet filter forward '{ type filter hook forward priority 0; }' 2>/dev/null
nft add rule inet filter forward queue num 0 bypass    # bypass — если Suricata упадёт, трафик пойдёт мимо
suricata -q 0 -c /etc/suricata/suricata.yaml -D

⚠️ Параметр bypass обязателен. Без него падение Suricata означает, что трафик перестанет ходить вообще.

Шаг 5. nDPI как модуль ядра: самая трудоёмкая часть, потому что собирается из исходников под ваше ядро:

apt install -y build-essential linux-headers-$(uname -r) git autoconf libtool pkg-config
git clone https://github.com/ntop/nDPI.git && cd nDPI
./autogen.sh && ./configure && make -j$(nproc) && make install

Дальше подключается ndpi-netfilter, и правило блокировки выглядит так:

iptables -A FORWARD -m ndpi --bittorrent -j DROP

Вот эту часть ds-guard как раз и автоматизирует: определяет ядро, ставит заголовки, собирает модуль. Экономия времени реальная; вопрос только в том, готовы ли вы за неё платить запуском закрытого кода под root.

Что в итоге выбрать

Моя рекомендация: если нод много и время дороже, ставьте ds-guard, но сначала на тестовую машину и со снапшотом, а после установки пройдитесь по проверкам из этой статьи. Если нода одна-две или вы принципиально не запускаете закрытый код на инфраструктуре, соберите руками, это один вечер.

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

Дальше по теме: Чек-лист безопасности сервиса · Каскад: вход в РФ, чистый выход · Защита панели и доступов