[netj]

Это все хорошо и красиво, но они сами свои бепы не соблюдают к сожалению.

Да и клиенты ветки 1.8 отличаются реализацией uTP

Пример несоблюдения видел, например 0x61 в байте полей version/type. Но как это влияет на отлавливание установления соединений, если преимущественно для этого большинство должно говорить на одном языке?

Можете привести другие несоответствия?

 

Если отличаются по части установления соединения, то каким образом они это могут делать так, чтобы принимать uTP соединения от версий, начиная с 1.8?

Взял версию 1.8.4 и документацию к ней.

В ней тот же пункт опций, что и в документации к 2.0.1, но ничего нет про управление разрмером пакета:

1 allows µTorrent to attempt outgoing TCP connections

2 allows µTorrent to attempt outgoing uTP connections

4 allows µTorrent to accept incoming TCP connections

8 allows µTorrent to accept incoming uTP connections

16 tells µTorrent to use the new uTP header. This is an improved communication header, but is not backwards compatible with clients that do not understand it.

В настройках поставил 31.

Взял выражение для tcpdump - и поймал кучу пакетов. Для версии 1.8.4 работает. Если есть где 1.8, могу попробовать протестить с ней.

Кстати, версий до 1.8 сейчас не так уж и много, а проблема pps обозначилась намного позже, чем вышла версия 1.8.4.

Т.е. как-бы при чём тут версии, которые реализуют uTP по-другому, если они были и раньше, сейчас их меньше основной массы, и раньше проблемы pps не было?

Изменено 14 мая, 2010 пользователем netj

[XeonVs]

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

[zkvomsk]

Возможно кто-нибудь поможет, есть проблема с циской 7206VXR (NPE-G2) ios adventerprisek9-mz.124-11.T3

конструкция фактически такая же как было в теме выше

 

class-map type access-control match-any No_Torrent

match start l3-start offset 40 size 5 regex "\x7F\xFF\xFF\xFF\xAB"

policy-map type access-control No_Torrent_PM

class No_Torrent

drop

interface GigabitEthernet0/1

service-policy type access-control input No_Torrent_PM

 

но по show policy-map.... счетчики нулевые, хотя пакеты под этот фильтр на интерфейсе точно есть и на фревом серваке висящем на Gig0/1 они прекрасно ловятся tcpdump-ом. Может кто знает куда копать?

[BETEPAH]

Подскажите финальный вариант со всеми 3 сигнатурами. Спасибо!

как-то так:

$ipt -I FORWARD 1 -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 2 -m udp -p udp -m string --hex-string "|7F FF FF FF 00 03|" --algo kmp --from 36 --to 41 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

[Lynx10]

или так

iptables -I FORWARD 1 -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statistic --mod

iptables -I FORWARD 1 -m udp -p udp -m string --hex-string "|7F FF FF FF 00 03 20 00|" --algo kmp --from 36 --to 43 -m statis

iptables -I FORWARD 1 -m udp -p udp -m string --hex-string "|00 38 00 00 00 01 00 00|" --algo kmp --from 40 --to 47 -m statis

 

?

[gab]

А если без флуда и "подпеванию троллям"?

По теме кто-нибудь определенно может сказать о появлении новой сигнатуры от uTorrent-вредителей? Или все-таки последние события никак не связаны с этим?

фильтруем так (за пару часов набежало):

  12M  697M REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp STRING match "|0000000000380000|" ALGO name kmp FROM 36 TO 43 reject-with icmp-port-unreachable
3811K  228M REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp STRING match "|7fffffffab|" ALGO name kmp FROM 40 TO 44 reject-with icmp-port-unreachable
1319K   66M REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp STRING match "|7fffffff0003|" ALGO  name kmp FROM 36 TO 41 reject-with icmp-port-unreachable

Для IPFW ng_bpf подскажите.

[XeonVs]

А если без флуда и "подпеванию троллям"?

