Балансировка двух Tor-каналов vs анонимность
Если хочется получить бОльшую скорость работы через Tor, или если хочется не ассоциировать разные анонимные identity посредством использования одних и тех же цепочек в Tor, можно, в простейшем случае, поднять два разных тор-клиента, и связать каждый из них со своим пользователем на машине. Однако, у такого подхода, если единственная его цель – улучшение качества и скорости связи, есть очевидный минус: "ручная" балансировка задач между разными Tor-каналами далеко не самая оптимальная. В связи с этим предлагается обсудить следующую схему. Допустим, что у нас есть два тор-канала (соответствуют одновременно запущенным двум Tor-клиентам) с прозрачным заворачиванием всего трафика от нужных юзеров в сеть Tor. Логично было бы сделать автоматическую балансировку нагрузки между этими каналами стандартными средствами firewall'а (например, altq в OpenBSD PF с использованием опций типа round-robin, route-to и, может быть, source-hash: какие-то примеры обсуждались здесь[link1]). Однако, мне не очевидно что такая схема будет работать корректно, т.к. всё зависит от того, отправляются ли разные tcp-сессии через разные gateway (Tor-клиенты), и, если нет, то как отреагирует firewall на ситуацию с сосуществованием двух независимых маршрутов до одного и того же внешнего IP. Также возникает вопрос о всевозможных последствиях для анонимности в таком подходе: сможет ли, к примеру, внешний хост определить, что пользовательский Tor-клиент настроен именно вышеуказанным способом? Вдруг разные элементы web-страницы будут загружаться через разные exit-ноды? Просьба к уважаемым участникам, кто понимает как технически работают балансировки интернет-каналов и Tor высказаться по этому поводу. Конкретные тезисы, выносимые на обсуждение, следующие:
- Возможно ли настроить такую схему (нет ли здесь противоречий со стандартами)?
- Каковы последствия данной настройки для анонимности?
- Какие конкретные технические рекомендации вы можете дать для организации такой настройки? (В терминологии iptables или, что лучше, pf, т.к. с ним я знаком лучше)
Ссылки
[link1] http://www.opennet.ru/base/net/pf_faq.txt.html
[link2] https://www.pgpru.com/proekt/poljzovateli?profile=mellon
[link3] http://juick.com/Raegdan/2589501
[link4] http://juick.com/Mellon/2609018
[link5] https://www.pgpru.com/novosti/2010/deanonimizacijabittorrentpoljzovatelejjsovmestnoispoljzujuschihsetjtor
[link6] https://www.pgpru.com/comment69862
Раньше были способы подключения двух медленных модемов в один канал. Наверняка можно через два псевдоустройства.
Первое, что приходит в голову:
первый клиент случайно выбирает цепочку: A-x-C, второй клиент выбирает цепочку: C-y-A, а трафик в данном случае идёт специфически коррелируемый и вообще нестандартный (половины пакетов нехватает).
Если все пакеты в рамках одной TCP-сессии идут только через одну цепочку одного из Tor-клиентов, то корреляции будут не столь явными, по крайней мере, это не будет отличаться от случая двух независимых Tor-клиентов концептуально. Дело ещё в том, что пока я очень плохо представляю как работает тот же altq и route-to: данными вещами в pf пользоваться не приходилось. С другой стороны, данная задача мне кажется интересной по практике настройки балансировки трафика (я-то думал, что на десктопе такое понадобиться вряд ли сможет).
Почему только двух? ;)
Я мог бы написать n, но поначалу проще отлаживать на 2ух, да и понятнее излагать концепцию на 2ух, к тому же, при n>3, имхо, угроза анонимности может стать существенной.
Ну допустим будет понятно, что два канала на самом деле – один, угрозы анонимности тут не более чем для одного "обычного" канала.
Если это будет понятно, то пользователи со сдвоенными каналами выделяются в заведомо маленькое множество. Примерно против этого же стараются скрывать ОС и браузер путём унифицированной подмены отправляемых заголовков.
Информация об ОС и броузере может теоретически помочь атаковать машину, т.е. подобрать уязвимость, эксплойт и т.д. А чем облегчает атаку (или чем грозит выделение в некое анонимное подмножество некоего также анонимного множества) информация о кол-ве каналов с точки, не совсем ясно.
Выделение в некое анонимное подмножество некоего также анонимного множества сужает область поиска анонима при переборе. Допустим, есть данные или гипотеза о том, что некто неанонимно посещает сайт А и настраивает свой Tor вышеуказанным образом. Также есть гипотеза, что он же анонимно посещает сайт B. Администраторы сайта B, зная об этой отличительной характеристике, могут с той или иной вероятностью подтвердить эту гипотезу, т.е. деанонимизировать анонима на сайте B. В предположении, что аноним соединяется с инетом через единственный интернет-канал, противник может провести атаку пересечения, доказав свою гипотезу, т.е. окончательно деанонимизировав нужного пользователя.
Впрочем, ответ на то, что вы спрашиваете столь очевиден, что я с трудом сдерживаюсь не назвать Вас плохими словами. Подобные пустые вопросы отнимают время участников, а когда они превращаются в неприкрытый троллинг отбивается всякое желание на подобное отвечать. Если не отвечать вообще, то новички, который действительно не понимают, полностью перестанут получать ответы на свои вопросы. Самый обычный DDoS.
Вот только пожалуйста без эмоций, если можно, а за ответ спасибо
Вот если зайти на pgpru.com, отключив блокировку баннеров, то можно увидеть через iptraf, что стартует множество сессий.
Вообще — это типично — множество TCP-сессий для одного HTTP-соединения.
Если они пойдут для одного пользователя не через один exit, а через два, то SATtva (или "человек-посредине") обо всём догадается :-)
Известны ли в IT какие-то способы связать все эти сессии воедино на правилах fw, т.е. иначе кроме как через привязывание всего трафика сгенерированного одним пользователем к одному и тому же Tor-клиенту? Конкретно web-трафик можно всегда пропускать через privoxy, а уж оно ведает, что все эти сессии порождены загрузкой одного и того же url. Вот бы познания privoxy, да fw'у в уши :-)
По порту всё можно завернуть в privoxy, а сам исходящий трафик от привокси как балансировать, между двумя торами что-ли?
Что-то типа того :) Только не факт, что можно сделать так, чтобы privoxy загружало всё, связанное с заданным url'ом, через один и тот же тор-клиент. Есть тагирование и покраска трафика, но вряд ли здесь это поможет, т.к., имхо, уровень, на котором нужно разгребать трафик, выше чем tcp, т.е. fw'у он не виден.
Это раз. А ещё вэб-страница может иметь смешанный контент из разных url'ов — это два.
Тогда получается, что только браузер знает, что надо грузить обязательно через один и тот же Tor-клиент :-(
Подумалось вот о чём: можно ли приспособить идею топика к ускорению работы скрытого сервиса? Например, клиентам раздаётся 3 разных onion-адреса для своего http-сервера (физически все они на одной машине), а клиенты настраивают балансировку нагрузки при обращениях к серверу. Непосредственно такое, наверное, не сделать, но можно поиграться с костылями: к примеру, опция AutomapHostsOnResolve позволяет отобразить все скрытые сервисы на какие-то виртуальные IP. Далее можно согласованно "продолжить маршрут" на серверной и клиентской стороне так, чтобы все IP, соответствующие onion-адресам, были gateway'ями на один какой-то IP адрес уже собственно нужного http-сервера. Iproute/iproute2/iptables вроде бы позволяют нагородить такой огород (?) У кого какие мысли по этому поводу?
Балансировку каких нагрузок это решает? Самая затратная с точки зрения времени часть HS-протокола — это построение двух цепочек до точки встречи.
Допустим, http-клиент скачивает какой-то файл. Если его скачка идёт параллельно по двум цепочкам, он должен качаться быстрее.
Mellon[link2]'у пофиг на профилируемость из-за балансировки[link3], скрипты[link4] готовы.
Когда-то давно интересовался подобным вопросом. Под Винду находил проги, которые могли устанавливать до 500 соединений одновременно.
В общем случае, скорость не увеличится. Винда и Линукс – это операционки с разделением по времени. Будет происходить чередование каналов закачки. Лет десять назад, скорость по разным маршрутам могла заметно отличаться из-за разницы в качестве обслуживания. Возможно, на многоядерных/многопроцессорных машинах скорость увеличится на число ядер, но для этого нужны проги специально написанные и скомпиленные соответствующим компилятором.
Причем тут ядра? Скорость одиночного TCP потока ограничена cognestion control алгоритмом и сильно зависит от пинга. Поэтому общеизвестный факт, что нужно качать в много потоков чтобы выжать всю ширину канала. Все download менеджеры так делают.
В том-то и дело, что одиночного. А про ядра – это просто предположение.
Есть разные утилиты типа half-open fix, которые увеличивают кл-во соединений по умолчанию с десяти, как правило до ста, правкой файла tcpip.sys. Это в виндах, которые не тронуты руками говносборщиков. Хотя среди сборок есть неплохие, но при работе с виндой предпочтительны чистые образа, во избежание глюков и малвари от сборщика, что не редкость. Бэкдоры от Майкрософт и АНБ не рассматриваются, потому что использование винды развлекательное или для официальной работы.
Раньше в винде было ограничение на 10 соед. Потом его снимали вроде в каких-то версиях, в общем от оси к оси, в зависимости от SP и обновлений, там разные решения были.
Обычно увеличивают до 100, как правило выставляют значение <100>. Но можно устанавливать любое произвольное количество, если не изменяет память, то и 500, и хоть тысячу, хоть две, не помню, есть ли вообще там ограничение, в частности в half-open fix'e. Вообще-то, 100 за глаза хватает рабочей станции, активно юзающей сеть + торенты.
Это в основном для торентоводов-стахановцев. Например, устаревшая, но до сих пор популярная среди юзеров торентов модель роутера асус RT-n16, по словам производителя, позволяет устанавливать до 300 тысяч одновременных соединений.
Жлобское сетевое поведение. И DM так делают, если выставить подобные настройки и сервер позволит качать в несколько потоков. Как правило, чаще встречаются просьбы (либо предопределенные политики) владельцев сетевого ресурса качать в один-два потока. Или бан.
Во многих случаях агрессивного поведения качальщика, он мало что выигрывает. Если один поток отдает 1 Мб/с, то это не значит, 10 потоков будут отдавать в сумме 10 Мб/с.
Про балансировку тора читать странно. Зачем? Тем более, если рассматривать с прицелом на анонимность, без пол-литра не обойтись.
Сейчас и так из коробки все быстро и анонимно. Но можно попробовать. Смотря для чего использовать балансировку.
Mellon, результаты экспериментов будут опубликованы? Тем более, что топик древний.
Кстати, кажется ранее в каком-то из торент-клиентов была встроена поддержка Tor. Vuze вроде, но он неудобный показался, с рекламой был года 4 назад, он как-то сразу не понравился, поэтому мной не только режим торификации не тестировался, но и обычное использование.
Топик был создан более четырёх лет назад, когда со скоростью всё было не так хорошо, опасность профилирования ещё не осознавалась, а TBB не было. Я — автор топика, если что.
Почему-то сразу вспоминается это[link5] и это[link6].