Раздельный запуск Torbrowser от нескольких пользователей с общим системным Tor-процессом и локальная прозрачная торификация
Цель варианта
- Использовать торбраузер с локальным системным тором вместо поставляемого в составе TBB.
- Осуществить одновременную работу нескольких пользователей системы через системный тор с построением различных цепочек для каждого пользователя посредством подключения к разным портам SocksPort и посредством прозрачной торификации на разные порты TransPort, DNSPort для других програм (опционально — для самого TBB использование прозрачной торификации устарело и не рекомендуется).
- Все пакеты, посланные из под конкретного пользователя торбраузером должны направляться файрволлом только на определённые порты локального хоста, связанные с работой системного тора. Это существенно исключает возможность утечки пакетов при уязвимостях в торбраузере, но существенно не защищает от преднамеренных целевых атак на данную конфигурацию.
Конфигурация тор
Остановите системный тор: /etc/init.d/tor stop. Если в текущей версии с этим есть проблемы, используйте kill.
Закомментируйте в конфиг-файле /etc/tor/torrc опцию SocksListenAddress 127.0.0.1. Она устарела, по умолчанию тор слушает только локальные соединения.
В случае проблем с запуском /etc/init.d/tor start, можно в ответ на соответствующие ошибки добавлять опции:
Для прозрачной торификации по умолчанию и для работы через SocksPort тора используются опции:
Следует добавить нужное количество дополнительных портов:
Поскольку порт 9051 занят, то добавим опции управляющего порта:
Управляющий порт м.б. использован для работы с программой tor-arm, показывающий статистику соединений с сетью tor и позволяющей менять цепочки для всех соединений.
Запуск тор /etc/init.d tor start не должен приводить к ошибкам и должен показывать, что все внесённые в конфиг порты работают нормально.
Настройка iptables
Во многих системах по-умолчанию используется сложный механизм инициализации, конфигурирования и хранения конфигов iptables. Подразумевается, что этот механизм отключен, а вместо него используется шелл-скрипт, который пользователь поддерживает самостоятельно. В Debian/Linux он может быть размещён, например, в /etc/network/if-pre-up.d. Здесь приведены только фрагменты такого скрипта, относящиеся к рассматриваемому варианту торификации.
Закроем снаружи все открытые тор-порты, даже если они принимают только локальные соединения:
# $IPTABLES -- переменная содержит путь к iptables, обычно:
IPTABLES="/sbin/iptables"
# $INET_IFACE -- внешний сетевой интерфейс, обычно:
INET_IFACE="eth0"
# blocked_myports -- пользовательская цепочка для заблокированных портов
iptables -N blocked_myports; iptables -F blocked_myports
for PROTOCOL in TCP UDP; do
for PORT in $(seq 53 58) $(seq 9040 9045) \
$(seq 9050 9055) 9059 9060; do
$IPTABLES -A blocked_myports -i $INET_IFACE -o !lo -p $PROTOCOL \
--dport $PORT -j DROP
done
done
$IPTABLES -A INPUT -p TCP -j blocked_myports
$IPTABLES -A INPUT -p UDP -j blocked_myports
Сделаем исключение из обработки для пакетов идущих на локальный хост.
$IPTABLES -t nat -A OUTPUT -o lo -j RETURN
$IPTABLES -t nat -A OUTPUT -d 127.0.0.1 -j RETURN
Правило для первого анонимного пользователя:
#Разрешим соединение с SOCKS-портом
$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner \
--uid-owner anonym_1 --dport 9051 -j ACCEPT
###Прозрачная торификация [начало]###
#
#Не требуется при работе TBB
#Может быть использована для одновременной работы других програм
#При отсутствии необходимости эти опции м.б. закоментированы
# Прозрачная торификация TCP на порт 9041
$IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonym_1 \
-m tcp -j REDIRECT --to-ports 9041
$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner --uid-owner anonym_1 \
-m tcp --dport 9041 -j ACCEPT
#Прозрачная торификация DNS на порт 54
$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonym_1 \
-m udp --dport 53 -j REDIRECT --to-ports 54
$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p udp -m owner --uid-owner anonym_1 \
-m udp --dport 54 -j ACCEPT
#
###Прозрачная торификация [конец]###
#Больше этому пользователю ничего не разрешено:
$IPTABLES -A OUTPUT -m owner --uid-owner anonym_1 -j REJECT
По аналогии, правило для второго анонимного пользователя (с закоментированной прозрачной торификацией):
$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner \
--uid-owner anonym_2 --dport 9052 -j ACCEPT
#Прозрачная торификация закоментирована
# $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonym_2 \
# -m tcp -j REDIRECT --to-ports 9042
#$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p tcp -m owner --uid-owner anonym_2 \
# -m tcp --dport 9042 -j ACCEPT
#$IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonym_2 \
# -m udp --dport 53 -j REDIRECT --to-ports 55
#$IPTABLES -t filter -A OUTPUT -d 127.0.0.1 -p udp -m owner --uid-owner anonym_2 \
# -m udp --dport 55 -j ACCEPT
$IPTABLES -A OUTPUT -m owner --uid-owner anonym_2 -j REJECT
Разрешим выход наружу самому системному тору:
TOR_UID="debian-tor"
$IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT
Использование tor-arm
Использование пакета Vidalia с системным Tor нецелесообразно из-за полного сворачивания её поддержки. Рекомендуется завести отдельно пользователя, включить его в группу tor-arm и запускать из под него утилиту tor-arm.
Следует избегать запуска tor-arm из под пользователя debian-tor, несмотря на то, что такая рекомендация имеется в пакете и долгое время оставалась неисправленной.
Настройка торбраузера
Начиная с четвёртой версии браузер позволяет автоапдейт. Но в ранних версиях четвёртой ветки стабильность и безопасность этого механизма не гарантировалась. Даже после его стабилизации безопаснее скачивать браузер вручную и проверять контрольные суммы, заверенные подписями GnuPG. Список рекомендуемых версий доступен по ссылке. Скачивание возможно с адреса
Скачанные файлы с подписями и суммами можно разместить в отдельном каталоге и проверить скриптом:
#! /bin/sh
echo > tbbchecklog.txt
sha256sum -c sha256sums-unsigned-build.txt 2>&1 | grep OK >> tbbchecklog.txt
echo >> tbbchecklog.txt
for a in sha256*.asc ; do
gpg --verify $a sha256sums-unsigned-build.txt >> tbbchecklog.txt 2>&1 ;
echo >> tbbchecklog.txt
done
echo >> tbbchecklog.txt
gpg --verify tor-browser-linux64*.asc >> tbbchecklog.txt 2>&1
echo >> tbbchecklog.txt
Перед ручным обновлением рекомендуется экспортировать старые закладки в файл, удалить старый распакованный каталог TBB. Впоследствии возможно импортировать закладки из файла обратно в новый распакованный браузер (вкладки: Bookmarks — Show all Bookmarks — Import and Backup).
Существует вероятность уязвимости в браузере, приводящая к утечке закладок. Поэтому следует рассмотреть целесообразность хранения определённых закладок торбраузера для конкретного анонимного профиля.
В распакованном каталоге TBB удалите расширение запуска Tor из связки:
Запустите TBB:
Зайдите в настройки: Edit → Preferences → Advanced → Network → Settings
И выберите опции:
Для другого пользователя следует выбирать другой порт, в соответствии с настройками файрволла. Следует также обращать внимание на возможность сброса этих настроек при перезапуске.
В адресной строке браузера нужно набрать about:config, для внесения некоторых опций, перечисленных в скрипте запуска start-tor-browser:
# extensions.torbutton.custom.socks_host 127.0.0.1
# extensions.torbutton.custom.socks_port <SocksPort>
# extensions.torbutton.inserted_button true
# extensions.torbutton.launch_warning false
# extensions.torbutton.loglevel 2
# extensions.torbutton.logmethod 0
# extensions.torbutton.settings_method custom
# extensions.torbutton.socks_port <SocksPort>
# extensions.torbutton.use_privoxy false
# app.update.auto false
В торбраузере, начиная с версии 4.5, организована корректная работа с SOCKS-портом, при этом для разных доменов выбираются разные исходящие узлы и существует возможность менять исходящий узел для каждой вкладки при помощи опции New Tor Circuit for this Site в Torbutton. При этом из-за удаления плагина tor-launcher, предназначенного для запуска локального (несистемного) Tor, часть опций tor-button будет недоступна. В связи с этим рекомендуется настраиваеть торбраузер на работу с системным тором именно через SOCKS-порт, а не через прозрачную торификацию. Прозрачная торификация может быть использована для этого же пользователя для работы с другими программами, но ей лучше не пользоваться при повышенных требования анонимности из-за опасениях утечки профилирующих и идентифицирующих данных, а также по другим возможным причинам.
После сохранения изменений следует перезапустить TBB. В разных вкладках на разных доменах TBB должен показывать разные IP-адреса, а при проверке через одинаковые домены — соответственно одинаковые в пределах жизни цепочки. Проверку наличия обновлений можно периодически осуществлять и вручную, например по основной ссылке рекомендуемых версий и скачивания новой версии.
Можно запустить два и более TBB из под разных пользователей одновременно. При одновременной проверке они должны показывать разный IP-адрес исходящих узлов при проверке на одном и том же домене.
При работе из-под одного пользователя для смены профиля рекомендуется перезапустить браузер и сменить все цепочки программной tor-arm или отправкой сигнала системному тор-процессу.
комментариев: 9796 документов: 488 редакций: 5664
Исходная ветка для общих обсуждений, не относящихся только к этому конкретному варианту.
Уже и смену настроек прокси сломали? 1:1? Работало же. Никто не хочет написать баг-репорт?
> Это существенно исключает возможность утечки пакетов при уязвимостях в торбраузере, но существенно не защищает от преднамеренных целевых атак на данную конфигурацию.
Оно? Медведь стучится в дверь ко мне...
P.S. Большой пасибыч за сей труд, unknown!!!
комментариев: 9796 документов: 488 редакций: 5664
У меня выглядит как 1:1. Пожалуйста, подтвердите, поэкспериментируйте. Нужно или добиться от TBB нормальной работы через другой SOCKS-порт, или включения прозрачной торификации (так чтобы он работал не через SOKS-порт). Если не получиться — составлять баг-репорт. Или кто-нибудь, подскажите как (и можно ли?) поменять порт назначения файрволлом в данном случае. Потому что в других цепочках (в смысле chains, для iptables, а не тора) модуль owner не работает.
Кстати, двойное заворачивание в тор, как кто-то предлагал в альтернативном варианте — потенциально опасная штука. Можно завернуть цепочку Host 1 — Host 2 — Host 3 в цепочку Host 3 — Host 2 — Host 1 или хотя бы частично обратную. Хотя это маловероятно и для скачивания статистики несущественно.
Безопасность через неясность? Нет, смысла усиливать это неясностью нет. Заведомо слабые места игнорируются в исследовательских, а не практических целях. Возможно как-то поднять псевдоустройство или прокси на локальном хосту с правами пользователя и таким способом обмануть файрволл.
Пока медведь, да.
Помимо концепции медведя пришла в голову концепция отличия практической/коммерческой безопасности от теоретической/исследовательской. В исследовательской нормальное дело улучшать стойкость самого сильного (или вообще любого отдельного) звена, даже если остальные — слабые. Будем изучать и улучшать создание невзламываемых замкОв, даже если при этом мы умеем делать только картонные двери. Зато, когда будет изобретён способ создания прочных дверей к ним уже будут созданы прочные замки и готовый результат можно будет выпускать в широкую практику.
Нужно поэкспериментировать, по идее все цепочки на разных портах всё равно построятся разные. Или выяснить, например это влиет только на запрос скрытого сервиса — выяснения точки встречи, но не на цепочки.
Ну хоть какое-то начало положено, а то почти 9 месяцев ничего родить не получалось :-)
Интересный вопрос, надо экспериментировать. Теоретически rdr + pass in/out должно отрабатывать. Есть ещё функционал в route-to, но я плохо понимаю, что именно оно делает. В rdr меня смущает, что pass out не будет использоваться, т.е. пакеты от всех пользователей (идущие на некоторый порт) будут перенаправляться на заданный порт. А на стадии pass in опция user ловит только то, от имени кого запущен сервис, а не то, кто послал. Впрочем, почти уверен, что сделать можно.
> Пожалуйста, подтвердите, поэкспериментируйте. Нужно или добиться от TBB нормальной работы через другой SOCKS-порт, или включения прозрачной торификации
Позже. Прозрачная торификация не заработает почти точно, т.к. в последних 2-3 версиях она уже не работала. Прокси стоит проверить.
> Можно завернуть цепочку Host 1 — Host 2 — Host 3 в цепочку Host 3 — Host 2 — Host 1 или хотя бы частично обратную.
Как ноды в цепочке моментально смогут понять, что реализовался именно описанный случай (без корреляций и статистики)?
> Возможно как-то поднять псевдоустройство или прокси на локальном хосту с правами пользователя и таким способом обмануть файрволл.
Если Tor-рутер на физически другой машине, это сильно упрощает настройку. А так... ssh -w root@127.0.0.1 позволяет сделать хоть сто дополнительных псевдоинтерфейсов, но это грязный и перегруженный метод. Есть и другие способы создания и работы с псевдоинтерфейсами, если всё локально. Возможно, какой-нить VLAN или просто насоздавать дополнительных IP-алиасов для lo и фильтровать в зависимости от IP (127.0.0.1, 127.0.0.2 и т.д.).
комментариев: 9796 документов: 488 редакций: 5664
скорее всего никак.
В способе с двойным заворачиванием в Tor не может, а тут... надо курить ваши правила. Виртуалка защищает, прежде всего, от вот этого, а не от обходов настроек firewall'а или от ошибки с повышением привелегий.
Ну и, раз пошла такая пьянка,
режьтеперенесите этот[создать] топик в общую копилку сакральных знаний[создать] (или хотя б ссылку поставьте), а по виртуалкам пока мало информации.P.ک.: «Слабый нетбук с беспроводным инетом» как раз и есть идеальный шанс организовать на нём wifi-Tor-рутер :)
комментариев: 9796 документов: 488 редакций: 5664
режьтеперенесите этот топик в общую копилку сакральных знанийЕсли готовы его поддерживать неанонимно, то распишитесь своим ключом и я (или SATtva, потому как с правами при переносе у меня часто бывают обломы) его перенесу, передав вам права на его владение как зарегистрированному пользователю.
комментариев: 9796 документов: 488 редакций: 5664
Скопировал[создать]. Пока сделал доступ группе OpenPGP, владение вам, дальше можете сами изменить доступ.
Скажем, если идет утечка каких-то пакетов под юзером, прозрачно торифицированным под другим SocksPort'ом, то они будут заворачиваеться фаерволом уже в этот порт, а не в 9050, и идти по другой цепочке Tor-нод.
Насколько это угрожает?
P.S. Когда я тестил FF и громоптицу у них вроде утечек не было, вот tkabber давал неск. пакетов dns-запросов утечки, можно было видеть их завернутыми в Tor фаерволом через iptables -L -v -t nat. Но вдруг?
комментариев: 1515 документов: 44 редакций: 5786
> Скопировал. Пока сделал доступ группе OpenPGP, владение вам, дальше можете сами изменить доступ.
Спасибо. Уже сменил.
> А как может угрожать с точки зрения возможного профилирования то, что TBB и при прозрачной торификации работает через порт 9050?
Не очень понятно, о чём речь.
- Чем они нестандартней, тем, формально, больше профилирования, но это всё равно попытка перехитрить самого себя: обычному пользователю доступно так много информации, что вряд ли список открытых портов здесь что-то изменит.
- Можно рассуждать и по-другому: пусть есть массовый эксплоит, опирающийся на то, что у всех всё запущено стандартно и на стандартных портах, тогда, поменяв станадртый порт, можно будет уберечься от такой массовой стандартизированной атаки (и такое уже было).
Хотя, если подходить к вопросу серьёзно, практически пустые спекуляции — хоть A, хоть B. Без виртуальной машины проблема вообще не решается, да и с ней будет защита не от профилирования, а от утечки информации о том, что анонимный и неанонимный профиль работают физически на одной и той же машине (операционной системе).комментариев: 9796 документов: 488 редакций: 5664
Скорее всего, Гость (24/06/2012 23:08) не интересовался утечкой списка открытых изнутри портов в случае эксплойта. Хотя это замечание тоже интересно. Речь скорее о том, чтобы при утечках/сбоях настройки безо всяких эксплойтов цепочки разных пользователей между собой не перепутались.
Следует различать работу через SOCKS порты: 9050, 9051 (в нашем примере он вместо управляющего), 9052, 9053 и т.д. — это не прозрачная торификация. Это прямое соединение с тор-демоном.
Перенаправление трафика опцией iptables-REDIRECT на локальные TransPort 9040, 9041, 9042, и т.д. и DNSPort 53, 54, 55 и т.д. — это прозрачная торификация. Прозрачная торификация работает без нареканий для тех программ, которые не работают через SOCKS, а пытаются напрямую слать пакеты в инет. Или они получат цепочку на своём порту, или по каким-то причинам не смогут работать вообще.
Что касается не прозрачной торификации, а работы напрямую через SOCKS. Здесь пакеты шлются не во внешнюю сеть, а сразу на локалхост, поэтому и редирект портов для них не работает. К сожалению, я не знаю как его сделать в этом случае локально с применением модуля owner.
Если программа работает через SOCKS и настроена скажем на порт 9051, а пытается соединиться через порт 9050, а в файрволле это для данного пользователя не разрешено, то она и не сможет это сделать. Общее правило, разрешающее для всех пользователей выход через 9050 — временное из-за проблем с TBB и оно действительно может привести и к смешиванию цепочек при аналогичных дефектах в других программах, соединяющихся с тором через SOCKS. Как только проблему с TBB удасться решить, нужно будет разрешить для каждого пользователя свой единственный SOCKS-порт. Единственное, что при этом может быть, это как в случае с багом в торбраузере с утечками DNS. Торбраузер получал бы цепочки через SOCKS-порт, а утечка DNS проходила бы через прозрачно торифицированный DNS-порт, но оба должны быть уникальными для данного пользователя так, чтобы не смешиваться с чужими портами, что будет блокироваться настройками файрволла. Пока что из-за общего порта 9050 это не так.
Т.е. в идеале, если бы не баги в TorButton, у каждого пользователя должна быть уникальная тройка SOCKS, Transport и DNS портов. Файрволл должен разрешать (строго на локалхост) прямое соединение для первого и прозрачную торификацию для двух других. Если происходит слёт настроек на другой порт или утечки, то всё должно продолжать работать или только в рамках этих трёх портов или не работать никак.
комментариев: 9796 документов: 488 редакций: 5664
Уже есть.
Torbutton always reset SOCKS port to 9050 — якобы пофиксили 7 месяцев назад. Похоже, что или недофиксили, или снова поломали.
Enhance "Transparent Torification (Requires custom transproxy or Tor router)" in Tor Button. — а эту опцию активно пилят, но пока не могут сделать как надо.
Vidalia's "Avoid public network" dialog should ask about tor router? — поддержку тор-роутеров и прозрачной торификации возможно включат и в видалию, хотя это и не в приоритете.
Exits should block reentry into the tor network — рано или поздно экситы будут блокировать двойное заворачивание в тор, так что рассчитывать на этот костыль для развязывания TBB не стоит.
replace iceweasel with Torbrowser? — проект TAILS изучает возможность перехода с патченного Iceweasel на прозрачно торифицированный TBB и возможность сборки deb-пакетов для Debian/Debian-based систем.