Раздельный запуск 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
Т.е. игр с включением кого-то в группу
не избежать?
Дать всем читать чужие хэши паролей? Очень умно.
Помимо собственно аутентификации разделение по цепочкам должно работать и во множестве иных случаев, так что огород имеет некоторый смысл. Во многих конфигурациях (но не во всех) какой-либо авторизации можно вообще избежать, т.к. всё будет работать искаробки.
комментариев: 9796 документов: 488 редакций: 5664
Речь шла и об управлении тором, и просмотре его состояния через управляющий порт. Транспортные и сокс-порты здесь не причём. Для работы через управляющий порт есть разные механизмы: беспарольный доступ (не рекомендуется, если его уже не убрали), парольный доступ (хэш от пароля хранится в тор-конфиге), доступ к cookie, доступ к fifo или управляющим сокетам, использование шифрованного cookie (с этим не разбирался, да оно не особо поддерживается).
Это лучше, чем запускать tor-arm с правами тор или давать доступ к управлению тором тем пользователям, которые из под него же и ходят и могут словить эксплойт в торбраузере.
Из всех способов что вы там перечислили, для стандартного случая – один пользователь на localhost – подходят толька два. Это подлючение к разным портам Tor, что предлагается в этой теме, и аутентификация SOCKS. Есть ещё один подходящий, который не перечислен, это разделение по хостам назначения (IsolateDestAddr). Но он имеет недостатки.
1. Ненадёжен, т.к. разные пользователи могут обратиться к одному ресурсу.
2. Изменится стандартное поведение торбраузера. Сайты могут содержать десятки ссылок на другие сайты. Для каждого из них будет создаваться своя цепочка, и на выходе будут разные IP-адреса.
3. Ухудшится производительность сети, т.к. создание цепочек требует ресурсов и времени.
Не всем, а только Tor. Без пароля есть GSSAPI, но что о нём говорить, если они даже username толком сделать не могут.
Вариант с аутентификацией SOCKS безопасней, чем прозрачная торификация для пользователя. Если у пользователя что-нибудь заведётся, то оно не сможет прозрачно выходить наружу.
Когда есть универсальный и стандартный способ безопасного доступа к порту через SOCKS аутентификацию, какой смысл во всех этих наворотах?
комментариев: 9796 документов: 488 редакций: 5664
Но можно сделать и ещё лучше, так получается? Т.е. каков самый безопасный вариант из поддерживаемых?
Я думаю, можно считать полустандартным случаем виртуалки, где каждая гостевая ОС сидит на своём IP или в своём диапазоне IP-адресов. Тут разделение по цепочкам для Tor'а, запущенного в хостовой ОС или отдельной гостевой заработает искаробки. Вроде даже в винде и VMware это работает как надо, хотя сетевой софт в винде очень тупой.
Никто не спорит. Вообще, моё IMHO — гики могли бы вообще обойтись без аутентификации, т.е. кто к какому порту может иметь право доступа, полностью регулируется фильтрацией на lo. Понятно, что разработчики должны учитывать в основном интересы домохозяек, поэтому советовать всем курить правила iptables/pf не могут.
Какое это имеет значение? Аутентификация осуществляет безопасный доступ к порту и устанавливает авторизованный TCP-сеанс. Какие действия потом совершаются в этом сеансе, несущественно.
Аутентификация SOCKS более тонко контролирует доступ. При фильтрации только средствами фаирвола, от имени пользователя могут запускаться все утилиты системы и они будут прозрачно проходить через Tor без каких-либо настроек. При наличии контроля доступа к Tor на уровне сеанса, приложения должны запускаться специальным образом. Потенциально вредоносное ПО тоже может пройти через Tor, но его создатели должны заранее знать в деталях, как авторизоваться на Tor-клиенте. Это конечно не является принципиальным ограничением, но довольно практичной подстраховкой.
Не только. Например, через Control Port можно посмотреть информацию о построенных цепочках, статистике Tor и ещё кучу всего, как я понимаю. Ни одному нормальному обычному проложению, работающему через Tor, знать это нет необхрдимости — это своего рода полный административный доступ к Tor. Вроде даже можно параметры конфига на лету менять и т.д.
Если они будут использовать правильный адрес (127.0.0.1:порт) и понимать, что это SOCKS-прокси, то да. Кстати, порт можно сделать нестандартным. Прозрачной торификации может не быть — просто будет зарезан весь трафик, который идёт не на конкретный 127.0.0.1:порт.
Не нахожу противоречий со сказанным выше. Для доступа к контрольному порту тоже можно создать отдельного пользователя с паролем.
Интерфейс и порт на котором прячется Tor элементарно находятся сканированием. Сравните со случаем, когда для доступа к Tor-клиенту нужно ввести имя пользователя и пароль (или найти их где-то в настройках запуска). Уровень проблемы для создателей злонамеренной программы совершенно другой.
Да, для любителей андроидов тут тоже есть интересные новости. Уязвимы, похоже, все конфигурации, при которых
Но некоторым сколько ни говори, что идеологически прозрачная торификация — зло, не согласятся. Дело даже не в конкретных схемах атаки, а в том, что есть понятие wrong practize, а опыт говорит о том, что wrong practize рано или поздно превращается в vulnerability и leak, причём, возможно, очень неожиданным образом, какой никто не мог предположить (как в этом случае).
А вот ещё одно сообщение в рассылке (символично, что оставшееся без ответа):
Т.е. ядро Linux сбрасывает uid у пакетов. На самом деле, там очень тонкая bug2bug2bug-ситуация с тем, как ведёт себя Tor, каковы спеки на TCP и каково поведение ядра Linux. Я с этим столкнулся, когда обнаружил, что у меня на lo масса пакетов в этих правилах блочится. У всех из них был потерян uid, судя по логам. Поначалу я думал, что что-то нужное неразрешено, что надо позволить Tor'у самому коннектиться к Tor Browser'у... но всё оказалось проще.
Есть несколько частичных воркэраундов, но они лишь частичные: часть пакетов можно подобрать, если разрешить ответы пакетами, не имеющими uid'а, но это не отловит все блокируемые пакеты. Пытался добавлять --socks-exist и др. опции. Ещё поигрался с установкой mark'а на соединение — ещё немного было отловлено, но тоже не всё. В принципе, можно не искать воркэраунды и мириться с тем, что значительная часть пакетов блочится на lo (позже увидел, что не только на lo, но на eth их сравнительно мало), но это, подозреваю, выливается в некоторое замедление связи и глюки с ней. Естественно, если убрать uid (owner) из правил, то всё решается и ничего не блочится, но тогда сама фильтрация на lo теряет смысл — любой зловред сможет воспользоваться этой дырой.
Может быть, этот круг проблем — дажее более глубокая вещь, т.е. утечка на уровне дизайна, но, так или иначе это баг: ядро сбрасывает uid, пытаясь ответить за процесс, породивший соединение (но уже умерший?), в итоге пакет, как не связанный ограничением по uid'у, может потенциально уйти в сеть. Номинально этот пакет ничего такого в себе не несёт, но он связан с исходным соединением, а этого оказывается достаточно для деанона. Не хочу быть оракулом, но, скорей всего, это баг ядра Linux. Да-да, уже второй, первый — тут.
Это ещё одно напомнание тем, кто тут так много орал на BSD. Как и предполагалось, досаточно плотнее ковырнуть Linux, и тут же вылезут ворохи проблем. Оказывается, не помогает ни его распространённость, ни стадо макак-тестировщиков. Уж насколько больше я игрался в жизни с PF, но такого маразма, да ещё вылазящего после первых же нетривиальных правил файерволла, я там не видел. Кстати, не забудьте отдблагодарить Линуса. Судя по всему, он лично туда
бэкдорыкоммитит.P.S. Из внутренних обсуждений:
комментариев: 9796 документов: 488 редакций: 5664
Дискуссия там завершилась этим:
Вот и у меня этого бага не наблюдалось.
В общем да, если считать, что исходно стойкой утилиты («примитива безопасности») не существует и надо иметь перестраховку на случай бага в ней. Но в предложенных мной правилах утеря UID приведёт к тому, что пользователь не соединится ни с локальным tor'ом, ни отправит пакет в сеть.