Tor и безмерная текучесть трафика

Здравствуйте, у меня проблема, которая заключается в том, что tor при простое системы для чего-то потребляет трафик.
Но, как полагаю я, это вовсе не на обновление каталога серверов, т.к:
Сначала немного скажу что я делал. Система у меня gentoo, если я просто поднимаю ppp1 без тора, то трафик не поступает вообще, т.е. как я получил 54 байта так это чисто и остается, как только я поднимаю сервис tor, через секунд 30-40 ко мне поступает иногда до 40кб иногда до 200кб разом, и потом, на протяжении десяти минут входящий трафик увеличивается примерно до 600кб, т.е. например минуту или две стабильно ничего не происходит, а потом поступает опять от 40 – 200 кб. Вообщем поведение разное, бывает что и просто по 20 кб / примерно в 20 секунд поступает.

Открыл в редакторе все файлы из каталога /var/lib/tor/data, и в это время, пока идет трафик, они не изменяются.
Как только останавливаю tor трафик тоже перестает поступать.
Отмечу еще раз, что я в это время ничего не делаю, прокси нигде не использую, все приложения которые могут испоьзовать сеть выключены, даже локальный днс пробовал отключать, просто запускаю в консоли тор и наблюдаю за текучестью трафика.

Интернет по технологии adsl.
конфиг тора:
User tor Group tor PIDFile /var/run/tor/tor.pid SocksPort 9050 SocksListenAddress 127.0.0.1 Log notice file /var/log/tor/tor.log DataDirectory /var/lib/tor/data ClientOnly 1 DirFetchPeriod 1 hours

конфиг privoxy:
forward-socks4a / 127.0.0.1:9050 . trust-info-url http://www.example.com/why_we_block.html trust-info-url http://www.example.com/what_we_allow.html confdir /etc/privoxy logdir /var/log/privoxy actionsfile standard # Internal purpose, recommended actionsfile default # Main actions file actionsfile user # User customizations filterfile default.filter logfile privoxy.log debug 4096 # Startup banner and warnings debug 8192 # Errors - *we highly recommended enabling this* listen-address 127.0.0.1:8118 toggle 1 enable-remote-toggle 1 enable-remote-http-toggle 1 enable-edit-actions 1 buffer-limit 4096 forward-socks4a / 127.0.0.1:9050 . forwarded-connect-retries 0

Tor v0.1.1.23

