Документация по ОС FreeBSD Воскресенье, 07.12.2025, 12:17
Главная
Регистрация
Вход
Приветствую Вас Гость | RSS
Меню сайта

Категории каталога
Apache [58]
DNS [25]
FTP [27]
Mail [74]
Samba [24]
Squid [46]
SSH [23]
VPN [35]
РРР [20]
Net [173]

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

Вести с полей

До разработчиков дошла весть, что протокол они реализовали не по собственной же спецификации, и в апдейтах uTorrent, а также выпущенной в мае опенсорсной реализации uTP поддерживаются уже оба формата. Как и ожидалось, со сменой формата пошла такая же волна, и сигнатуры пришлось усложнять. Найти их можно всё в той же теме на Наге (первые 20 страниц можно пропустить). Обсуждали и (опять) сторону кооперации - тут ведь такой момент, рубить пришлось и тем провайдерам, которые вполне лояльно относились к торрентам. Причем эффект это дало положительный и для пользователей: на tcp у них качает быстрей. Кто-то ругался в том же духе, что и я в предыдущем посте по теме:

Вы не поверите, но разработчики uTP стремились именно снизить overhead за счет того, что часть функций TCP уже реализована в протоколе BitTorrent (вычисление контрольных сумм, повторная передача частей с плохой суммой). Но они столкнулись с проблемой congestion control, которую до этого люди много лет решали для TCP, что и привело к увеличению нагрузки на сеть. Я вообще удивляюсь, что они не пригласили для разработки uTP ни одного ученого, специализирующегося на congestion control. Это очередное проявление инженерной самонадеянности, что дескать можно обойтись без научного подхода, которая привела к созданию таких уродов, как архитектура х86 и язык PHP.

Однако, как оказалось, разработчики не то что ученых не пригласили - они даже тестировали не в реальных условиях. Создавался uTP для медленных ADSL-линков, ну и ладно, а Ethernet проверяют пусть пользователи. Именно так: админы с Нага подняли тему на форуме разработчиков:
http://forum.utorrent.com/viewtopic.php?id=76254  - и получили вот такой ответ:

- Also, if you mentioned laboratory testings - do you check how uTP willl load softrouter comparing to TCP?
- No, we have not run any such tests. To a very large degree, we rely on reports from our users, including you

Экспериментаторы на всея Интернете, тьфу. Впрочем, на определенный контакт они всё же пошли:

Извините за реанимацию темы. Тут Арвид Норберг (BitTorrent Inc) ищет добровольцев, чтобы потраблшутить этот косяк с мелкими пакетами.
Разыскивается: ISP, у которого оборудование просело от uTP, готовый немного поэкспериментировать на своих пользователях.

Однако, коллективный разум nag.ru выдвинул идею, по типу уже имевшей место быть кооперации трекеров с провайдерами насчет retracker.local:

На форуме utorrent пробегала правильная идея насчет выключения uTP путём внесения определенной записи в ДНС, т.е. чтобы этот вопрос решался конкретным сетевым администратором.

Однако разработчики на это предложение ответитили совершенно недвусмысленным отказом. Более того, затем были комментарии уже вполне научного характера - народ разобрался в их намерениях и стал предлагать более совершенные алгоритмы, по анализу выходит, что им, в принципе, даже и не обязательно уменьшать размер пакета для этого. Добровольцы пошли дальше и посмотрели на то, что вместо общепринятого термина latency они вводят свой производный delay (дельта между минимальным latency за последние 2 минуты), это-то ладно, но дальше они привязывают его к совершенно произвольной константе в 100 миллисекунд, без учета реального положения дел в сети. Им был предложен алгоритм (даже на псевдокоде расписали!), который вычисляет нужное значение по статистике за последние 2 минуты - что заодно позволит избавиться и от пилообразных графиков загрузки канала, колебаний вокруг нужного размера. Только куда там, с тех пор прошло более 3 недель, а в теме до сих пор тишина...
А вот как откомментировал открытые исходники libutp в той же теме на nag.ru товарищ с ником Ivan_83:

Но пока:
if (flags == ST_RESET && (conn->conn_id_send == id || conn->conn_id_recv == id))
можно попробовать тупо слать PacketFormatV1 с connid 0 до 65535 и type= ST_RESET; на адрес/порт жертвы.
по идее это оторвёт все коннекты на uTP, только адрес/порт узнать сначало нужно.
Можно написать в фаере заворот (зеркалирование) всего UDP на отдельную машину на один порт, которая будет проверять пакет uTP или нет, если да то слать пачку/несколько ресетов юзеру, можно даже заспуфить IP отправителя (если работать на машине-фаере его можно получить из pf/ipfw). Если даже будет ложный детек-маловеротно что ресет пакеты uTP другие проги воспримут/пострадают.
PS: просмотр чужого кода почти всегда отбивает желание этим пользоваться :(
PPS: чукча не читатель, чукча писатель: повторили косяк с дыркой в DNS, а ведь в изначальном пакете connid был 32 бита, хотя бы, и доп поля не проверяются при разрыве (и вообще не понятно проверяются ли - код бегло пролистал).
PPPS: UDP для торрента хорошо, реализация та ещё - бррр - уже костыли торчат v, v1 и по мелочам.

После чего он реализовал демона, который вешается на divert-сокет и отправляет концам uTP-соединения пакет сброса, т.е. позволяет прервать соединение и в середине (сигнатуры ловили только пакет установления, что означало медленное падение трафика с начала резки). Код он выложил тут: 

За ним последовал Max Irgiznov, который взялся переделать код его демона в netgraph-ноду, дабы в режиме ядра было производительнее; выложил её в двух вариантах: первый генерирует ответы, второй просто дропает пакеты. Впрочем, код сырой, работает в ядре, так что пользуйтесь на свой страх и риск - демон на divert хоть и работает в userland, как natd, но для UDP-трафика нагрузки, на самом деле, невелики.

О пользе универсальных интерфейсов

Тут надо немножко сказать про этот самый механизм divert(4), который позволяет такие трюки. Давным-давно, в 90-х, когда возникла задача NAT, типичный способ её решения был - прям тут же в ядре реализовать непосредственное решение этой задачи. Это вообще распространенный подход: не особенно задумываясь, взять первое подходящее. Во FreeBSD решили несколько иначе: задачу увидели в чуть более общем виде, как изменение проходящих пакетов, и реализовали соответственно - raw-сокеты были уже известны, ввести аналогичный тип сокетов под эту задачу было несложно. Если задача универсализируется путем довольно простых добавлений - именно так и стоит делать. Хотя это и могло казаться ненужным, ибо долгое время единственным используемым потребителем divert-сокетов был natd - другие пользователи таки появились. Работает divert так: в адресе сокета процессу возвращается идентификатор (номер правила ipfw), на котором пакет был "завернут" (diverted) в userland. Процесс обычно отправляет пакет обратно в ядро с тем же самым адресом, и путь по правилам ipfw продолжаается с прерванного места (см. схему), но может и изменить его произвольным образом, тогда далее пакет пойдет с другого правила. То есть, это способ для приложения послужить аналогом набора правил "skipto" для ipfw.
Именно так, помимо вышеупомянутого демона для uTP, работает, например, ipfw-classifyd: анализирует пакеты на предмет сложных протоколов, в ipfw возвращается только номер правила результата - какой протокол получился, что с ним делать. Преимущество обработки пакетов отдельным демоном - выше надежность системы (баги с падениями бывали актуальны даже для natd, ядро же упало бы в таких случаях в панику), проще программировать, доступно куда больше возможностей. Цена - более низкая производительность на переключениях контекста, но актуально это не для всех задач. Ну, допустим, анализируемого трафика не так много. Или же с ним производятся достаточно сложные действия, начиная с проверки регулярных выражений - здесь затраты на переключение контекста станут несущественными сравнительно с основной работой.

Рыба гниёт с головы

Эта старая поговорка применима не только к незадачливым разработчикам uTorrent, хотя именно их идиотизм и вызвал к жизни послужившие основой сего поста исследования. Здесь мы пойдем дальше - к голове BitTorent-сети.
Какова, собственно, задача шейпинга/блокировки у провайдера? Найти соединения интересующего протокола, то есть пары IP:port (с обеих концов), что с ними делать дальше, известно. Именно задачу поиска пытаются решить фильтры по сигнатурам непосредственно в потоке данных, и именно им усложняет работу шифрование. Казалось бы, неразрешимо, разработчики клиентов всегда будут опережать провайдеров в этой борьбе.
Однако откуда эту информацию берут сами клиенты? Они откуда-то знают, куда соединяться, никакой анализ сигнатур всего проходящего трафика им для этого не требуется. Получают они её с трекера (в случае торрентов). Именно это и есть та "голова" сети, её слабое место. Анализ трафика на сигнатуры кажется естественным, потому что это еще один применяемый к очередному пакету тест (вроде "это порт 80?") непосредственно на том оборудовании, которое тут же применит и действие. Но можно ведь и загрузить правила откуда-то извне, без таких дорогостоящих проверок, если знать списки - кто куда собирается соединиться. Такой анализ, разумеется, сложнее и затратнее - но, с другой стороны, управляющего трафика, от трекера, куда меньше трафика данных, так что в сумме выйдет дешевле.
Предположим, схема такая - мы знаем адреса трекеров, мы отправляем их HTTP-трафик на машину с FreeBSD для анализа. Скрипт на ней выдает правила (ACL) уже непосредственно для тех железок, через которые идут данные. Поскольку трафика трекеров сравнительно не так много, с этим справится скрипт на Perl, висящий на divert-сокете. Тут-то он, divert, и пригождается - в ядро Perl не засунешь.
Здесь надо немного рассказать о том, как торренты работают. Клиент запрашивает у трекера список пиров для каждой раздачи - это адреса и порты других клиентов (пиров), куда он может коннектиться. Трекер отвечает ему в стандартном для торрентов bencoded-формате, внутри HTTP-ответа:

15:04:11.819658 IP bt.http > bmw.4378: P 1018458854:1018459110(256) ack 4282925248 win 8760
        0x0000:  4500 0128 5fca 4000 3706 835d 5faa 8b0d  E..(_.@.7..]_...                 
        0x0010:  c3d0 b120 0050 111a 3cb4 72e6 ff48 40c0  .....P..<.r..H@.                 
        0x0020:  5018 2238 c338 0000 4854 5450 2f31 2e31  P."8.8..HTTP/1.1                 
        0x0030:  2032 3030 204f 4b0d 0a53 6572 7665 723a  .200.OK..Server:                 
        0x0040:  206e 6769 6e78 2f30 2e37 2e36 320d 0a44  .nginx/0.7.62..D                 
        0x0050:  6174 653a 2046 7269 2c20 3230 204e 6f76  ate:.Fri,.20.Nov                 
        0x0060:  2032 3030 3920 3039 3a30 333a 3031 2047  .2009.09:03:01.G                 
        0x0070:  4d54 0d0a 436f 6e74 656e 742d 5479 7065  MT..Content-Type                 
        0x0080:  3a20 7465 7874 2f68 746d 6c3b 2063 6861  :.text/html;.cha                 
        0x0090:  7273 6574 3d77 696e 646f 7773 2d31 3235  rset=windows-125                 
        0x00a0:  310d 0a54 7261 6e73 6665 722d 456e 636f  1..Transfer-Enco                 
        0x00b0:  6469 6e67 3a20 6368 756e 6b65 640d 0a43  ding:.chunked..C                 
        0x00c0:  6f6e 6e65 6374 696f 6e3a 2063 6c6f 7365  onnection:.close                 
        0x00d0:  0d0a 0d0a 3439 0d0a 6438 3a69 6e74 6572  ....49..d8:inter                 
        0x00e0:  7661 6c69 3333 3837 6531 323a 6d69 6e20  vali3387e12:min.                 
        0x00f0:  696e 7465 7276 616c 6933 3338 3765 353a  intervali3387e5:                 
        0x0100:  7065 6572 7332 343a c3d0 b120 f7d3 4e8c  peers24:......N.                 
        0x0110:  07c8 ee8e 4df5 a473 9ec7 4e8c 00b2 5fbe  ....M..s..N..._.                 
        0x0120:  650d 0a30 0d0a 0d0a                      e..0....                         

Формат описан в BEP-003, я не буду на нём подробно останавливаться - достаточно выделенных цветом частей. Внутри словаря (dictionary) с валидным ответом обязательно присутствует ключ interval (в секундах) - через какое время клиенту следует повторно запросить список. В общем-то очевидно, что файрвол может использовать его как время истечения срока действия списка - клиенты могли выключиться, например. А вот с ключом peers всё несколько сложнее. По спецификации ему соответствует список словарей (ассоциативных массивов) с данными клиентов. Но этот формат занимает много места, и сейчас используют упакованный, "компактный" формат: просто строка, из кусков по 6 байт, 4 байта на IP и 2 на порт, для каждого адреса. Трекер обычно ограничивает количество пиров, отдаваемых одному клиенту, так что список должен влезать в один пакет (поэтому пересборку tcp-потока с анализом последующих пакетов я делать не стал).
Скрипт тестировался именно на этой "компактной" форме отдаче (такие тут локальные трекеры под рукой), хотя поддержка спецификации тоже присутствует, просто мне не на чем было проверить.
Примечание: один и тот же порт используется как для TCP, так и для UDP (uTP). Поэтому, например, имея такой список, можно просто ограничить срабатывание на UDP, целиком зарезав uTP, и совсем не тронув TCP.

Итак, вот сам скрипт, всё необходимое реализовано вручную, никаких дополнительных модулей сверх штатной поставки Perl 5 он не требует:

#!/usr/bin/perl -w
#
# A BitTorrent HTTP Tracker Response IP/Port pairs catcher.
#
# (c) Vadim Goncharov (nuclight), 2010.
# Covered by standard 3-clause BSD license.
#
# Uses FreeBSD's divert(4) sockets and prints IP/port pairs catched from
# BitTorrent tracker's responses to clients (may be used to shape/firewall).
# Requires no additional Perl modules. Output format is one line per record,
# four fields space-separated:
#
#   host port client_ip expire_time
#
# where host and port are those of remote listening Torrent, client_ip is IP
# of Torrent client getting response from tracker (probably on your local
# network) and expire time is UNIX timestamp until this tuple is still valid.

use strict;
use POSIX;
use IO::Socket;
use IO::Select;

use constant IP_MAXPACKET    => 65535;  # Maximum IP Packet size
use constant IP_VERSION_IPv4 => 4;      # IP version 4
use constant IP_PROTO_TCP    => 6;      # Transmission Control Protocol

my $div_host = '127.0.0.1'; # actually ignored by divert(4), could be any
my $div_port = 6881;
my $sanitize = 0;           # output or not corrected IPs

# setup the divert socket
my $divsock = IO::Socket::INET->new(LocalHost => $div_host,
                                    LocalPort => $div_port,
                                    Type => IO::Socket::SOCK_RAW,
                                    Proto => 'divert')
    or die "Can't create divert socket: $!\n";

# initialize the select object
my $select = new IO::Select($divsock);

sub ip2str($)
{
    my $ip = shift;
    return join('.', unpack("C4", pack("N", $ip)));
}

sub output
{
    my ($ip, $port, $src, $dst, $endtime) = @_;
    my $safeip;

    if (($safeip = $ip) =~ s/[^-A-Za-z0-9_.]//g) {
        print STDERR "INSECURE FROM $src: $ip $port $dst $endtime\n";
    }

    print "$safeip $port $dst $endtime\n" if ($safeip eq $ip) || $sanitize;
}

sub process_tcp_data
{
    my ($pkt, $src, $dst) = @_;

    if ($pkt =~ m/^HTTP\/1.*\r\n\r\n.*d8:intervali(\d+)e/gs) {
        my $interval = $1;
        my $endtime = time + $interval;

        # packed peer list case
        if ($pkt =~ m/\G.*5:peers(\d+):/gs) {
            my $binpeerlen = $1;
            my $start = pos $pkt;

            # check for incorrect/truncated packets
            if ($start + $binpeerlen > length($pkt)) {
                $binpeerlen = length($pkt) - $start;
                $binpeerlen -= $binpeerlen % 6;
            }

            # do actual work - extract IP/port pairs from binary string
            map {
                my ($ip, $port) = unpack("Nn", $_);
                output(ip2str $ip, $port, $src, $dst, $endtime);
            } unpack("(a6)*", substr($pkt, $start, $binpeerlen));
        }

        # bencoded peer list case (BEP-003)
        if ($pkt =~ m/\G.*5:peersl/gs) {
            while ($pkt =~ m/\Gd2:ip(\d+):/gs) {
                my $ip = substr($pkt, pos $pkt, $1);
                pos $pkt += $1;
                if ($pkt =~ m/\G.*?4:porti(\d+)ee/gs) {
                    output($ip, $1, $src, $dst, $endtime);
                }
            }
        }
        # there've been seen 'interval' without 'peers' in the wild,
        # do nothing in this case (e.g. warning from tracker to client)
    }
}

# main loop
while (1) {
    my ($data, $fwtag, $sock);

    # check when one can read
    foreach $sock ($select->can_read) {
        if ($sock == $divsock) {
            # fetch the packet
            $fwtag = recv($sock, $data, IP_MAXPACKET, 0)
                or die "Unable to read packet: $!\n";

            # check that is IPv4 and TCP
            my $hlen = ord($data);   # ver and header length
            if ((($hlen & 0xf0) >> 4) == IP_VERSION_IPv4) {
                $hlen = ($hlen & 0x0f) * 4;
                my ($proto, $src, $dst, $tcphlen) = (unpack("x9Cx2NNx" . ($hlen-20) . "x12Ca*", $data))[0..3];
                if ($proto == IP_PROTO_TCP) {
                    $tcphlen = ($tcphlen & 0xf0) >> 2;

                    # finally get only TCP payload part
                    if (length($data) > $hlen + $tcphlen) {
                        $data = unpack("x" . ($hlen+$tcphlen) . "a*", $data);
                        process_tcp_data($data, ip2str $src, ip2str $dst);
                    }
                }
            }
        }
    }
}

И попробуйте-ка напишите аналог на PHP! :-p

Nota bene: На самом деле скрипт выполняет пассивный анализ данных без модификации пакетов, поэтому используйте правило tee, а не divert - оно передает в сокет копии пакетов, поскольку скрипт ничего не пишет в ядро обратно (оригиналы бы просто дропались, если бы не tee).

Говорят, что для ряда версий линуксового ядра есть патчи, реализующие divert(4). Так что скрипт портабелен и реализован как часть конструктора - он просто выводит на stdout найденные пары и время их "протухания" в формате Unix. Этот вывод можно пайпом отправить во что-то, что будет преобразовывать в правила конкретного файрвола, будь он на этой же машине или же ACL для удаленной Cisco. На самом деле скрипт выводит так же адрес локального клиента (который делал запрос к трекеру) на случай, если он вдруг понадобится для конкретных правил. Следует иметь в виду, что трекер, среди отданных пар адресов, часто может отдавать адреса и Ваших же клиентов (они ведь наверняка участвуют в раздаче). Поэтому учитывайте направления.
Пример строки вывода такой:

1.2.3.4 5678 192.168.199.123 1278453649

Здесь можно ожидать коннектов от Вашего клиента 192.168.199.123 к удаленному 1.2.3.4:5678 в течение промежутка времени до 02:00 07.07.2010 Москвы. Разумеется, к этому адресу и порту скорее всего будут коннектиться и другие клиенты в локальной сети.

Эксперимент со скриптом на живой сети из ~70 активных торрент-пользователей (100Mbit аплинка в полку, ~11kpps), начатый в районе полуночи выходного дня, за час вывел около 20 тысяч уникальных хостов. Интервал трекера составлял примерно 50 минут, через это время первые записи начали протухать, и сначала число записей еще немного росло, потом начало медленно снижаться (наступала ночь).

Вариант скриптов обвязки для FreeBSD

На FreeBSD нет средства, позволяющего эффективно матчить именно пары ip:port, выбор скуден: или линейный список правил, или только адреса в таблице. Однако с большой долей уверенности мы можем предположить, что в torrent-обмене из внешней сети участвуют только машины конечных клиентов, не сервера, а потому мы можем шейпить их целиком, не опасаясь, что какие-то более приоритетные сервисы на тех машинах задавим. Значит, нам достаточно будет вносить только первое поле из четырех в выводе скрипта в саму таблицу, а четвертое, где unixtime, тоже вносить в таблицу аргументом, но не для использования в файрволе, а для скрипта, который будет чистить старые записи.
Итак, добавляем правило в ipfw для отправки на анализ:

ipfw add 6008 tee 6881 tcp from tracker.torrents.site.ru 80 to any

Допустим, правила шейпера будут использовать таблицу 68. Пусть скрипты добавляют хосты в неё:

$ cat torr_ipfw_tbl_add.sh
#!/bin/sh

torrtbl=68
fwt="/sbin/ipfw table"  # DON'T use "-q": will not return error on add

while read ip port dstip endtime; do
        if ! $fwt $torrtbl add $ip $endtime 2>/dev/null; then
                $fwt $torrtbl delete $ip
                $fwt $torrtbl add $ip $endtime
        fi
done

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

$ cat torr_ipfw_tbl_expire.sh
#!/bin/sh

torrtbl=68
fw="/sbin/ipfw"
$awk="/usr/bin/awk"

$fw table $torrtbl list | $fw -p $awk '{ if ($2 < '`date +%s`') {print "table '$torrtbl' delete " $1}}' /dev/stdin

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

(./torrent_tracker_catch.pl | ./torr_ipfw_tbl_add.sh) >error.log 2>&1 &

Вуаля, теперь ipfw table 68 list | wc -l в любой момент времени можно спросить, сколько их там, несчастных в таблице.

Проблемы, итоги

Наблюдение показало, что сам перловый скрипт практически не ест CPU. А вот приведенные выше скрипты добавления для FreeBSD в отдельные моменты форкались эдак на 10-15% загрузки процессора подопытного роутера на P4. Оптимальнее, конечно, был бы вариант скрипта-демона, самостоятельно следящего за таблицами и не дергающего процесс ipfw на каждую строчку, но это уже не вписывается в объем поста и оставляется домашним заданием, ибо ничего сложного для нормального админа в этом нет.

Проблемным местом является определение того, какие же именно пакеты отдавать в скрипт: очевидно, что весь HTTP - это чересчур много. Надо знать адреса трекеров, но не все они могут быть заранне известны. Выходом может служить детектирование в ядре сигнатуры "\nd8:intervali" (см. выше пример дампа) и отправка в divert-сокет только подпавших под неё пакетов.
К сожалению, во FreeBSD в настоящее время нет штатных средств для поиска подстроки в пакете. Если этот аспект производительности составляет проблему, можно соорудить костыль из 4 программ для ng_bpf для поиска четырех байтов "\nd8:i" последовательным перебором; так можно покрыть около 1000 первых байт пакета.

Однако я надеюсь, что это не понадобится - ни в ближайшее время, ни вообще. В общем-то, сей пост есть превентивный шаг: если разработчики не пойдут на сотрудничество с провайдерами - выше был пример инициативы с DNS, отказали, ну не идиотизм ли. Держателям трекеров (хотя на Западе, кстати, некоторые трекеры сами банят тех, кто с uTP) сейчас ответить нечего - попытка ввести шифрование приведет к сильному возрастанию на них нагрузки, которая и так не маленькая (это ж не оконечный клиент). Там тоже, кстати, идиотизм реализации - трекером обычно служит скрипт на PHP в составе процесса Апача, overhead по использованию ресурсов и требованию к железу дикий. Такое впечатление по количеству идиотизмов, что в их среде много где с головы гниёт... впрочем, об этом сказано уже достаточно.

Источник: http://nuclight.livejournal.com/125747.html
Категория: Net | Добавил: oleg (16.07.2010) | Автор: Vadim Goncharov (nuclight)
Просмотров: 1024 | Рейтинг: 0.0/0 |
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Форма входа

Beastie

Друзья сайта

Copyright MyCorp © 2025