По теме кто-нибудь определенно может сказать о появлении новой сигнатуры от uTorrent-вредителей? Или все-таки последние события никак не связаны с этим?

фильтруем так (за пару часов набежало):

Для IPFW ng_bpf подскажите.

А почитать тему слабо?

 bpf_prog_len=24 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=20 k=64 } { code=32 jt=0 jf=0 k=40 } { code=21 jt=0 jf=2 k=2147483647 } { code=48 jt=0 jf=0 k=44 } { code=21 jt=15 jf=0 k=171 } { code=32 jt=0 jf=0 k=36 } { code=21 jt=0 jf=2 k=2147483647 } { code=32 jt=0 jf=0 k=40 } { code=21 jt=11 jf=3 k=204800 } { code=21 jt=0 jf=2 k=0 } { code=32 jt=0 jf=0 k=40 } { code=21 jt=8 jf=0 k=3670016 } { code=48 jt=0 jf=0 k=26 } { code=21 jt=0 jf=7 k=31 } { code=48 jt=0 jf=0 k=36 } { code=21 jt=0 jf=5 k=0 } { code=48 jt=0 jf=0 k=45 } { code=21 jt=0 jf=3 k=0 } { code=40 jt=0 jf=0 k=46 } { code=21 jt=0 jf=1 k=514 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ]

Изменено 17 мая, 2010 пользователем XeonVs

[Lynx10]

нда сколько людей столько идей

[_INF_]

$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP

$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

Это блокирует много нужного игрового UDP типа CSS CoD Broodwar и пр. к некоторым игровым просто нельзя приконнектиться, к другим же можно, но войти в созданную игру нельзя.

 

 

[marikoda]

$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP

$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

Это блокирует много нужного игрового UDP типа CSS CoD Broodwar и пр. к некоторым игровым просто нельзя приконнектиться, к другим же можно, но войти в созданную игру нельзя.

т.е. надо исключить игровые порты?

[_INF_]

$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP

$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

Это блокирует много нужного игрового UDP типа CSS CoD Broodwar и пр. к некоторым игровым просто нельзя приконнектиться, к другим же можно, но войти в созданную игру нельзя.

т.е. надо исключить игровые порты?

надо просто матчить так

$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 00 00 00 00 38 00 00|" --algo kmp --from 36 --to 43 -m statistic --mode random --probability 0.95 -j DROP

 

хотя тоже не исключаю , что часть сервисов отвалится.

 

[BETEPAH]

да, наверное так правильнее будет

[tim716]

Тут

http://forum.utorrent.com/viewtopic.php?id=76254

я создал темку по мотивам этой ветки, там спрашивают подробности которых я не знаю, кто знает инглиш - пообщайтесь, объясните что нужно сделать чтоб всем было счастье, может и услышат глас в пустыне. Бессмысленная "война" думаю никому не нужна.

[hiller]

Зафильтровать клиент uTorrent и все дела. Никакой войны не будет.

Изменено 19 мая, 2010 пользователем hiller

[marikoda]

Зафильтровать клиент uTorrent и все дела. Никакой войны не будет.

Как зафильтровать то?

[maxxxxu]

Подскажите финальный вариант со всеми 3 сигнатурами. Спасибо!

как-то так:

$ipt -I FORWARD 1 -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 2 -m udp -p udp -m string --hex-string "|7F FF FF FF 00 03|" --algo kmp --from 36 --to 41 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

в этот фильтр попадает Call of Duty 4 Modern Warfare 2

[AlKov]

как-то так:

$ipt -I FORWARD 1 -m udp -p udp -m string --hex-string "|7F FF FF FF AB|" --algo kmp --from 40 --to 44 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 2 -m udp -p udp -m string --hex-string "|7F FF FF FF 00 03|" --algo kmp --from 36 --to 41 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 3 -m udp -p udp -m string --hex-string "|00 38 00 00|" --algo kmp --from 40 --to 43 -m statistic --mode random --probability 0.95 -j DROP
$ipt -I FORWARD 4 -m udp -p udp -m string --hex-string "|00 00 00 00|" --algo kmp --from 36 --to 40 -m statistic --mode random --probability 0.95 -j DROP

