Проверка анонимности Tor

хотя "отдельный" требует уточнения – кроме него, есть еще один, общий, что ли?

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

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

Вы очень хорошо мыслите :) Это верно, что нормальный файерволл не будет различать какое приложение послало с указанной машины пакет в сеть, но файерволл знает, что все пакеты с некоторой заданной машины (которую вы используете для тора) должны перенаправляться в тор-сеть, причём сам тор-клиент крутится на рутере с файерволлом, а потому машина, на которой вы используете тор, работает с сетью вообще "прозрачно" (без всяких прокси и т.п.): для неё ртуер – самый обычный gateway (маршрутизатор). Т.о., всё что покидает целевую машину, предназначенную для работы в тор, либо не уйдёт в сеть вообще (например, тор по udp не работает, а потому рутер зарежет на своей стороне этот трафик полностью), либо будет корректно завёрнуто в тор-протокол и отправлено рутером в тор-сеть. Утекать в данном случае нечему по той простой причине, что на целевой машине не содержится никакой информации косвенно связывающей вас с вашей оффлайновой жизнью (см. что писал в предыдущих постах).

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

Файерволл вообще не может надёжно фильтровать по приложениям, читаем unkown'а:

В Linux были "персональные" опции для iptables. Можно было ограничить доступ в сеть конкретной программе по имени. Догадываетесь, почему эту опцию выкинули?
-m owner \-\-cmd-owner '/usr/bin/program'

Осталась только опция ограничения по пользователю, но не по программе.

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

/comment22082 Т.е., вам намекают, что пора "отвыкать видеть": мир на самом деле не таков, каковым он кажется из-за десктопа с Windows.

в упрощеном виде – под VMWare

Слишком упрощёный вид. Переходя от отдельной физической машине к виртуальной вы ослабляете степень защищённости системы во много-много раз: читаем Theo de Raadt'а:

Later in the discussion it was suggested that virtualization should be a priority for security reasons, "virtualization seems to have a lot of security benefits." OpenBSD creator Theo de Raadt strongly disagreed with this assertion, "you've been smoking something really mind altering, and I think you should share it."

/comment32246 Т.е., TdR намекает вам, дословно, на то, что если вы хотите прятаться за виртуальной машиной, думая, что это даёт большую защищённость, то вам слеудет поделиться с народом тем, что вы курите.

И каждое такое изменение прикладных программ, драйверов, конфигураций и т.д. потенциально может создать брешь в Тор-потоке ввиду их несовершенства, ошибок и отсутствия проверки на предмет Тор-совместимости с точки зрения безопасности его самого. Поэтому сниферить придется после каждого такого изменения, а поскольку некоторые изменения происходят незамеченными для пользователя, то большому счету сниферить придется постоянно – с утра до вечера. Когда же работать?

Да, есть люди, которые вручную проверяют все изменения в windows-софте, всё затачивают под себя, все автообновления отключают, и делают много того, что в UNIX доступно "из коробки". У ntldr'а был пост на тему securing windows, SATtva на него неоднократно ссылался позже, когда у народа возникали вопросы, но я пока не смог найти тот его комментарий. Факт в том, что такая затюненная настройка windows простым смертрным недоступна, доступный минимум приведён в том мной ненайденном комментарии, но это всё равно менее защищёно по сравнению с аналогичными усилиями, приложеннымидля защиты opensource-ПО (Linux, etc.).

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

Всё это сущий бред. Это иллюзия защищённости, к которой все так привыкли. Современные хорошие вирусы и трои не ловятся ни одним из антивирусов, никак, причём это концептуальная проблема, и она никак не решается. Единственный способ – противостоять заражению, работая из-под непривелегированного юзера с непривелегированными правами, если же заражение произошло – уже всё, поздняк. Аналогично и с тором: обмануть такую систему "детекта" будет элементарно, а потому и завязываться на такие костыли такому серьёзному проекту как тор и смысла нету.

которая так и не увидит свет для конечного широкого пользователя.

Распространённость использования тор такова, что на этот счёт я совершенно не беспокоюсь. Это сотни тысяч пользователей по всему миру, по некоторым оценкам.

При сферическом автодетекте DNS-утечек в вакууме и полной внешней торификации возникает ряд вопросов:

• Как пользователю разделить, что торить, а что нет? Всё торить? Включая автоапдейты системы? Часто с машине идёт как Tor, так и не-Tor трафик одновременно.
• Если торится не всё, то как анализировать трафик?
• Если у пользователя несколько реально/виртуальных интерфейсов (VPN-ы/Wi-Fi), для каждого описывать политику мониторинга пакетов?
• Трафик в локалке, DHCP, синхронизация времени и пр. тоже могут порождать DNS-запросы. Это всё тоже пользователь будет описывать в конфиге? Может проще вручную все пакеты просмотреть? Хотя да, это же не сделать регулярно.
• При вероятно большом числе ложных срабатываний куда будут посылать разработчики необученных пользователей, которые тут-же подымут панику в рассылке?
• Какими привилегиями должен обладать снифер, чтобы перехватывать трафик на интерфейсах? Рутовыми? И в правилах SELinux для Tor'a ему тоже такие привилегии выделить — слушать все интерфейсы?
• Сниферы и либы по перехвату пакетов — потенциально довольно дырявые приложения, часто страдающие переполнениями буфера с возможностью исполнения произвольного кода. От этого обычно мало кто страдает, потому что их не запускают регулярно и противник не может точно знать, когда жертва запускает снифер, чтобы послать ей набор вредоносных пакетов. Поэтому сниферы на предмет секьюрити патчат неохотно и нерегулярно. А теперь представим, что противнику будет заведомо известно, что у жертвы постоянно висит снифер вместе с Tor'ом. Т.е. разработчикам Tor'а придётся зависеть не только от дыр в openSSL, но и от несекьюрной by-design снифер-либы?

