Jump to content
Калькуляторы

Приоритезация 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?

Edited by hiller

Share this post


Link to post
Share on other sites

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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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

 

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

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

Share this post


Link to post
Share on other sites
Пилите Шура, пилите!

 

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

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

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

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

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

+1

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

Share this post


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

 

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

Share this post


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

 

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

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

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

 

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

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

 

 

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

 

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

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

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

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

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

+1

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

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

Edited by hiller

Share this post


Link to post
Share on other sites

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

 

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

Share this post


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

 

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

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

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

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

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

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

 

 

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

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

 

 

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

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

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

Share this post


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

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

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

Share this post


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

 

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

+1

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

 

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

 

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

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

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

Share this post


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

 

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

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

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

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

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

Share this post


Link to post
Share on other sites
Вы так докрутитесь до жалоб в связь надзор, за хреновое качество.
Кол-во соединений/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 соединениями к прмиеру?

Share this post


Link to post
Share on other sites

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

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

NiTr0

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

 

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

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

Share this post


Link to post
Share on other sites

Вот рабочее и самое не ресурсоемкое (ИМХО) на данный момент решение, предварительно необходимо разрешить трафик игровых, 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 сессий.

 

Share this post


Link to post
Share on other sites
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'у.

Edited by hiller

Share this post


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

 

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

 

 

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

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

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

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

 

 

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

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

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

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

Share this post


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

 

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

 

 

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this