в этот фильтр попадает Call of Duty 4 Modern Warfare 2

Вот-вот.. Именно эта мысль (режем что-то не то) у меня и была с самого начала применения последней сигнатуры.. Что-то уж очень много пакетов в нее попадает. Правда все пакеты как один, по 30 байт, но..

Что примечательно, жалоб пока нет. Может конечно, мало игроков в эти игрушки у нас.

Изменено 19 мая, 2010 пользователем AlKov

[Ivan_83]

Зафильтровать клиент uTorrent и все дела. Никакой войны не будет.

Вы проиграете войну с торрентами после первой схватки, я вам гарантирую.

Создателям протокола ну совсем ничего не стоит сделать чтобы к примеру генерился рандомный одноразовый ключ к каждому пакету, путь даже 4-8 байт, и дальше весь пакет им шифровался, пусть даже очень тупо по XOR.

После этого никаких постоянных сигнатур вы не увидите.

4 байта - это более 4 миллиардов комбинаций - если ставить сигнатурный отлов :)

После такой тривиальнейшей операции вам потребуется обрабатывать все пакеты целиком.

А разработчики могут заюзать RC4 или вовсе AES - им пофик, не им платить за вычислительные мощности.

Потом они тоже самое сделают с TCP.

Потом они спрячут заголовки в http во что нибудь стандартное или в данные для post и тоже шифранут.

 

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

[marikoda]

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

Уже сейчас приходится покупать, чтобы переварить трафик.

Но не у всех есть возможность покупать редбеки и жуниперы.

 

Хотя, в свете объединения связьинвестовских контор, альтернативным операторам пора думать о смене профиля. :)

Говорят, сейчас в моде небольшие сети кафешек. :)

[hiller]

Зафильтровать клиент uTorrent и все дела. Никакой войны не будет.

Вы проиграете войну с торрентами после первой схватки, я вам гарантирую.

Создателям протокола ну совсем ничего не стоит сделать чтобы к примеру генерился рандомный одноразовый ключ к каждому пакету, путь даже 4-8 байт, и дальше весь пакет им шифровался, пусть даже очень тупо по XOR.

После этого никаких постоянных сигнатур вы не увидите.

4 байта - это более 4 миллиардов комбинаций - если ставить сигнатурный отлов :)

После такой тривиальнейшей операции вам потребуется обрабатывать все пакеты целиком.

А разработчики могут заюзать RC4 или вовсе AES - им пофик, не им платить за вычислительные мощности.

Потом они тоже самое сделают с TCP.

Потом они спрячут заголовки в http во что нибудь стандартное или в данные для post и тоже шифранут.

 

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

Да любую хрень при желании можно отфильтровать. И нужно это делать. Если не получится технически, применять юридические инструменты.

 

ps Иван, как я понимаю, Вы пользователь, зачем Вы здесь? Пугать нас супер-возможностями программеров из команды uTorrent?

 

[AlKov]

...Потом они тоже самое сделают с TCP.

Потом они спрячут заголовки в http во что нибудь стандартное или в данные для post и тоже шифранут.

[offtop]

А потом они... А еще они... И... в итоге Нюрнбергский Процесс.. :D

 

И по теме: кто-либо может сказать однозначно - сигнатура "ip[40:4]=0x00380000 and ip[44:4]=0x00010000" точно режет геймеров, или все же только "любимый" uTP?

Очень бы не хотелось геймеров наказывать ни за что..

 

Изменено 19 мая, 2010 пользователем AlKov

[Negator]

Да любую хрень при желании можно отфильтровать. И нужно это делать. Если не получится технически, применять юридические инструменты.

 

ps Иван, как я понимаю, Вы пользователь, зачем Вы здесь? Пугать нас супер-возможностями программеров из команды uTorrent?

