Перейти к содержимому
Калькуляторы

Приоритезация BitTorrent на базе OpenDPI в Linux

На http://opendpi.org недавно анонсировали wrapper, позволяющий использовать возможности OpenDPI с iptables.

Поставил, скомпилил, вроде работает, но как-то не полноценно.

 

Задача была понизить приоритет всему BitTorrent трафику, в определенное время (bussiness hours).

Попробовали, результат - так себе. Для теста решили дропнуть весь BitTorrent в это время.

Что-то дропнулось, к примеру к трекерам клиенты коннектиться перестали. А вот существующие закачки так и продолжали грузиться.

 

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

Автор патча говорит, что у него были следующие результаты:

 

Running the vanilla OpenDPI demo on a pcap file created by downloading 5%

of a Ubuntu ISO with rTorrent shows 4054 unknown packets. After patching

and recompiling, there are only 154 unknown packets and 3907 packets were

recognized as BitTorrent traffic.

Подобные тесты еще не проводил, видимо в выходные займусь.

 

Собственно вопрос: описываемый патч от 09-10-2009, неужели за год BitTorrent так сильно мутировал, что практически перестал определяться?

Может навалимся на эту задачу, пофиксим OpenDPI?

Изменено пользователем hiller

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пилите Шура, пилите!

 

Торренты блочить и сложно и просто одновременно.

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

Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт...

по достижение пороговых значений блочить этот порт клиента или что то ещё делать.

Без статы и пороговых значений - получите ложные срабатывания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Поубивал бы таких админов...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пилите Шура, пилите!

 

Торренты блочить и сложно и просто одновременно.

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

Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт...

по достижение пороговых значений блочить этот порт клиента или что то ещё делать.

Без статы и пороговых значений - получите ложные срабатывания.

+1

p2p/bittorrent можно детектить только по поведенческому характеру. Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатур

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поубивал бы таких админов...
Если данное "разграничение" пользуется не для рубки на корню, а для поднятия приоритета отдельных классов траффика (игровой, http, udp при зарубленом uTP и т.д.) - оно вполне оправдано, "малой кровью" получаем в час пик и довольных пользователей "высокоприоритетных" сервисов, и довольных торрентоводов. Естессно, для блокировки такое не подходит никак.

 

А по поводу "правильного блокировщика" - тут или резать запросы к анонс урл на л7 (если надо целиком забить торренты), или собирать статистику по хостам и людей с большим ппс/большим кол-вом соединений заворачивать целиком в низкоприоритетный класс, а когда "одумаются" (ппс упадет/соединения поотваливаются) - возвращать в основной класс обратно (если надо "прикрутить"). А src port для соединения на другой хост (типичный download), если не ошибаюсь, будет как раз таки рандомным...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Поубивал бы таких админов...

Может лучше разработчиков торрента?

 

Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений? С каждой новой версией шлет пакеты все меньшего размера (utp)? Если бы нормально идентифицировался, проблем бы не было.

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

 

 

Пилите Шура, пилите!

 

Торренты блочить и сложно и просто одновременно.

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

Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт...

по достижение пороговых значений блочить этот порт клиента или что то ещё делать.

Без статы и пороговых значений - получите ложные срабатывания.

+1

p2p/bittorrent можно детектить только по поведенческому характеру. Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатур

А как это делается на Cisco SCE?

 

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Крайне жестокая мера. Кстати, а как в исключения добавить скайп? ;)

 

Пилите Шура, пилите!

 

Торренты блочить и сложно и просто одновременно.

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

Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт...

по достижение пороговых значений блочить этот порт клиента или что то ещё делать.

Без статы и пороговых значений - получите ложные срабатывания.

Можно на retracker.local собирать информацию о портах клиентов и блочить их.

Изменено пользователем hiller

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

>Можно на retracker.local собирать информацию о портах клиентов и блочить их.

 

А что Вы там соберёте-то? Только порт для входящих соединений, сколько-то трафика можно будет классифицировать, но utp-шный трафик так не поймаешь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатур
Сигнатуры не меняются а добавляются, но сигнатуры не чёткие, под ниж подпадают иногда пакеты от других приложений, для uTP (udp) это так.

 

А по поводу "правильного блокировщика" - тут или резать запросы к анонс урл на л7 (если надо целиком забить торренты), или собирать статистику по хостам и людей с большим ппс/большим кол-вом соединений заворачивать целиком в низкоприоритетный класс, а когда "одумаются" (ппс упадет/соединения поотваливаются) - возвращать в основной класс обратно (если надо "прикрутить"). А src port для соединения на другой хост (типичный download), если не ошибаюсь, будет как раз таки рандомным...
Это не поможет с DTH.

В хттп не нужно резать всё, достаточно кое что из заголовков, я как то дома доигрался с анонимайзером в сквиде :)

