Tor и безмерная текучесть трафика
Здравствуйте, у меня проблема, которая заключается в том, что tor при простое системы для чего-то потребляет трафик.
Но, как полагаю я, это вовсе не на обновление каталога серверов, т.к:
Сначала немного скажу что я делал. Система у меня gentoo, если я просто поднимаю ppp1 без тора, то трафик не поступает вообще, т.е. как я получил 54 байта так это чисто и остается, как только я поднимаю сервис tor, через секунд 30-40 ко мне поступает иногда до 40кб иногда до 200кб разом, и потом, на протяжении десяти минут входящий трафик увеличивается примерно до 600кб, т.е. например минуту или две стабильно ничего не происходит, а потом поступает опять от 40 – 200 кб. Вообщем поведение разное, бывает что и просто по 20 кб / примерно в 20 секунд поступает.
Открыл в редакторе все файлы из каталога /var/lib/tor/data, и в это время, пока идет трафик, они не изменяются.
Как только останавливаю tor трафик тоже перестает поступать.
Отмечу еще раз, что я в это время ничего не делаю, прокси нигде не использую, все приложения которые могут испоьзовать сеть выключены, даже локальный днс пробовал отключать, просто запускаю в консоли тор и наблюдаю за текучестью трафика.
Интернет по технологии adsl.
конфиг тора:
конфиг privoxy:
Tor v0.1.1.23
Вывод tcpdump -i ppp1
87.119.245.48 – мой текущий динамический ip
Данный dump сделал кргда был опущен dns сервер и когда в конфиге тора была запись:
DirFetchPeriod 12 hours
Помогите минимизировать трафик при простое системы, ибо как полагаю я, это какой-то ненужный мне трафик.
Какой исходник? Это просто sfx rar архив и батник, который собственно производит инсталляцию. Боящиеся запускать могут просто открыть в WinRar и извлечь все файлы вручную. Бинари в сборке взяты из официального дистрибутива, и это легко проверить.
Вот в настройке tor сервера я не силен. Может местные гуру дадут универсальный конфиг, или советы по созданию конфигуратора?
Будем заражать все подряд. Авось из десятка тысяч заражений будет хотя-бы сотня нормальных серверов.
комментариев: 1515 документов: 44 редакций: 5786
Ну вот как такие крутые хакеры, имеющие свой бот-нет, не умеют настраивать тор-сервер? Я никогда не настраивал, но другие могут подксказать.
Надо просто посмотреть на статистику: сколько пользовательских машин с Win наборту имеют реальный IP: параметр, думаю, известный.
Может не стоит компрометировать сеть ТОР таким образом?
Цель конечно понять можно, но вот средства. К сети будет больше ненужного/лишнего внимания.
Что-то сейчас мне эта идея не кажется такой хорошей!
Не стоит опошлять все светлое и хорошее в этом мире!
комментариев: 1515 документов: 44 редакций: 5786
Те, кому надо с обоих сторон о её существовании прекрасно осведомлены
ЗЫ: попытайтесь что-нибудь скачать с рапиды через тор ;-)
комментариев: 9796 документов: 488 редакций: 5664
Если написать вирус, то разработчики будут регистрировать exit ноды вручную, после подтверждения согласия запустившего (что кажется и так делалось по-крайней мере поначалу). Потому что иначе получим массу тормозящих, нестабильных и блокируемых на законном основании антивирусами и файрволлами exit-нод, из тора будет никуда не выйти.
Наконец написавший вирус может получить контроль над большой сетью exit'ов с которых будет легко вычислять трафик пользователей, что облегчает разрушение анонимности, становясь всё более глобальным наблюдателем. Это со всех сторон провокация.
Согласен с unknown'ом, что создание ботнета на основе оригинальной Tor'ы с последующим зачислением ее в ранг вирусов и троянов – Провокация!
комментариев: 9796 документов: 488 редакций: 5664
Так бы сразу честно и предупреждали! Вот это уже полезное с точки зрения совершенствования безопасности системы замечание. Но кажется у разработчиков уже были какие-то мысли по противодействию таким сценариям.
комментариев: 11558 документов: 1036 редакций: 4118
Если бы это было возможно, количество Tor-узлов было бы значительно больше. К сожалению, настройка сервера (или, вернее, его окружения) в большинстве случаев должна производиться вручную. spinore верно заметил, что не на каждой машине есть возможность ретрансляции входящего трафика (где нет брандмауэров или затянутых рутеров, давно водятся стаи троянов и ботов).
Здравая мысль. Пару недель назад один из участников or-talk предложил такую же, как Гость, идею "самораспространяющегося дистрибутива". Поддержки в сообществе она не нашла.
Ну "само" это конечно излишне, а вот что-то типа "zero configuration", как в hamachi, иметь бы не помешало:
У меня был примерно такой же ход мыслей, завернуть тор в тор. Понятно, что думал я над этим из спортивного интереса.
Чтобы в цепочках не было одинаковых нод, можно сделать скрипт, который будет периолдически просматривать файл cached-routers и половину нод записывать в ExcludeNodes в torrc одной копии ТОРа, а остальное в torrc другой копии. Или еще использовать EntryNodes/ExitNodes в одной копии для ограничения используемых нод.
Еще раз говорю, это носит только познавательный характер.
Понял, что сморозил чушь! В таком случае будет два разных TCP соединения и все прозрачно.
Тогда еще один вопросик – в первом варианте все будет гоняться через одно TCP соединение с EntryNode или тоже будет открыто второе?
Это пока!
spinore
Неужели? :)
Можно использовать Tor control protocol – команду EXTENDCIRCUIT, или таки провести исследование куда компилятор кладёт эту константу и пропатчить бинарники :)
Хорошо бы ввести в Tor опцию задержки пакета(cell), которую можно было бы реализовать через приоритетную очередь на Tor-серверах.
Это не потребует дополнительных ресурсов, но увеличит безопасность за счёт времени для желающих.
Хотя, конечно, если таковых будет много, придётся либо увеличивать длину очереди(т.е. тратить доп. ресурсы), либо принудительно сокращать желаемое для них время задержки.
Но много таковых будет вряд-ли...
комментариев: 11558 документов: 1036 редакций: 4118
Приемлемая задержка до 15-30 секунд не повысит безопасность. А неприемлемая будет по таймауту убивать HTTP-, TCP-, и прочие сессии клиентского уровня.