Вывод tcpdump -i ppp1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ppp1, link-type LINUX_SLL (Linux cooked), capture size 68 bytes 18:09:23.340227 IP 78.96.117.44.31070 > 87.119.245.48.1026: UDP, length 366 18:09:38.461171 IP 87.119.245.48 > 78.96.117.44: ICMP host 87.119.245.48 unreachable - admin prohibited, length 402 18:11:15.056371 IP 87.119.245.48.46371 > 85.214.91.190.9030: S 1126139466:1126139466(0) win 5808 <mss 1452,sackOK,timestamp 48707900[|tcp]> 18:11:15.203194 IP 85.214.91.190.9030 > 87.119.245.48.46371: S 1116407089:1116407089(0) ack 1126139467 win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp[|tcp]> 18:11:15.203376 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 1 win 182 <nop,nop,timestamp 48707937 0> 18:11:15.203837 IP 87.119.245.48.46371 > 85.214.91.190.9030: P 1:101(100) ack 1 win 182 <nop,nop,timestamp 48707937 0> 18:11:15.372818 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 1:1441(1440) ack 101 win 65435 <nop,nop,timestamp 7816169 48707900> 18:11:15.372980 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 1441 win 272 <nop,nop,timestamp 48707979 7816169> 18:11:15.374003 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 1441:2881(1440) ack 101 win 65435 <nop,nop,timestamp 7816169 48707900> 18:11:15.374147 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 2881 win 362 <nop,nop,timestamp 48707980 7816169> 18:11:15.520865 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 2881:4321(1440) ack 101 win 65435 <nop,nop,timestamp 7816171 48707979> 18:11:15.521006 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 4321 win 452 <nop,nop,timestamp 48708016 7816171> 18:11:15.522066 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 4321:5761(1440) ack 101 win 65435 <nop,nop,timestamp 7816171 48707979> 18:11:15.522198 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 5761 win 542 <nop,nop,timestamp 48708017 7816171> 18:11:15.523512 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 5761:7201(1440) ack 101 win 65435 <nop,nop,timestamp 7816171 48707980> ............................ 18:11:16.433831 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 68417:69857(1440) ack 101 win 65435 <nop,nop,timestamp 7816180 48708208> 18:11:16.435355 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 69857:71297(1440) ack 101 win 65435 <nop,nop,timestamp 7816180 48708208> 18:11:16.435501 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 71297 win 2003 <nop,nop,timestamp 48708245 7816180> 18:11:16.437070 IP 85.214.91.190.9030 > 87.119.245.48.46371: . 71297:72737(1440) ack 101 win 65435 <nop,nop,timestamp 7816180 48708208> 18:11:16.437495 IP 85.214.91.190.9030 > 87.119.245.48.46371: P 72737:73505(768) ack 101 win 65435 <nop,nop,timestamp 7816180 48708208> 18:11:16.437648 IP 87.119.245.48.46371 > 85.214.91.190.9030: . ack 73505 win 2003 <nop,nop,timestamp 48708246 7816180> 18:11:33.786064 IP 87.119.238.63.4316 > 87.119.245.48.2967: S 275830455:275830455(0) win 65535 <mss 1440,nop,nop,sackOK> 18:11:33.786275 IP 87.119.245.48.2967 > 87.119.238.63.4316: R 0:0(0) ack 275830456 win 0 18:11:34.169175 IP 87.119.238.63.4316 > 87.119.245.48.2967: S 275830455:275830455(0) win 65535 <mss 1440,nop,nop,sackOK> 18:11:34.169365 IP 87.119.245.48 > 87.119.238.63: ICMP host 87.119.245.48 unreachable - admin prohibited, length 56 18:11:59.250219 IP 87.119.245.48.37113 > 128.31.0.34.9001: F 863861110:863861110(0) ack 2422099679 win 484 <nop,nop,timestamp 48718949 381939803> 18:11:59.250532 IP 87.119.245.48.46437 > 85.214.83.203.9001: F 929276118:929276118(0) ack 926556819 win 396 <nop,nop,timestamp 48718949 3047666157> 18:11:59.250966 IP 87.119.245.48.33308 > 212.42.236.140.https: F 920485137:920485137(0) ack 2261896261 win 359 <nop,nop,timestamp 48718949 284979766> 18:11:59.395624 IP 85.214.83.203.9001 > 87.119.245.48.46437: F 1:1(0) ack 1 win 3011 <nop,nop,timestamp 3047881466 48718949> 18:11:59.395802 IP 87.119.245.48.46437 > 85.214.83.203.9001: . ack 2 win 396 <nop,nop,timestamp 48718985 3047881466> 18:11:59.400792 IP 212.42.236.140.https > 87.119.245.48.33308: F 1:1(0) ack 1 win 43 <nop,nop,timestamp 285033831 48718949> 18:11:59.400962 IP 87.119.245.48.33308 > 212.42.236.140.https: . ack 2 win 359 <nop,nop,timestamp 48718986 285033831> 18:11:59.445614 IP 128.31.0.34.9001 > 87.119.245.48.37113: F 1:1(0) ack 1 win 113 <nop,nop,timestamp 381992303 48718949> 18:11:59.445837 IP 87.119.245.48.37113 > 128.31.0.34.9001: . ack 2 win 484 <nop,nop,timestamp 48718998 381992303>

87.119.245.48 – мой текущий динамический ip

Данный dump сделал кргда был опущен dns сервер и когда в конфиге тора была запись:
DirFetchPeriod 12 hours

Помогите минимизировать трафик при простое системы, ибо как полагаю я, это какой-то ненужный мне трафик.

На страницу: 1, 2, 3, 4, 5, 6, 7 След.

Комментарии

—	spinore (03/07/2007 13:32) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

Тор тяжёл тем, что это не один IP. Если бы был один-два-три IPшника, я бы просто посчитал PF'ом – там это легко делается. А вот как я объясню PF'у привило "все пакеты тор"? Писать таблицу всех IP не предлагать :-) Можно, конечно, ещё на ночь поставить, предварительно всё отключив лишнее, ас утра поглядеть – единственный вариант.

