Torrent: альтернативный способ детектирования

[nuclight]

Со времени событий вокруг uTP прошло более 4 месяцев, разработчики uTorrent на месте не стояли, в теме на nag.ru тоже накатали уже более сорока страниц. Придумал и я принципиально новый способ ловить соединения торрентов, но обо всём по порядку.

Comments

[rainbow_beast]

Да нет там никакой проблемы для трекера. Берётся этот же ответ трекера, шифруется чем-нибудь с паролем в диапазоне 1000...9999, к примеру - там хоть xor подойдёт, так что много ресурсов не понадобится. Пароль не передаётся. Пользователю не проблема это расшифровать тупым брутфорсом, а вот провайдеру тяжеловато придётся...

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

На самом деле, я имел в виду SSL...

[nuclight]

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

[ext_330280]

список трекеров можно получать запуская этот же скрипт (с другим сокетом чтобы не мешать работе постоянного скрипта), скажем, раз в 20 минут, с правилом для всего http трафика с продолжительностью на 10-20 секунд. И затем складывать список треккеров в отдельную таблицу, которая используется уже для постоянного контроля.

Запуск
(./torrent_tracker_catch.pl | ./torr_ipfw_tbl_add.sh) >error.log 2>&1 &
сильно грузит проц из-за использования шела, лучше добавлять записи в таблицу внутри скрипта perl

[ext_330280]

эффективность очень низкая

Раздающих:
# ipfw table 68 list| wc -l
239653

Количество наблюдаемых треккеров:
ipfw table 12 list| wc -l
25

Вот сравнение трафика за минуту из таблицы 68 и общего UDP( table 4 - абоненты с высокой активностью количества соединений udp):
12050 121991 97920245 skipto 15000 udp from 192.168.8.0/21 to table(68) in via em0 limit src-addr 5
12051 457802 323512845 skipto 15000 udp from table(4) to any in via em0 limit src-addr 15

[nuclight]

> скажем, раз в 20 минут, с правилом для всего http трафика с продолжительностью на 10-20 секунд

При этом всё же есть вероятность, что часть трекеров будет пропущена, а хватит и одного трекера, чтоб начать кушать полосу.

> сильно грузит проц из-за использования шела, лучше добавлять записи в таблицу внутри скрипта perl

Ну, я об этом выше писал, у ЖЖ на размер поста ограничения, а модифицировать самостоятельно не столь сложно.

> эффективность очень низкая
> 12050 121991 97920245 skipto 15000 udp from 192.168.8.0/21 to table(68) in via em0 limit src-addr 5
> 12051 457802 323512845 skipto 15000 udp from table(4) to any in via em0 limit src-addr 15

Вы проверяете только по счетчикам и только в варианте с динамическими правилами? Дело в том, что limit работает так: проверяется, не превышен ли для текущего пакета лимит, если да, то пакету тут же безусловно делается deny, но вот счетчики на правиле - им всё равно инкрементируются. Попробуйте посмотреть без динамических правил.

[zyxman]

Я таблицы в ipfw гружу так:
awk '{ print "table 1 add ",$0," \n" }' < $1 | /sbin/ipfw /dev/stdin

Скорость загрузки примерно в 1000 раз ускоряется, тк там самая дорогая операция запуска ipfw, а он может хоть миллион правил за один запуск влить.

[nuclight]

Как можно заметить при внимательном прочтении текста поста, этот способ там использован.

[zyxman]

И еще, Perl может работать не только с tee но также с pcap, который на несколько порядков быстрее (потому что умеет читать много пакетов за один запрос к ядру, а "ядреная" часть умеет складывать много пакетов в буфер и ЕМНИП, даже пушить этот буфер в юсерспейс).
Программирование libpcap практически идентично divert, кроме чуть другой обертки подключения.

[nuclight]

Это рабочий Proof of concept (не использующий посторонних модулей), для промышленного применения никто не запрещает допилить, разумеется - правда, при этом libpcap будет таки несколько сложнее, плюс divert проще еще тем, что делает сборку фрагментированных пакетов.