Полагаю, накручивальщики рейтинга так и генерят фиктивный аплоад от клиента для статистики на трекере.

Вы так докрутитесь до жалоб в связь надзор, за хреновое качество.

src порт от клиента - как правило один или по колличеству людей за натом, ни uTorrent, rTorrent вроде не умеют рандомизацию своего порта, да и бессмысленно это, ибо как к ним тогда цепляться?

В rTorrent вроде диапазон портов для входящих соединений можно указать, но не рандомизацию. Скорее всего он будет каруселить (перебирать номера) по ним.

 

 

Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений?
Вас не спросили.

Вам платят, - ваше дело труба.

 

 

Можно на retracker.local собирать информацию о портах клиентов и блочить их.
Такие клиенты дураки.

Быстро пропишут в хостс его или в фаер и халява кончится не начавшись.

Некоторые популярные трекеры клали с прибором на ретракеры.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений? С каждой новой версией шлет пакеты все меньшего размера (utp)? Если бы нормально идентифицировался, проблем бы не было.

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

Изначально BitTorrent работал на одном TCP-порту и не шифровался. Угадайте, почему поведение изменилось?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

+1

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

 

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Поубивал бы таких админов...

А я магистралов, которые шкуродерством занимаются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent.

 

По факту жалоб добавляем в исключения то что пропустили.

Поубивал бы таких админов...

А я магистралов, которые шкуродерством занимаются.

Не фиг жить "в заповедниках".

Это всегда дорого.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы так докрутитесь до жалоб в связь надзор, за хреновое качество.
Кол-во соединений/pps - ИМХО единственный надежный критерий выявления торрентоводов, ложное срабатывание возможно только при наличии пачки зловредов либо спамогенератора. А то, что у качка упадет скорость не только в торренте, но и в других программах, работающих параллельно с торрентом - собссно не есть большая проблема, т.к. торрент обычно канал хорошо засирает.

 

src порт от клиента - как правило один или по колличеству людей за натом, ни uTorrent, rTorrent вроде не умеют рандомизацию своего порта, да и бессмысленно это, ибо как к ним тогда цепляться?
На src порт исходящего соединения никто и не цепляется. И порт этот зачастую выбирается рандомно, а даже если и последовательно - ничем это не поможет делу.

 

В rTorrent вроде диапазон портов для входящих соединений можно указать, но не рандомизацию. Скорее всего он будет каруселить (перебирать номера) по ним.
rtorrent+rutorrent гуй, настройки особо не копал, практически дефолтные:

# netstat -n -p|grep rtorrent
tcp        0      1 91.202.133.76:52597     178.71.219.253:26542    SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:49168     188.123.237.106:33815   SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:35482     109.226.69.149:54787    SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:58743     188.130.204.33:16319    SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:37395     95.24.89.33:60996       SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:48570     78.62.86.241:10348      SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:49265     109.205.252.39:46802    SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:56445     78.37.246.97:54912      SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:43688     92.243.181.166:24261    SYN_SENT    8035/rtorrent
tcp        0  25612 91.202.133.76:56370     91.76.82.206:52550      ESTABLISHED 8035/rtorrent
tcp        0      1 91.202.133.76:35983     89.169.73.215:60745     SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:36216     109.188.198.6:17758     SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:33515     95.55.62.57:46110       SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:53087     87.239.27.141:46672     SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:55366     95.26.125.206:52847     SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:34154     77.87.33.219:34136      SYN_SENT    8035/rtorrent
tcp        0      1 91.202.133.76:33090     94.232.14.32:30001      SYN_SENT    8035/rtorrent
tcp        0  66640 91.202.133.76:31031     79.172.15.237:54656     ESTABLISHED 8035/rtorrent

 

Как приоритезировать-то будете такой "зоопарк"? :) И сколько ресурсов потребуется на одного качка с 400 соединениями к прмиеру?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.

как правило надежный путь это количество конектов на любой порт выше 1024.

NiTr0

ваш пример это просто опросник торента. когда начнется кач будет много срц одинакового порта.

 

тоесть вариант КАК определить торент - это много исходящих/входящих соеднинений на исходящий порт клиента. так как торенту на до же на какой то порт принимать и слушать.

вот только непонятно как эти порты запоминать и блочить. тоесть аддресс-лист есть. а что то вроде аддресс-лист-порт нету.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот рабочее и самое не ресурсоемкое (ИМХО) на данный момент решение, предварительно необходимо разрешить трафик игровых, mail агентов и пр пр пр.

 

-A FORWARD -p udp --dport 1024:65535 -m state --state NEW -m recent --set --name UDPFLOOD --rsource
-A FORWARD -p udp --dport 1024:65535  -m state --state NEW -m recent --update --seconds 5 --hitcount 10 --name UDPFLOOD --rsource -j DROP

