Прям настроение поднялось. Приятно видеть девушек, самостоятельно решающих такие проблемы
После включения этого файла, у меня снова ноды >800. Но не буду торопиться, может просто совпадение. Проверить-то просто: перезапустить клиент без этого файла, но я боюсь
Как всегда топчик с этого сайта. Как всегда хочется в него зарыться и читать, читать, читать…)
+1
Тоже от меня спасибо. Поставил этот клиент, перенес в него 200 раздач, пока работает. Опций у него, конечно, немало. Придется поизучать. @ Xunlei еще раз спасибо!
Поделитесь, пжс, как вы этого добились?) Какой клиент, какие настройки?
Да, так и есть. В данный момент у меня в utorrent вообще работает одна-единственная начальная нода (малопопулярная). С любыми др. dht-нодами 0 соединений
Да никак я этого не добился. Думаю, все эти настройки никакой роли не играют, когда речь идет об атаке на DHT и борьбе с торрент-трафиком.
Как я писал выше, целый месяц не включал торрент-клиент, когда обнаружил эту проблему. На той неделе проблема, вроде бы, ушла, но, как оказалось, не надолго. Сегодня опять то же самое. Как видите, в прошлый раз я ничего не делал, проблема пришла, и в этот раз я ничего не делал — она снова появилась
Нет, настройки, конечно, на что-то влияют, и даже кому-то помогают (мне, например, тоже когда-то помогла смена порта на 1024, когда сеть DHT показывала 0 узлов), но, к сожалению, не в этом случае.
Клиент µTorrent 3.6.0.47196. Когда все нормально, узлов больше 800. В Tixtati у меня больше 450 не поднимается. Почему, не знаю. Может быть, поэтому:
в сравнении = uTorrent 3.6 (DHT:800 узлов) vs qBittorrent 5.2.0 (узлы DHT:320)
// при одинаковом списке раздачи-закачке и одинаковом времени работы
Если я правильно понимаю, фейковые ноды захламляют DHT-пространство длинными списками, вынуждая торрент-клиенты бросать поиск новых DHT-узлов. Возможно, поэтому в клиенте это выглядит, как набор узлов до определенной точки, а затем сброс и повторный вход в сеть с потерей набранных узлов.
So there are different groups of fake nodes performing different work. Some passively observe the DHT traffic, relay data, and can’t be trivially marked as evil, some are chosen as intermediate nodes that report fake and non-existent nodes, some are always at the end of the line to surround the hash/ID.
This has been going on for almost five months. They rotated and added fake nodes each day. First, they only observed and measured how effectively their nodes were inserted in request chains and node lists. Recently, they started to reply with long lists of fake nodes to make torrent clients give up the search after many futile tries. You can check the Search tab, and see dozens of non-existing node addresses that are reported by each attacking node. I don’t know how they choose their targets from all torrenting clients, but it probably depends on long session length and total number of torrents.
Возможно есть и другие причины. Но то, что идет какое-то вмешательство извне, по-моему, очевидно. Tixtati получше себя проявляет в такие периоды, но его тоже это не обходит.
Вопрос выше так и остался без ответа. Есть ли какой-то смысл в подобных списках, применительно к торрент-клиентам?
Спасибо! С этим клиентом кол-во узлов стало в районе 500, но до 800 пока не дошло)
upd Уже в районе 700+, так что да, дело в клиенте. Но насколько эти узлы рабочие, вопрос
Да, пиcали, что какие-то атаки идут на сеть dht
На моем провайдере на поиск узлов влияет лишь адрес начального узла и порт входящих соединений. С некоторыми адресами всегда 0 соединений, так же, как с некоторыми портами. Похоже, что блокируется большая часть известных начальных dht-нод плюс определенные порты
Имхо, есть смысл добавить то, что вам предложил Xunlei - CIDR блокируемых хостингов. Дабы не ловить триггерные блокировки
Спасибо Поизучаю, что у него там на странице. Пока добавил combined-final-win.dat, посмотрим, как он себя проявит. Надеюсь, до экспериментов с nping --udp дело у меня не дойдет )
Ну, до этого тоже, надеюсь, не дойдет
Добавил в избранное. Почитаю позже в деталях. Пока добавил только несколько фильтров, не могу сказать лучше стало или хуже. Кажется, дропы продолжаются. Вы вроде бы давно пользуетесь Tixtati, скажите: такой график это нормально?
После примения этих фильтров, наверное, еще рано судить, но пока большой разницы не вижу, к сожалению
Этих фильтров достаточно, или еще нужно что-то применить в обязательном порядке?
Ответ очень прост. Когда все нормально, у меня сразу подхватываются 15-18 активных раздач на полный канал. Когда начинается проблема, uTorrent вообще може пустовать, или вяло раздавать 1-2 раздачи. В Tixtati чуть получше, но не сказал бы что намного.
Попробую. У него на картинке много чего. Но неужели всё это нужно? Какие наиболее важные фильтры из всех, хотелось бы понять. All CIFRs?
Вроде плоховато — мало ответов на исходящие запросы (но у меня на картинке же плюсуются и неблокируемые IPv6 через туннель и I2P; и не понятно, как трактовать исходящие ответы — это ответы от нод на исходящие запросы клиента или ответы от клиента на входящие запросы ), и у меня анонсирование выключено, пока поиска достаточно.
Доступные по ссылке фильтры можно вставить как ссылку и настроить автообновление (или через планировщик задач Windows).
DPI triggering — чтобы снизить шанс блокировки, остальные опциональны для снижения бесполезного трафика.
Я имел в виду внезапный дроп с ошибками. Таких выраженных дропов, конечно, немного, но если смотреть на график, то каждые 2-3 минуты (максимум 10) они есть.
В статье еще писалось про десятки несуществующих адресов узлов, которые можно увндеть на вкладке поиска
You can check the Search tab, and see dozens of non-existing node addresses that are reported by each attacking node.
Я посмотрел. Действительно, даже на редких раздачах, где не должно быть, по идее, много нодов, их оказывается за сотню-полторы, абсолютное большинство которых, при этом, со статусом Failed. Об этом речь?
Спасибо! Буду дальше, по возможности, пробовать. Жаль, что времени на это много уходит, и с очень малым результатом пока. Но надеюсь, дальше лучше будет
А есть готовая сборка со всеми плагинами? Помню, были сложности с переносом раздач из uTorrent в этот клиент, именно поэтому в свое время не перешел на него. Не знаю, как у него с этим сейчас, но в Tixtati перенос сделан с умом.
В общем, сейчас вернулся к теме на рутрекере, посмотрел на нее свежим взглядом. Да, кажется, удалось найти косвенное подтверждение догаткам. Выбрал некоторые цитаты. Надеюсь, автор не против.
Спойлер
Я вот вижу эту ерунду у себя в клиенте, все как описано в упомянутых статьях по атакам на DHT. Куча DHT-узлов с портом 6881 и фальшивыми идентификаторами. Сбрасываешь локальный на новый, и тут же тебе шлют эти же самые адреса с новыми идентификаторами, которые максимально близки к твоему. Магнитная ссылка на популярную раздачу с сотнями пиров собирает 150-200 узлов, все оказываются Failed, и пиров в DHT не находится. Ну такого не бывает.
В свежий клиент через десять минут активно напихивают чуть ли не 30 штук фальшивых узлов DHT с максимально совпадающим хэшем, а в целом из пяти сотен набранных пиров DHT как минимум половина занимается подменой адресов и практически полностью контролирует доступность данных для клиента.
Вы не наблюдаете, потому что не знаете, куда смотреть, а великолепные популярные программы вообще не показывают, что у них внутри творится с DHT. Попробуйте добавить в клиент случайный хэш и посмотреть на узлы, которые отвечают с идентификатором, максимально близким ему. Потом добавьте другой случайный хэш, и увидите, как те же самые узлы внезапно присылают уже такие идентификаторы. Или посмотрите на количество узлов, имеющих максимально близкие к вашему клиенту координаты. Меняете свой идентификатор, и тут же находятся другие такие же. Все эти манипуляции описаны чуть ли не 20 лет назад.
//Атака прошла, и все “само починилось”. 365 DHT, больше сотни пиров везде.//
Ага, конечно. Больше миллиона пакетов к адресам из списка подозрительных в сутки, по десятку в секунду. Это треть или половина общего трафика DHT. В нормальном клиенте всё видно в подробностях, и их количество потихоньку растёт и растёт. Просто результат является вероятностным и зависит от того, какой у вас торрент-клиент, сколько у вас торрентов и насколько активно он их ищет в DHT, какие начальные адреса реальных пользователей вам попались и насколько они стабильны, какие адреса попались участникам, к которым вы обращаетесь на первом и последующих шагах, сколько времени длится сеанс и сколько ботов вам набралось. Если не повезло, и фальшивые узлы заняли все самые близкие места на пути к хэшу, вы пиров для этого торрента от них уже не получите. Аналогично с попытками поиска близких к вашему узлу реальных узлов для долговременных контактов, боты будут выдавать только адреса друг друга.
Пробовал, как здесь написано, добавить случайный хэш к раздачам. Сразу появляется 150-175 нодов, практически все Failed. Насколько они там все на друг друга похожи, не стал разбираться. Ясно, что атака на DHT идет — вопрос что делать? Какие методы противодействия использовать?
Клиент добавляет узел в routing table только после успешного обмена сообщениями.
Используются PING/PONG перед сохранением узла.
Тайм-ауты и повторная проверка
Неактивные узлы удаляются.
Перед заменой старого узла выполняется повторный запрос.
2. Защита от Sybil-атак
Sybil-атака заключается в создании большого числа ложных идентификаторов узлов.
Методы защиты:
ограничение количества узлов с одного IP-адреса;
ограничение количества узлов из одной подсети (/24 для IPv4, аналогично для IPv6);
предпочтение узлов из разных автономных систем (AS);
криптографически связанные Node ID (в некоторых реализациях).
3. Защита от Eclipse-атак
При Eclipse-атаке злоумышленник стремится заполнить routing table жертвы своими узлами.
Применяются:
разнообразие источников узлов;
случайный выбор соседей;
ограничение количества записей с одного диапазона адресов;
медленная замена старых проверенных узлов новыми.
4. Проверка соответствия Node ID IP-адресу
Некоторые клиенты используют Node ID Security:
Node ID частично вычисляется из IP-адреса;
невозможно произвольно выбирать идентификатор;
значительно усложняется Sybil-атака.
Этот механизм реализован, например, в некоторых современных версиях libtorrent.
5. Rate Limiting
Для защиты от DHT Flooding:
ограничение числа запросов в секунду;
ограничение количества запросов от одного IP;
отдельные лимиты для различных типов сообщений (find_node, get_peers, announce_peer).
6. Токены (Token Validation)
Перед выполнением announce_peer клиент обязан получить специальный токен.
Это позволяет предотвратить:
регистрацию ложных пиров;
удаленное загрязнение DHT.
Токен:
короткоживущий;
вычисляется с использованием секретного ключа узла;
зависит от IP отправителя.
7. Проверка ответов
Клиенты проверяют:
корректность структуры bencoded сообщений;
допустимые размеры пакетов;
совпадение transaction ID;
наличие обязательных полей;
корректность Node ID.
Некорректные ответы игнорируются.
8. Защита routing table
Используются правила Kademlia:
k-buckets фиксированного размера;
предпочтение старых стабильных узлов;
новые узлы не вытесняют давно работающие без проверки;
LRU (Least Recently Used) для обновления записей.
Это существенно повышает устойчивость сети.
9. Ограничение bootstrap
Bootstrap выполняется только через доверенные узлы.
Популярные реализации используют заранее известные bootstrap-серверы и затем постепенно переходят к полностью распределенной работе.
10. Криптографическая защита
В классическом Mainline DHT сообщения обычно не подписываются, однако возможны дополнительные меры:
цифровые подписи;
проверка целостности сообщений;
защищенный транспорт (экспериментальные реализации).
Недостаток — увеличение нагрузки и снижение совместимости.
11. Обнаружение аномалий
Клиенты могут анализировать:
слишком частые ответы;
одинаковые Node ID;
необычную концентрацию узлов в одном диапазоне ID;
большое количество ошибок протокола.
Подозрительные узлы помещаются в черный список.
12. Blacklist и репутация
Некоторые реализации поддерживают:
временную блокировку IP;
счетчики ошибочных сообщений;
исключение узлов, нарушающих протокол;
локальную репутацию без централизованного сервера.
Современные направления исследований
В научных работах предлагаются дополнительные методы:
Secure Node ID — привязка идентификатора к IP или криптографическому ключу.
S/Kademlia — модификация Kademlia с повышенной устойчивостью к Sybil- и Eclipse-атакам.
Криптографическая аутентификация участников DHT.
Proof-of-Work для регистрации узлов, чтобы сделать массовое создание идентификаторов более затратным.
Репутационные модели, оценивающие надежность узлов по их поведению.
Итог
На практике наиболее эффективной оказывается комбинация нескольких механизмов:
проверка достижимости узлов;
ограничение количества узлов с одного IP или подсети;
привязка Node ID к IP или ключу;
защита announce_peer с помощью токенов;
ограничение частоты запросов (rate limiting);
консервативное управление routing table;
обнаружение аномалий и временная блокировка подозрительных узлов.
Видимо, да. Хотя qBittorrent, судя по всему, не так безнадежен на фоне uTorrent и Tixati
Спойлер
Полностью настроить перечисленные защитные механизмы можно только в клиентах на базе libtorrent (например, qBittorrent)**. В µTorrent и Tixati большинство внутренних механизмов защиты DHT реализованы разработчиками и недоступны для изменения через интерфейс.
qBittorrent
qBittorrent использует libtorrent, где многие защитные механизмы уже включены по умолчанию:
ограничение узлов из одной подсети (dht_restrict_routing_ips=true);
ограничение узлов при поиске (dht_restrict_search_ips=true);
предпочтение проверенных Node ID по BEP 42 (dht_prefer_verified_node_ids=true). ([libtorrent.org][1])
В графическом интерфейсе доступны только косвенные настройки:
Инструменты → Настройки → BitTorrent
Enable DHT
Enable Peer Exchange (PeX)
Enable Local Peer Discovery (LSD) — можно отключить, если локальная сеть не используется.
включите IP Filtering и подключите актуальный ipfilter.dat, если хотите блокировать известные диапазоны IP. ([GitHub][2])
Если вы используете стандартные сборки qBittorrent, изменить такие параметры, как dht_enforce_node_id, dht_restrict_routing_ips или dht_aggressive_lookups, через интерфейс нельзя — они задаются библиотекой libtorrent и обычно уже имеют безопасные значения по умолчанию. ([libtorrent.org][1])
µTorrent
У µTorrent возможности значительно скромнее.
Можно настроить:
Options → Preferences → BitTorrent
включить или отключить DHT;
включить DHT для новых торрентов;
включить Peer Exchange;
включить Protocol Encryption.
Через Advanced можно изменить некоторые параметры соединений и кэширования, но:
нет ограничения узлов по подсетям;
нет проверки BEP 42 Node ID;
нет управления токенами DHT;
нет настройки защиты routing table.
Большинство защитных механизмов либо отсутствуют, либо жестко встроены в клиент.
Tixati
Tixati предоставляет больше диагностической информации о DHT, чем µTorrent, но также почти не позволяет менять внутреннюю логику защиты.
Доступно:
включение/отключение DHT;
просмотр статистики DHT;
ограничение общего числа соединений;
ограничение скорости передачи;
настройка фильтрации IP (при использовании внешних списков).
Недоступно:
настройка проверки Node ID;
ограничение по CIDR;
изменение алгоритмов Kademlia;
управление токенами DHT.
Если нужна максимальная защита DHT
Из этих трех клиентов qBittorrent обеспечивает наиболее современную защиту благодаря использованию libtorrent, где реализованы ограничения на узлы из одной подсети, поддержка проверенных Node ID (BEP 42) и другие механизмы защиты DHT, причем большинство из них включены по умолчанию. ([libtorrent.org][1])
Если интересует именно тонкая настройка DHT (например, изменение dht_enforce_node_id, dht_privacy_lookups, размеров routing table, агрессивности поиска и других внутренних параметров), то это обычно требует работы не с qBittorrent, а непосредственно с приложением, использующим API libtorrent, либо собственной сборки клиента с измененными настройками библиотеки.
Куда ж деваться. Второй день страдаю. Сегодня опять без молока остался. Хорошо, что ближайшие 10 дней как-то не до торрентов будет. Может, к тому времени и проблема сама уйдет? Почему бы нет. Поатакуют, поатакуют, да перестанут )
Все, что под спойлерами, было от chatgpt. Есть еще ответ про списки от него
Спойлер
IP-фильтры не защищают непосредственно от атак на DHT (например, Sybil-, Eclipse- или отравления таблицы маршрутизации). Они лишь предотвращают соединения с адресами, уже внесенными в списки по репутации. Узлы, участвующие в DHT-атаках, могут использовать новые или ранее не замеченные IP-адреса, поэтому полагаться только на ipfilter.dat не стоит. Основную защиту обеспечивают механизмы самого DHT-клиента (проверка Node ID, ограничения по подсетям, токены announce_peer, rate limiting и т. д.).
Если ваша цель — именно защита DHT от вредоносных узлов, а не общая фильтрация IP, можно также рассмотреть использование собственного динамически обновляемого списка на основе журналов клиента и внешних репутационных источников. Это обеспечивает более актуальную защиту, чем статический ipfilter.dat.
Если цель — уменьшить количество соединений с известными вредоносными или подозрительными адресами, а не просто заблокировать «всех подряд», то сегодня наиболее актуальны следующие источники.
1. IPFilter Updater (рекомендуется для торрент-клиентов)
Это один из наиболее активно поддерживаемых проектов для PeerGuardian/qBittorrent/µTorrent-совместимых фильтров. Он ежедневно публикует готовый ipfilter.dat и автоматически объединяет несколько источников. Обновления выходят регулярно. ([ipfilter.app][1])
Исторически самый известный поставщик списков IP. Он поддерживает списки в форматах P2P, DAT и CIDR, совместимых со многими торрент-клиентами и сетевыми фильтрами. Однако часть классических списков обновляется менее активно, чем раньше, поэтому стоит обращать внимание на дату конкретного списка. ([iblocklist.com][2])
FireHOL не создает собственые списки «с нуля», а агрегирует и анализирует множество независимых источников. Это особенно полезно, если вы хотите самостоятельно выбрать категории (ботнеты, сканеры, вредоносные узлы и т. п.) или использовать списки на уровне межсетевого экрана. ([FireHOL IP Lists][3])
Для большинства пользователей оптимален такой вариант:
IPFilter Updater — как основной ipfilter.dat.
Обновление списка раз в сутки.
Не использовать слишком агрессивные списки, блокирующие половину Интернета.
Чего стоит избегать
Многие старые руководства рекомендуют:
Bluetack Level1;
старые PeerGuardian-листы;
списки десятилетней давности.
Часть из них уже практически не поддерживается или обновляется нерегулярно, поэтому их эффективность сегодня ограничена. ([FireHOL IP Lists][4])
Спойлер
Короткий ответ: нет, общепринятых и регулярно обновляемых “черных списков вредоносных DHT-узлов” для сети BitTorrent не существует.
Причин несколько.
DHT-узлы очень динамичны. Миллионы клиентов постоянно появляются и исчезают, многие используют динамические IP-адреса. Блокировка IP быстро устаревает и может затронуть уже другого, легитимного пользователя. Исследования показывают, что переиспользование IP-адресов существенно снижает надежность классических блок-листов.
Атаки обычно строятся не на постоянных IP. Например, Sybil- или Eclipse-атака достигается созданием множества узлов с определенными Node ID. Злоумышленник может сменить IP и снова войти в сеть.
Современная защита сместилась с блок-листов на проверку поведения узлов. Например, в libtorrent реализовано ограничение выбора Node ID на основе внешнего IP (BEP 42 / DHT Security Extension), что затрудняет создание большого числа “выгодных” идентификаторов. ([libtorrent.org][1])
Что используют исследователи
В научных работах встречаются экспериментальные подходы:
локальные репутационные системы;
обнаружение аномальных распределений Node ID;
выявление групп Sybil-узлов;
временные локальные черные списки, формируемые самим клиентом. ([ResearchGate][2])
Но эти решения, как правило, не публикуют в виде готовых списков IP.
Что делают крупные реализации
Например, libtorrent вообще не опирается на внешние блок-листы DHT. Вместо этого используются:
проверка Node ID;
ограничения по IP-префиксам;
защита bootstrap;
токены announce_peer;
ограничения при заполнении routing table. ([libtorrent.org][1])
Если хочется повысить защиту
Наиболее практичный вариант — не искать готовый список, а вести собственый локальный blacklist, формируемый по наблюдениям клиента. Обычно в него включают узлы, которые систематически:
возвращают некорректные bencoded-ответы;
отвечают Node ID, не соответствующими ограничениям BEP 42 (если клиент это проверяет);
генерируют аномально большое число запросов;
участвуют в подозрительных кластерах с близкими Node ID;
неоднократно не проходят проверку достижимости (PING).
Такой список значительно полезнее статического IP-фильтра, потому что отражает реальное поведение узлов, а не только их адреса.
Если вы готовы использовать дополнительное ПО или модифицировать клиент, можно также запускать собственный DHT-краулер, который собирает таблицу узлов, анализирует их поведение и автоматически формирует локальный blacklist. Именно такой подход чаще применяется в исследовательских проектах и дает больше пользы, чем универсальные публичные списки, которых на сегодняшний день фактически нет.
Спасибо. Похоже, все-таки придется снова попробовать qBittorrent. Кстати, если бы не ваше сообщение, я бы, наверное, не полез в чат к ИИ. Но раз уж туда полез, то можно еще его послушать — красиво ведь чешит
Спойлер
Главным методом защиты современных торрент-клиентов (таких как qBittorrent, uTorrent) от атак на DHT-сеть является применение официального расширения безопасности BEP 42. Оно жестко привязывает идентификатор узла (Node ID) к его реальному IP-адресу. [1, 2]
Децентрализованная сеть DHT (Mainline DHT) уязвима к двум опасным типам угроз: атаке Сивиллы (Sybil Attack), когда один злоумышленник создает тысячи фейковых узлов, и затмению (Eclipse Attack), когда атакующие узлы изолируют жертву от остальной сети. [3, 4]
Ключевые методы защиты в клиентах
Привязка Node ID к IP (BEP 42): Клиент генерирует свой Node ID на основе хеш-суммы (CRC32C) своего внешнего IP-адреса с добавлением соли. При обмене данными узлы проверяют этот хеш. Если ID сгенерирован не по правилам, узел мгновенно блокируется. Это не позволяет атакующему «подделать» ID для перехвата конкретного торрента. [1, 2, 5]
Лимитирование по IP-адресам (IP Throttling): Ограничение количества узлов DHT, которые могут находиться на одном IP-адресе или в одной подсети /24 в таблице маршрутизации клиента. Это защищает от заполнения таблицы фейковыми узлами с одного сервера. [3, 6]
Механизм токенов (Tokens): При поиске пиров (get_peers) узел выдает клиенту временный зашифрованный токен. Объявить себя раздающим (announce_peer) клиент может, только вернув этот токен обратно. Метод предотвращает спуфинг (подмену IP-адресов). [7, 8]
Защита от DDoS (Rate Limiting): Ограничение частоты входящих UDP-запросов (PING, FIND_NODE), чтобы клиент не стал участником отраженной DDoS-атаки (DRDoS). [8, 9]
Режим «только чтение» (BEP 43): Клиенты на мобильных устройствах или со слабым каналом могут объявить себя Read-only. Они участвуют в поиске, но другие узлы не вносят их в свои таблицы маршрутизации, снижая на них нагрузку и риски. [1, 10]
В современных торрент-клиентах базовые механизмы защиты DHT (вроде BEP 42 и лимитов на пакеты) встроены в ядро по умолчанию. Однако вы можете усилить защиту, настроив фильтрацию, лимиты и конфиденциальность. [1, 2]
1. qBittorrent
Клиент использует движок libtorrent, где большинство защитных механизмов BEP активны по умолчанию. Дополнительно настроить безопасность можно так: [2]
Прокрутите вниз до параметров сетевых ограничений.
Найдите и активируйте Анонимный режим (Anonymous Mode) — это скрывает ваш User-Agent и запрещает отправлять ваш реальный IP-адрес напрямую в заголовках пакетов DHT. [4]
Чтобы защитить DHT от утечки через локальный интерфейс при работе с VPN, в графе Сетевой интерфейс жестко выберите имя вашего VPN-подключения (вместо «Любой интерфейс»). [3]
Перейдите во вкладку БитТоррент и при необходимости подключите IP-фильтрацию (загрузив файл p2p.p2p или BAM), чтобы отсекать IP-адреса известных ботнетов от вашей DHT-сети.
2. uTorrent
В uTorrent тонкая настройка скрыта в недокументированных параметрах движка.
Откройте Настройки → Настройки программы → Дополнительно (Advanced).
Используйте строку «Фильтр» для изменения следующих флагов:
net.outgoing_max_port и net.incoming_max_port: установите фиксированные значения, чтобы сузить диапазон портов и минимизировать сканирование из DHT.
ipfilter.enable: переведите в значение true, чтобы включить блокировку подозрительных подсетей через файл ipfilter.dat (его нужно положить в папку %AppData%\uTorrent).
bt.anonymous_mode: переведите в true, чтобы усложнить индентификацию вашего узла.
Если вы хотите полностью защитить себя от атак на децентрализованную сеть в ущерб поиску редких раздач, измените dht.rate на более низкое значение (например, 1048 вместо дефолтных значений), чтобы ограничить объем входящего трафика DHT.
3. Tixati
У Tixati один из самых продвинутых и уникальных инструментов для кастомизации DHT. [5]
Откройте Settings (Настройки) → DHT. [1]
Ротация Node ID (Защита от слежки): Включите опцию Auto-change Node-ID и задайте интервал (например, раз в неделю или при каждом запуске). Смена ID сбрасывает таблицы маршрутизаторов атакующих и полностью «очищает» ваш узел от Eclipse-атак. [1]
Перейдите в Settings → IP Filter. Нажмите On, затем Add и вставьте URL-адрес надежного блок-листа (например, списки уровня P2P/Ботнеты). В настройках фильтра обязательно поставьте галочку Apply to DHT, чтобы заблокированные IP-адреса не могли даже пинговать ваш DHT-клиент. [6, 7, 8]
В разделе Settings → Network → Connections вы можете переключить Network Mode на IPv4 only (или IPv6 only), чтобы злоумышленники не могли атаковать ваш клиент по альтернативному сетевому протоколу, если он защищен хуже. [9, 10]
IP-фильтрация (IP Filter) в торрент-клиентах блокирует пакеты от вредоносных узлов (антипиратских мониторинговых агентств, спам-ботов, шпионских и зараженных серверов). Она запрещает им подключаться к вам напрямую и слать ложные данные через сеть DHT. [1, 2, 3]
Где взять актуальные списки (Blocklists)
Большинство крупных баз (например, iblocklist.com) стали полностью платными. Использовать бесплатные альтернативные источники можно следующими способами: [3]
Репозиторий IPFilter Updater (Рекомендуемый)
Где взять: Проект IPFilter.app (официальный GitHub-репозиторий разработчика DavidMoore).
Ссылка для скачивания: Прямая ссылка на файл ipfilter.dat (обновляется автоматически каждую ночь). [2, 4, 5]
База eMule Security
Где взять: Крупный бесплатный регулярно обновляемый немецкий P2P-список.
Скопируйте скачанный файл ipfilter.dat прямо в эту открывшуюся системную папку.
В uTorrent зайдите в Настройки → Дополнительно. Найдите параметр ipfilter.enable и переведите его в true. Перезапустите клиент. [3, 4, 7, 8]
Важное замечание: IP-фильтры — это хорошая базовая защита от массового спама в DHT, но они не защищают на 100% от слежки. Профессиональные антипиратские компании и провайдеры постоянно арендуют новые случайные пулы IP-адресов, которых нет в списках. [2, 3]
Параметр dht_prefer_verified_node_ids=1 ?
Вроде как включен по умолчанию.
Вот есть консольный бинарник для линукса (из состава libtorrent 1.2). Можете в нём потестить фичу.
./client-test --enable_dht=1 --dht_prefer_verified_node_ids=1 --allow_multiple_connections_per_ip=0 --no_connect_privileged_ports=1 'ссылка на magnet'
качает в текущую папку со всех интерфейсов без запроса содержимого.
Также можно увидеть подробный лог, дописав в опции -f log
), и у меня анонсирование выключено, пока поиска достаточно.
Enable DHT
Важное замечание: IP-фильтры — это хорошая базовая защита от массового спама в DHT, но они не защищают на 100% от слежки. Профессиональные антипиратские компании и провайдеры постоянно арендуют новые случайные пулы IP-адресов, которых нет в списках. [2, 3]