Да не пользователь он. Но дело не в этом. Прав он -резать это не метод это полумеры.

Скоро будет сотня новых версий торрента и что? резать все? обновились не все что то одно резать не получится.

Разработчики видимо пошли по пути увеличения кол-ва пакетов и сходить с него не собираются. А увидят что их режут - найдут как зашифровать.

Нужно решать проблемы торрентов другими путями, правда пока не знаю какими -время покажет.

[T_Igor]

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

____________________________________________________

Евросоюз оштрафовал Samsung и других участников сговора на 331 миллион евро

 

Как и ожидалось, сегодня официально опубликовано решение регулирующего органа Евросоюза наложить штраф на Samsung Electronics и других производителей памяти.

 

Общая сумма штрафа, который предстоит выплатить компаниям, уличенным в сговоре с целью фиксации цен, составляет 331 млн. евро. Как удалось выяснить следствию, картельное соглашение действовало с июля 1998 года по июнь 2002 года.

 

Максимальному наказанию подверглась компания Samsung — 145,73 млн. евро. Вину Infineon, по мнению регуляторов, способна искупить сумма в размере 56,70 млн. евро. Участие Hynix Semiconductor в незаконной деятельности обойдется компании в 51,47 млн. евро.

 

Другие фигуранты заплатят меньше: Hitachi — 20,41 млн. евро, Toshiba — 17,64 млн .евро, Mitsubishi Electric — 16,61 млн. евро, Nanya Technology — 1,80 млн.

 

Компаниям NEC, Hitachi и Elpida Memory вместе предстоит заплатить 8,50 млн. евро. Кроме того, 2,12 млн. евро компания NEC заплатит совместно с Hitachi и еще 20,41 млн. евро — самостоятельно.

 

Единственным из десяти ранее названных производителей, кто избежал штрафа, стала компания Micron Technology, в 2002 году раскрывшая информацию о существовании сговора.

________________________________________________________________________________

________________________________

Вот так бывает!

Изменено 19 мая, 2010 пользователем T_Igor

[netj]

Господа zkvomsk, BETEPAH, Lynx10, gab, _INF_, AlKov, вы разобрались в назначении полей протокола uTP и их применении для обнаружения пакетов с данными uTP, что показывается для всех только при помощи tcpdump, а затем каждый сам переведёт в соответствующую запись для собственного фильтра, что описано в моём коменте ранее?

1. Всё ещё продолжают писать положение полей относительно ip. Если размер заголовка будет не 20, а 24 байта, выражение будет адресоваться не к тем данным. Поэтому адресация должна быть только относительно udp для uTP.

2. В коменте наглядно показано, почему шаблоны "7F FF FF FF 00 03" и "00 38 00 00" бессмысленны и что означают.

3. В коменте чётко показано, что фильтровать и фильтровать ли, и к чему будет приводить фильтрация - есть случай, когда она может привести к обратному эффекту.

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

Изменено 24 мая, 2010 пользователем netj

[AlKov]

Господа .... AlKov, вы разобрались в назначении полей протокола uTP и их применении для обнаружения пакетов с данными uTP...

Я лично нет. Недостаточно знаний и времени для их получения в нужном объёме, к сожалению.. :( Тупо копировал и проверял "на живых людях"..

Ваши предложения по проблеме? Это (выделено)

Итого, очень хотелось бы, чтобы с одной стороны пользователи отключили динамическое управление размером пакетов, задав net.utp_initial_packet_size=8, а админы в ответ на это и в обмен на приведённую инфу по распознаванию пакетов не резали наобум, и вообще, не резали, но тормозили эти пакеты до приемлемой для обеих сторон скорости, что должно приводить к паузам между последовательностями передач пакетов ST_DATA.

ИМХО, нереально. Т.к. адекватных юзеров и юзеров, которые читают объявления, или местный форум и следуют рекомендациям админов, очень мало...