-A FORWARD -p tcp --dport 1024:65535 -m state --state NEW -m recent --set --name TCPFLOOD --rsource
-A FORWARD -p tcp --dport 1024:65535  -m state --state NEW -m recent --update --seconds 5 --hitcount 10 --name TCPFLOOD --rsou
rce -j DROP

 

После применения внешний трафик остался тем же, он снизилась нагрузка на систему за счет 5 кратного уменьшения количества conntrack сессий.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.

как правило надежный путь это количество конектов на любой порт выше 1024.

NiTr0

ваш пример это просто опросник торента. когда начнется кач будет много срц одинакового порта.

 

тоесть вариант КАК определить торент - это много исходящих/входящих соеднинений на исходящий порт клиента. так как торенту на до же на какой то порт принимать и слушать.

вот только непонятно как эти порты запоминать и блочить. тоесть аддресс-лист есть. а что то вроде аддресс-лист-порт нету.

Есть conntrack, в нем есть список портов.

 

Вот командочка, с помощью которой можно посмотреть на какие порты, сколько коннектов для определенного IP. Самое большое кол-во, как правило - torrent.

Блокируем этот порт и пользователь резко перестает качать. Надо понимать, что порт может через какое-то время поменяться (стоит рандомизация порта при каждом запуске).

 

conntrack -L | grep $user_ip | grep tcp | awk '{print $7}' | sort | uniq -c
conntrack -L | grep $user_ip | grep udp | awk '{print $7}' | sort | uniq -c

 

Чтобы блокировка работала со 100% точностью, ломимся по http на подозрительный порт и убеждаемся, что это точно торрент. Надо почитать спецификацию торрента, чтобы делать правильный http-запрос, который присущ только torrent'у.

Изменено пользователем hiller

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Как приоритезировать-то будете такой "зоопарк"? :) И сколько ресурсов потребуется на одного качка с 400 соединениями к прмиеру?
Не сильно больше, чем требуется для НАТа.

 

 

400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.
И?

Реально от этого КПД только падает.

Есть некоторая корреляция по колличеству соединений на мегабит: меньше - полоса как правило не догружена до полки, больше - полоса в полку, но полезного трафика меньше, тк много ip/tcp служебок бегает.

Но лимит ХР это слишком мало для мегабитных тарифов.

 

 

Чтобы блокировка работала со 100% точностью, ломимся по http на подозрительный порт и убеждаемся, что это точно торрент. Надо почитать спецификацию торрента, чтобы делать правильный http-запрос, который присущ только torrent'у.
Вы так уже делали?))))))

Так то торент бинарный, и только с трекерами он по хттп общаться может, а может по юдп.

Ну повешаю я на 443, 3389, pptp (номер не помню), включу крипту.

На глазок отличите шифрованный торрент от хттпс сайта или впн игрового хаба?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Как приоритезировать-то будете такой "зоопарк"? :) И сколько ресурсов потребуется на одного качка с 400 соединениями к прмиеру?
Не сильно больше, чем требуется для НАТа.

 

 

400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.
И?

Реально от этого КПД только падает.

Есть некоторая корреляция по колличеству соединений на мегабит: меньше - полоса как правило не догружена до полки, больше - полоса в полку, но полезного трафика меньше, тк много ip/tcp служебок бегает.

Но лимит ХР это слишком мало для мегабитных тарифов.

 

 

Чтобы блокировка работала со 100% точностью, ломимся по http на подозрительный порт и убеждаемся, что это точно торрент. Надо почитать спецификацию торрента, чтобы делать правильный http-запрос, который присущ только torrent'у.
Вы так уже делали?))))))

Так то торент бинарный, и только с трекерами он по хттп общаться может, а может по юдп.

Ну повешаю я на 443, 3389, pptp (номер не помню), включу крипту.

На глазок отличите шифрованный торрент от хттпс сайта или впн игрового хаба?

1. Надо в договоре предусматривать такие моменты.

2. Нат + качки = НАТ*2? А зачем, если можно просто НАТ?

3. Лимита XP хватает, чтобы таскать файлы по любым протоколам на любых скоростях. Если считаете, что не достаточно, то это результат перегрузки на вашем провайдере или выше.

4. Хрен на бинарность торрента. Можно не хттп, а бинарный запрос делать. Наша задача убедиться, что этот порт открыт именно торрентом.

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

А найдем мы его по дикому количеству соединений с этим портом на разные адреса. Другие сервисы так себя не ведут.

 

Так что можно классифицировать этот трафик без сверхестественных DPI (читай лишних нагрузок). Провел несколько тестов. Работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.