—	unknown (03/07/2007 13:54) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Можно, конечно, ещё на ночь поставить, предварительно всё отключив лишнее, ас утра поглядеть – единственный вариант.

А если отключить всё лишнее, то он не будет активно перестраивать цепочки -> меньше траффик на проверку цепочек -> реже обновления статистики

—	spinore (03/07/2007 14:32) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

А если отключить всё лишнее, то он не будет активно перестраивать цепочки -> меньше траффик на проверку цепочек -> реже обновления статистики

А что, траффик, потребляемый тором, зависит ещё от того какие программы лезут в интернет напрямую?
И вообще, он неаддитивен получается? То есть траффик нагрзуки != траффик холостого хода + траффик программ, работающих под тором(?). Да, как всё трудно. Я единственное что замечал, так это то, что если тор долго не трогать netstat в диагностике сетевого монитора не показывает соединения с тор-узлами: он что, усыпает и отключается на автопилоте?

—	unknown (03/07/2007 15:57) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Может не так поняли слово лишнее?

Запустили тор, он скачал статистику. Запустили программу через тор, он построила цепочки, если цепочка не строится, может ещё раз ткнуться в статистику – не выкачивая всю с главного узла, а только обновления с некоторых. Если программы в тор не ломятся, то и цепочки не строятся, а статистика обновляется редко и более глобально.

—	spinore (03/07/2007 16:27, исправлен 03/07/2007 16:30) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

Сейчас вроде всё понял.

Если программы в тор не ломятся, то и цепочки не строятся, а статистика обновляется редко и более глобально.

Не уверен что она вообще будет обновляться. Мне всегда казалось, что если тор не используют, то он "усыпает".
Здесь вопрос идёт относительно серьёзной уязвимости в корреляции траффика:
Допустим, что оппнент подозревает, что пользователь "A", посещающий некоторый сайт, является Ивановым Иваном Ивановичем, при которого всё известно. Допустим, что оппонент обладает неограниченными возможностями в прослушивании входящего траффика на сервер, где хостится тот самый сайт, посещаемый пользователем "A". Поскольку все соединения с тором могут быть легко зафиксированы на уровне провайдера, то можно набирать статистику и проверять: не в промежутки ли времени между соединениями Ивана Ивановича с tor'ом пользователь "A" подключался к сайту. Если статистика говорит о том, что не обнаружено ни одного соединения пользователя "A" с сайтом в другое время, возникают мутные подозрения о том, что Иван Иванович и есть пользователь "А". Чтобы реализовать такую схему не надо быть совсем глобальным наблюдателем: надо лишь сидеть в двух местах в интернете: между Иваном Ивановичем и его провайдером и на потоках траффика перед самым сайтом. Вопрос: что может предпринять Иван Иванович? Например, сделать вид что соединение с тором у него есть всегда. Но если интенсивность скачки статистики сильно зависит от интенсивности использования тора, то атака остаётся осуществимой и лишь чуть-чуть усложняется. Делать равномерный покрывающий траффик непрактично в условиях ограниченности оного. В итоге, вопрос сводится к совсем простому: окупает ли эта "псевдозащита" от указанной уязвимости затраты на перерасход траффика в холостом ходу tor'а?

—	unknown (03/07/2007 16:56) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Это атака пересечения траффика, от которой tor не защищает

—	spinore (03/07/2007 17:20) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

Тяжкий случай ;(

—	*Гость* (03/07/2007 17:26) <#>

Делать равномерный покрывающий траффик непрактично в условиях ограниченности оного

Тут уж придется выбирать – "кошелёк(траффик) или жизнь(анонимность)" :).
А вобще то неограниченный траффик становиться всё более доступным...

—	unknown (03/07/2007 17:29, исправлен 03/07/2007 17:30) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Вопрос: что может предпринять Иван Иванович? Например, сделать вид что соединение с тором у него есть всегда.

Запустить свой сервер (в данном случае хотя бы middleman-tor)! Справедливо для всех анонимных сетей.

—	spinore (03/07/2007 18:26) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

