hiller Опубликовано 14 декабря, 2010 (изменено) · Жалоба На 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? Изменено 14 декабря, 2010 пользователем hiller Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 14 декабря, 2010 · Жалоба Пилите Шура, пилите! Торренты блочить и сложно и просто одновременно. Сложно - потому что готовых решений не особо или сами так себе, а легко потому что торрент не очень то и прячется, и порты не лету не рандомизирует. Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт... по достижение пороговых значений блочить этот порт клиента или что то ещё делать. Без статы и пороговых значений - получите ложные срабатывания. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 14 декабря, 2010 · Жалоба Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 14 декабря, 2010 · Жалоба Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Поубивал бы таких админов... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shicoy Опубликовано 15 декабря, 2010 · Жалоба Пилите Шура, пилите! Торренты блочить и сложно и просто одновременно. Сложно - потому что готовых решений не особо или сами так себе, а легко потому что торрент не очень то и прячется, и порты не лету не рандомизирует. Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт... по достижение пороговых значений блочить этот порт клиента или что то ещё делать. Без статы и пороговых значений - получите ложные срабатывания. +1p2p/bittorrent можно детектить только по поведенческому характеру. Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатур Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 декабря, 2010 · Жалоба Поубивал бы таких админов...Если данное "разграничение" пользуется не для рубки на корню, а для поднятия приоритета отдельных классов траффика (игровой, http, udp при зарубленом uTP и т.д.) - оно вполне оправдано, "малой кровью" получаем в час пик и довольных пользователей "высокоприоритетных" сервисов, и довольных торрентоводов. Естессно, для блокировки такое не подходит никак. А по поводу "правильного блокировщика" - тут или резать запросы к анонс урл на л7 (если надо целиком забить торренты), или собирать статистику по хостам и людей с большим ппс/большим кол-вом соединений заворачивать целиком в низкоприоритетный класс, а когда "одумаются" (ппс упадет/соединения поотваливаются) - возвращать в основной класс обратно (если надо "прикрутить"). А src port для соединения на другой хост (типичный download), если не ошибаюсь, будет как раз таки рандомным... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 15 декабря, 2010 (изменено) · Жалоба Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Поубивал бы таких админов... Может лучше разработчиков торрента? Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений? С каждой новой версией шлет пакеты все меньшего размера (utp)? Если бы нормально идентифицировался, проблем бы не было. Ну да, приоритет ему ставили бы более низкий, но конечные юзеры не страдали бы от ложных срабатываний всяческих фильтров. Пилите Шура, пилите! Торренты блочить и сложно и просто одновременно. Сложно - потому что готовых решений не особо или сами так себе, а легко потому что торрент не очень то и прячется, и порты не лету не рандомизирует. Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт... по достижение пороговых значений блочить этот порт клиента или что то ещё делать. Без статы и пороговых значений - получите ложные срабатывания. +1p2p/bittorrent можно детектить только по поведенческому характеру. Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатур А как это делается на Cisco SCE? Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Крайне жестокая мера. Кстати, а как в исключения добавить скайп? ;) Пилите Шура, пилите! Торренты блочить и сложно и просто одновременно. Сложно - потому что готовых решений не особо или сами так себе, а легко потому что торрент не очень то и прячется, и порты не лету не рандомизирует. Правильный блокиратор должен собирать стату по каждому своему ИП (в смысле которые изнутри сети), и складывать в табличку по src порт... по достижение пороговых значений блочить этот порт клиента или что то ещё делать. Без статы и пороговых значений - получите ложные срабатывания. Можно на retracker.local собирать информацию о портах клиентов и блочить их. Изменено 15 декабря, 2010 пользователем hiller Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 декабря, 2010 · Жалоба >Можно на retracker.local собирать информацию о портах клиентов и блочить их. А что Вы там соберёте-то? Только порт для входящих соединений, сколько-то трафика можно будет классифицировать, но utp-шный трафик так не поймаешь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 15 декабря, 2010 · Жалоба Анализ по сигнатуре эффекта заметного не дает, по причине периодически меняющихся сигнатурСигнатуры не меняются а добавляются, но сигнатуры не чёткие, под ниж подпадают иногда пакеты от других приложений, для uTP (udp) это так. А по поводу "правильного блокировщика" - тут или резать запросы к анонс урл на л7 (если надо целиком забить торренты), или собирать статистику по хостам и людей с большим ппс/большим кол-вом соединений заворачивать целиком в низкоприоритетный класс, а когда "одумаются" (ппс упадет/соединения поотваливаются) - возвращать в основной класс обратно (если надо "прикрутить"). А src port для соединения на другой хост (типичный download), если не ошибаюсь, будет как раз таки рандомным...Это не поможет с DTH.В хттп не нужно резать всё, достаточно кое что из заголовков, я как то дома доигрался с анонимайзером в сквиде :) Полагаю, накручивальщики рейтинга так и генерят фиктивный аплоад от клиента для статистики на трекере. Вы так докрутитесь до жалоб в связь надзор, за хреновое качество. src порт от клиента - как правило один или по колличеству людей за натом, ни uTorrent, rTorrent вроде не умеют рандомизацию своего порта, да и бессмысленно это, ибо как к ним тогда цепляться? В rTorrent вроде диапазон портов для входящих соединений можно указать, но не рандомизацию. Скорее всего он будет каруселить (перебирать номера) по ним. Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений?Вас не спросили.Вам платят, - ваше дело труба. Можно на retracker.local собирать информацию о портах клиентов и блочить их.Такие клиенты дураки.Быстро пропишут в хостс его или в фаер и халява кончится не начавшись. Некоторые популярные трекеры клали с прибором на ретракеры. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 15 декабря, 2010 · Жалоба Нахрена нужен такой протокол, который сложно идентифицируется и создает огромное кол-во соединений? С каждой новой версией шлет пакеты все меньшего размера (utp)? Если бы нормально идентифицировался, проблем бы не было.Ну да, приоритет ему ставили бы более низкий, но конечные юзеры не страдали бы от ложных срабатываний всяческих фильтров. Изначально BitTorrent работал на одном TCP-порту и не шифровался. Угадайте, почему поведение изменилось? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 15 декабря, 2010 · Жалоба Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. +1Только у нас немного по другому, на одного прова полезный трафик типа хттп, игровой, почтовый и т.д. а весь остальной шлак в другой канал. А так были бы каналы резиновые за приемлемую цену то можно было бы и не извращаться. Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Поубивал бы таких админов... А я магистралов, которые шкуродерством занимаются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kirya Опубликовано 16 декабря, 2010 · Жалоба Есть ещё один простой метод исключением, выделяем входящий трафик с портами src <1024, выделяем список основных сервисов и games по портам, протоколам итд. То что осталось - на 99% Bittorrent. По факту жалоб добавляем в исключения то что пропустили. Поубивал бы таких админов... А я магистралов, которые шкуродерством занимаются. Не фиг жить "в заповедниках".Это всегда дорого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 18 декабря, 2010 · Жалоба Вы так докрутитесь до жалоб в связь надзор, за хреновое качество.Кол-во соединений/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 соединениями к прмиеру? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Fog Опубликовано 18 декабря, 2010 · Жалоба 400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи. как правило надежный путь это количество конектов на любой порт выше 1024. NiTr0 ваш пример это просто опросник торента. когда начнется кач будет много срц одинакового порта. тоесть вариант КАК определить торент - это много исходящих/входящих соеднинений на исходящий порт клиента. так как торенту на до же на какой то порт принимать и слушать. вот только непонятно как эти порты запоминать и блочить. тоесть аддресс-лист есть. а что то вроде аддресс-лист-порт нету. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_INF_ Опубликовано 19 декабря, 2010 · Жалоба Вот рабочее и самое не ресурсоемкое (ИМХО) на данный момент решение, предварительно необходимо разрешить трафик игровых, 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 сессий. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 20 декабря, 2010 (изменено) · Жалоба 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'у. Изменено 20 декабря, 2010 пользователем hiller Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 20 декабря, 2010 · Жалоба А то, что у качка упадет скорость не только в торренте, но и в других программах, работающих параллельно с торрентом - собссно не есть большая проблема, т.к. торрент обычно канал хорошо засирает.Инет не доливают - повод для жалобы. Как приоритезировать-то будете такой "зоопарк"? :) И сколько ресурсов потребуется на одного качка с 400 соединениями к прмиеру?Не сильно больше, чем требуется для НАТа. 400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.И?Реально от этого КПД только падает. Есть некоторая корреляция по колличеству соединений на мегабит: меньше - полоса как правило не догружена до полки, больше - полоса в полку, но полезного трафика меньше, тк много ip/tcp служебок бегает. Но лимит ХР это слишком мало для мегабитных тарифов. Чтобы блокировка работала со 100% точностью, ломимся по http на подозрительный порт и убеждаемся, что это точно торрент. Надо почитать спецификацию торрента, чтобы делать правильный http-запрос, который присущ только torrent'у.Вы так уже делали?))))))Так то торент бинарный, и только с трекерами он по хттп общаться может, а может по юдп. Ну повешаю я на 443, 3389, pptp (номер не помню), включу крипту. На глазок отличите шифрованный торрент от хттпс сайта или впн игрового хаба? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 21 декабря, 2010 · Жалоба А то, что у качка упадет скорость не только в торренте, но и в других программах, работающих параллельно с торрентом - собссно не есть большая проблема, т.к. торрент обычно канал хорошо засирает.Инет не доливают - повод для жалобы. Как приоритезировать-то будете такой "зоопарк"? :) И сколько ресурсов потребуется на одного качка с 400 соединениями к прмиеру?Не сильно больше, чем требуется для НАТа. 400 говорите. на многих трекерах патчи лежат чтоб ограничения винды снять. и не стесняются писать по 1-2 тыщи.И?Реально от этого КПД только падает. Есть некоторая корреляция по колличеству соединений на мегабит: меньше - полоса как правило не догружена до полки, больше - полоса в полку, но полезного трафика меньше, тк много ip/tcp служебок бегает. Но лимит ХР это слишком мало для мегабитных тарифов. Чтобы блокировка работала со 100% точностью, ломимся по http на подозрительный порт и убеждаемся, что это точно торрент. Надо почитать спецификацию торрента, чтобы делать правильный http-запрос, который присущ только torrent'у.Вы так уже делали?))))))Так то торент бинарный, и только с трекерами он по хттп общаться может, а может по юдп. Ну повешаю я на 443, 3389, pptp (номер не помню), включу крипту. На глазок отличите шифрованный торрент от хттпс сайта или впн игрового хаба? 1. Надо в договоре предусматривать такие моменты.2. Нат + качки = НАТ*2? А зачем, если можно просто НАТ? 3. Лимита XP хватает, чтобы таскать файлы по любым протоколам на любых скоростях. Если считаете, что не достаточно, то это результат перегрузки на вашем провайдере или выше. 4. Хрен на бинарность торрента. Можно не хттп, а бинарный запрос делать. Наша задача убедиться, что этот порт открыт именно торрентом. Вешайте его хоть на какой порт, включайте хоть какую крипту, отвечать он обязан по протоколу. Запрашиваем хэндшейк и убеждаемся, что это торрент. А найдем мы его по дикому количеству соединений с этим портом на разные адреса. Другие сервисы так себя не ведут. Так что можно классифицировать этот трафик без сверхестественных DPI (читай лишних нагрузок). Провел несколько тестов. Работает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...