Как пользователю разделить, что торить, а что нет? Всё торить? Включая автоапдейты системы? Часто с машине идёт как Tor, так и не-Tor трафик одновременно.
Если торится не всё, то как анализировать трафик?

В системе с внешним рутером я бы торил весь траффик с заданной машины, включая автоапдейты. Если же тор-клиент запущен локально, то должен ториться весь трафик, порождённым задарнным пользователем (это делается), а трафик остальных пользователей – идти напрямую.

Если у пользователя несколько реально/виртуальных интерфейсов (VPN-ы/Wi-Fi), для каждого описывать политику мониторинга пакетов?

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

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

Куда-то туда.

Трафик в локалке, DHCP, синхронизация времени и пр. тоже могут порождать DNS-запросы. Это всё тоже пользователь будет описывать в конфиге? Может проще вручную все пакеты просмотреть?

Эти пакеты не покинут локальную сеть в схеме с внешным тор-рутером. С схеме же с локальным тор-клиентом выход – только настройка торификации всего трафика от заданного юзера (насколько я знаю, файерволлов под винду с указанным функционалом нет, зато они есть в Linux и BSD).

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

Если весь трафик проходит через рутер, где принудительно заворачивается в Tor, то, я так понимаю, нет и никакого смысла контролировать DNS-утечки.

Если весь трафик проходит через рутер, где принудительно заворачивается в Tor, то, я так понимаю, нет и никакого смысла контролировать DNS-утечки.

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

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

Он хочет, чтобы данные проверялись ещё и до заворачивания в Tor — а не содержится ли в них локального айпишника, имени хоста, списка каталогов или ещё-чего деанонимизирующего, стыренного каким-нибудь джаваскриптом или flash-плэйером. Этот детектор должен для этого уметь распутывать все виды обфускации, обладать искуственным интеллектом и возможно даже проходить тест Тьюринга. Ну и чтобы при этом всё срабатывало превентивно и без ложных срабатываний.

Как говорили одно время, можно грабить корованы...

Unknown:

Шифр Циммермана был взломан Шамиром, с тех пор Циммерман решил не изобретать своих шифров для своей программы PGP, а использовать системы лучших криптографов.

Мне так кажется, или вы действительно среагировали на потенциальный троллинг другого гостя

Был ли троллинг потенциальным или реализовавшимся, является ли спрашивающий другим гостем по отношению к тому или тем же самым, а также кто-как на самом деле среагировал — это всё достоверно одному Случайному Оракулу только известно.
Содержательный ответ на прямой вопрос был дан на первой странице топика, а дальше пошёл выполняться какой-то протокол нулевого знания.

По ссылке http://whoer.net/ext можно посмотреть как джаваскрипт с флешем палят днсы

Использую FF с Torbutton. Никто ничего не палит. Что я делаю не так?

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

Различия между "тор, прокси, сокс, впн, опенвпн и т.д." проявляются на инфраструктурном уровне, их невозможно выявить чисто программными средствами на каком-то сайте (как, например, такой сервис определит, ведутся ли на прокси-узле логи?). Внешне, обычный прокси и Torbutton будет неотличим от Tor и Torbutton, но в случае реализации модели угрозы тушка пользователя ощутит всю разницу на раз.

Оставлю это здесь. На память и вообще как завязку к практически готовому реалити шоу. С интересом следим за результатом или как минимум оглашения двух рабочих методов от анти-ктото-за-тор хантера.

Добавлю это сюда. Интересные вещи рассказывают, оказывается заполненое поле сокс-прокси игнорируется "Одним из самых распространенных вариантов использования tor является связка Tor, Vidalia, Firefox+Torbutton." (хулиган из ссылки мог и забыть сокс в настройках, но хантер утверждает что это глюк лисы из офиц. бандла с торбаттоном) К вопросу о проверки на анонимность: на фтп лиса пойдет не через прописанный сокс интерфейс тора, а напрямую?!

К вопросу о проверки на анонимность: на фтп лиса пойдет не через прописанный сокс интерфейс тора, а напрямую?!

Если сокс не прописан, то, видимо, да. Tb в целом сдизайнен независимо от сокс и прочих проксей – это просто правки внутренних настроек для обезличивания трафика. Я могу захотеть пользоваться тором напрямую, но обезличить трафик, скрывая какая у меня ОС, версия браузера и т.п. – tb также способен на это, безотносительно всякого Tor'а, и это правильное поведение. Есть умолчальные настройки для проксей, которые tb выставляет при инсталле плагина, но их легко можно отредактировать по своему вкусу.

Если сокс не прописан, то, видимо, да.

Но сокс то прописывается торбаттоном всегда (убрать можно это да), вне зависимости от прокси для отдельных протоколов (хттп, хттпс, фтп)
Хантер увидел, что нет прописанного прокси для фтп (а его и не надо для лисы версии от 1.5 и больше, если нужен частично рабочий-пасив фтп бегающий через сокс порт тор клиента, потому как привокси такой запрос просто бы заигнорила) и решил что это бага. Если бага и есть то в том, что был(?) проигнорирован сокс (хантер конечно плавает в предмете, но факты то излагает, если не считать неупомянутого сокса).
В целом не застревая на самой истории с хулиганом (он мог вообще ослика юзать или оперу или еще что, используя только привокси или полипо из состава бандлы или сам собрал), хантер утверждает что его метода с графической ссылкой на фтп "пробивает" базовый бандл скачанный по ссылке с сайта тор проекта.