Запустил бы. Жалко что ли? Ясно, что не большее чем middle man :-)))
Но кто мне внешние соединения откроет? Итак админы стегут что трафа много народ расходует. даже об внешнем ssh не может быть речи. Только туеннели -((

—	SATtva (03/07/2007 22:25, исправлен 31/08/2007 22:09) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Это атака пересечения траффика, от которой tor не защищает

В некоторых случаях проблема может быть серьёзнее, чем может показаться. Допустим, небольшой город, где все друг друга знают, а число интернет-пользователей сравнительно невелико. Если Иван Иваныч решит подключиться к какому-нибудь местному узлу через Tor, провайдер окажется для него глобальным наблюдателем, отслеживающих трафик обоих хостов. Ну, и в бОльших масштабах тоже могут возникнуть трудности.

—	spinore (04/07/2007 18:34) профиль/связь <#> комментариев: 1515 документов: 44 редакций: 5786

Проблема tor'a в том, что хоть им много людей пользуется во всём мире, но никак не на каждом отдельно взятом квадратном метре. Если против tor'а предпримут атаку, то много голов слетит: выслеживаем всех кто пользуется и идём на рейд (о чём уже упоминал в какой-то теме). tor безопасен пока только потому, что за него никто не берётся: неуловимому Джо прятаться проще.

—	ent1 (04/07/2007 23:25) <#>

spinore
Если нет "продвинутых" средств подсчета рафа, можно сделать так:
1. ограничить число первых нод (через ReachableAddresses) и считать трафик только к этим ip.
2. завернуть трафик тора на локальный прокси (через HttpProxy и HttpsProxy) и считать трафик от тора к лок. проксе.

А вот насчет покрывающего трафика вопрос гораздо интереснее!
Допустим что нет возможности поднять сервер tor, даже как middle – как про техническим причинам (человек сидит за натом или проксей) так и по "юридическим" (в договоре с провайдером указано что нельзя проксировать чужой трафик или типа того).
Как быть?
Что-то вижу пока только один вариант – для всех цепочек всегда используется одна нода (EntryNodes и StrictEntryNodes)! Далле средствали ос ограничиваем входящую и исходящую скорость (например по 5кб), далее запускаем одновременно закачка большого файла с внешнего сервера и заливку большого ыайла на внешний сервер.

Очень топорный вариант, но что-то лучше придумать не получается.
Может у кого есть мысли?

—	SATtva (04/07/2007 23:50) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Далле средствали ос ограничиваем входящую и исходящую скорость (например по 5кб), далее запускаем одновременно закачка большого файла с внешнего сервера и заливку большого ыайла на внешний сервер.

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

Вообще ParanoidAnt уже предлагал здесь некоторые инструменты. Может быть не совсем релевантно, но может пригодиться. Кроме того, генерировать трафик можно, пуская поток из /dev/urandom с хоста-инициатора в /dev/null на хосте-получателе.

Замечу также, что покрывающий трафик не реализован в Tor'е не только (и не столько) по экономическим соображениям. Дело в том, что пока нет бесспорного понимания, в какой мере использование покрывающего трафика способствует повышению анонимности соединения. В качестве одного из примеров, активный нападающий (с доступом к большим сегментам Сети) может разрывать некоторые соединения и смотреть, в какой момент ваше торифицированное подключение отвалится. Покрывающий трафик здесь не поможет.

—	ent1 (05/07/2007 00:28) <#>

Конечно, решения которое я предложил – кривое. Но вообще без покрывающего трафика сейчас жить опасно! Особенно если под контролем "точка входа" и "точка выхода". У меня уже был один прецедент, когда без покрывающего трафика мне сказали кто есть ху, для чего было достаточно посмотреть "нефлоу с сor ма". Так что делайте вывод!

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

Шейпер действительно будет не лишним. Но имхо и без него будет работать, искрене надеюсь, что каждое соединение получит равную часть полосы (4 целевых соединения и 1 покрывающее – каждомы по 1кб).

А насчет покрывающего трафика в целом и угрозы "разрыва соединения" – было бы здорово, если можно было средствами самого тора организовывать покрывающий трафик фиксированой полосы ДО ПЕРВОЙ ноды!

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

А вот аткой вопрос – если построены две разные цепочки с одной и тойже EntryNode, то можно будет определить какой трафик относиться к одной и другой цепочке (если снимать трафик только от меня к EntryNodes)?

На страницу: 1, 2, 3, 4, 5, 6, 7 След.

Ваша оценка документа [показать результаты]