id: Гость   вход   регистрация
текущее время 22:30 28/03/2024
Владелец: unknown (создано 24/06/2012 17:27), редакция от 12/08/2015 22:34 (автор: unknown) Печать
Категории: софт, анонимность, tor
http://www.pgpru.com/Библиотека/Руководства/СетеваяАнонимность/ПродвинутоеИспользованиеTorвUnix/РаздельноеИспользованиеTorbrowserсСистемнымTorиПрозрачнаяТорификация
создать
просмотр
редакции
ссылки

Раздельный запуск Torbrowser от нескольких пользователей с общим системным Tor-процессом и локальная прозрачная торификация


Оглавление документа:

Цель варианта


  1. Использовать торбраузер с локальным системным тором вместо поставляемого в составе TBB.
  2. Осуществить одновременную работу нескольких пользователей системы через системный тор с построением различных цепочек для каждого пользователя посредством подключения к разным портам SocksPort и посредством прозрачной торификации на разные порты TransPort, DNSPort для других програм (опционально — для самого TBB использование прозрачной торификации устарело и не рекомендуется).
  3. Все пакеты, посланные из под конкретного пользователя торбраузером должны направляться файрволлом только на определённые порты локального хоста, связанные с работой системного тора. Это существенно исключает возможность утечки пакетов при уязвимостях в торбраузере, но существенно не защищает от преднамеренных целевых атак на данную конфигурацию.

Конфигурация тор


Остановите системный тор: /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 90559059 9060do

        $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 или отправкой сигнала системному тор-процессу.


 
На страницу: 1, ... , 5, 6, 7, 8, 9, ... , 16 След.
Комментарии [скрыть комментарии/форму]
— unknown (29/05/2014 09:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В системном Tor это надо настраивать в конфиге самостоятельно.
— Гость (29/05/2014 12:11)   <#>
А зачем эти куки и хеши, когда есть стандартные методы SOCKS-аутентификации. Для username достаточно дать Tor доступ на чтение /etc/shadow, права root не нужны. Проблема с изоляцией цепочек решается без велосипедов, которые здесь предлагаются. Поддерживать такой колхоз весьма затруднительно. Кто-нибудь в курсе, в новых версия Tor сделали наконец нормальную SOCKS-аутентификацию, username работает?
— Гость (30/05/2014 04:18)   <#>

Т.е. игр с включением кого-то в группу

Рекомендуется завести отдельно пользователя, включить его в группу tor-arm и запускать из под него утилиту tor-arm.

не избежать?


Дать всем читать чужие хэши паролей? Очень умно.


Помимо собственно аутентификации разделение по цепочкам должно работать и во множестве иных случаев, так что огород имеет некоторый смысл. Во многих конфигурациях (но не во всех) какой-либо авторизации можно вообще избежать, т.к. всё будет работать искаробки.
— unknown (30/05/2014 09:51, исправлен 30/05/2014 09:51)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Речь шла и об управлении тором, и просмотре его состояния через управляющий порт. Транспортные и сокс-порты здесь не причём. Для работы через управляющий порт есть разные механизмы: беспарольный доступ (не рекомендуется, если его уже не убрали), парольный доступ (хэш от пароля хранится в тор-конфиге), доступ к cookie, доступ к fifo или управляющим сокетам, использование шифрованного cookie (с этим не разбирался, да оно не особо поддерживается).



Это лучше, чем запускать tor-arm с правами тор или давать доступ к управлению тором тем пользователям, которые из под него же и ходят и могут словить эксплойт в торбраузере.

— Гость (30/05/2014 09:57)   <#>
Помимо собственно аутентификации разделение по цепочкам должно работать и во множестве иных случаев, так что огород имеет некоторый смысл.

Из всех способов что вы там перечислили, для стандартного случая – один пользователь на localhost – подходят толька два. Это подлючение к разным портам Tor, что предлагается в этой теме, и аутентификация SOCKS. Есть ещё один подходящий, который не перечислен, это разделение по хостам назначения (IsolateDestAddr). Но он имеет недостатки.

1. Ненадёжен, т.к. разные пользователи могут обратиться к одному ресурсу.

2. Изменится стандартное поведение торбраузера. Сайты могут содержать десятки ссылок на другие сайты. Для каждого из них будет создаваться своя цепочка, и на выходе будут разные IP-адреса.

3. Ухудшится производительность сети, т.к. создание цепочек требует ресурсов и времени.

Дать всем читать чужие хэши паролей?

Не всем, а только Tor. Без пароля есть GSSAPI, но что о нём говорить, если они даже username толком сделать не могут.

Вариант с аутентификацией SOCKS безопасней, чем прозрачная торификация для пользователя. Если у пользователя что-нибудь заведётся, то оно не сможет прозрачно выходить наружу.
— Гость (30/05/2014 10:01)   <#>
Речь шла и об управлении тором, и просмотре его состояния через управляющий порт. Транспортные и сокс-порты здесь не причём. Для работы через управляющий порт есть разные механизмы: беспарольный доступ (не рекомендуется, если его уже не убрали), парольный доступ (хэш от пароля хранится в тор-конфиге), доступ к cookie, доступ к fifo или управляющим сокетам, использование шифрованного cookie (с этим не разбирался, да оно не особо поддерживается).

Когда есть универсальный и стандартный способ безопасного доступа к порту через SOCKS аутентификацию, какой смысл во всех этих наворотах?
— unknown (30/05/2014 11:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
SOCKS для транспортного уровня, а протокол контроля вынесен отдельно, на отдельный тип порта, т.к. выполняет много других функций.
— Гость (30/05/2014 12:24)   <#>

Но можно сделать и ещё лучше, так получается? Т.е. каков самый безопасный вариант из поддерживаемых?


Я думаю, можно считать полустандартным случаем виртуалки, где каждая гостевая ОС сидит на своём IP или в своём диапазоне IP-адресов. Тут разделение по цепочкам для Tor'а, запущенного в хостовой ОС или отдельной гостевой заработает искаробки. Вроде даже в винде и VMware это работает как надо, хотя сетевой софт в винде очень тупой.


Никто не спорит. Вообще, моё IMHO — гики могли бы вообще обойтись без аутентификации, т.е. кто к какому порту может иметь право доступа, полностью регулируется фильтрацией на lo. Понятно, что разработчики должны учитывать в основном интересы домохозяек, поэтому советовать всем курить правила iptables/pf не могут.
— Гость (30/05/2014 13:13)   <#>
SOCKS для транспортного уровня, а протокол контроля вынесен отдельно, на отдельный тип порта, т.к. выполняет много других функций.

Какое это имеет значение? Аутентификация осуществляет безопасный доступ к порту и устанавливает авторизованный TCP-сеанс. Какие действия потом совершаются в этом сеансе, несущественно.

кто к какому порту может иметь право доступа, полностью регулируется фильтрацией на lo

Аутентификация SOCKS более тонко контролирует доступ. При фильтрации только средствами фаирвола, от имени пользователя могут запускаться все утилиты системы и они будут прозрачно проходить через Tor без каких-либо настроек. При наличии контроля доступа к Tor на уровне сеанса, приложения должны запускаться специальным образом. Потенциально вредоносное ПО тоже может пройти через Tor, но его создатели должны заранее знать в деталях, как авторизоваться на Tor-клиенте. Это конечно не является принципиальным ограничением, но довольно практичной подстраховкой.
— Гость (30/05/2014 14:16)   <#>

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


Если они будут использовать правильный адрес (127.0.0.1:порт) и понимать, что это SOCKS-прокси, то да. Кстати, порт можно сделать нестандартным. Прозрачной торификации может не быть — просто будет зарезан весь трафик, который идёт не на конкретный 127.0.0.1:порт.
— Гость (30/05/2014 20:11)   <#>
Например, через Control Port можно посмотреть информацию о построенных цепочках, статистике Tor и ещё кучу всего, как я понимаю. Ни одному нормальному обычному проложению, работающему через Tor, знать это нет необхрдимости — это своего рода полный административный доступ к Tor.

Не нахожу противоречий со сказанным выше. Для доступа к контрольному порту тоже можно создать отдельного пользователя с паролем.

Если они будут использовать правильный адрес (127.0.0.1:порт) и понимать, что это SOCKS-прокси, то да. Кстати, порт можно сделать нестандартным. Прозрачной торификации может не быть — просто будет зарезан весь трафик, который идёт не на конкретный 127.0.0.1:порт.

Интерфейс и порт на котором прячется Tor элементарно находятся сканированием. Сравните со случаем, когда для доступа к Tor-клиенту нужно ввести имя пользователя и пароль (или найти их где-то в настройках запуска). Уровень проблемы для создателей злонамеренной программы совершенно другой.
— few_days (21/07/2014 22:55)   <#>
Вы ещё пользуетесь прозрачной торификацией всех соединений? Тогда деанон уже тут:

I've discovered that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances. ... The bug can be triggered either by a remote server closing a connection, or by restarting the local tor client. ... It sends this packet first as the UID of the app in question, and if that fails, it resends it as a blank UID (the kernel itself). ...

That packet has leaked past the iptables firewall rules, and past the transproxy rules. It went straight to Google. I have noticed several Android apps (including Firefox, F-Droid, and many Google apps and Android services) that allow their sockets to sit in CLOSE_WAIT upon remote close while transproxied, and they all leak packets in this case, which happens frequently in normal usage. ...

None of the transproxy documentation I could find mentions this issue, nor suggests any additional safety rules. This means every transproxied Tor user is unwittingly leaking packets, at least some of the time. Sorry to be the bearer of bad news.

Да, для любителей андроидов тут тоже есть интересные новости. Уязвимы, похоже, все конфигурации, при которых

sandboxes apps/OS/vm behind a firewall that redirects all tcp and dns traffic into tor Trans* options and drops the rest.

Но некоторым сколько ни говори, что идеологически прозрачная торификация — зло, не согласятся. Дело даже не в конкретных схемах атаки, а в том, что есть понятие wrong practize, а опыт говорит о том, что wrong practize рано или поздно превращается в vulnerability и leak, причём, возможно, очень неожиданным образом, какой никто не мог предположить (как в этом случае).

А вот ещё одно сообщение в рассылке (символично, что оставшееся без ответа):

22% of all packets (it is 11% of bytes of that traffic) sent by tor relay was uid not set to "debian-tor".

Т.е. ядро 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. Из внутренних обсуждений:

— Будет ли когда-нибудь такое, что ядро заморозят и начнут вычищать баги?
— Я тебе скажу страшное: это не поможет. Сейчас уровень понимания сделанного упал так низко, что, убирая баги, они будут вносить новые — это еще хуже. А-ля openssl и heartbleed. Ну, и трехбуквенные конторы подсуетятся тут же. Бэкдор лучше всего запрятать под исправление бага. :) Могу пояснить: потому что исправление видно, а его косвенные эффекты — совсем нет. В общем, кое-чему явно не хватает осинового кола, хотя, может быть, всех сложные системы (и BSD в том числе) еще не начали ковырять серьезно. Последнее время, если ты заметил, баги носят системный характер.
— Гость (22/07/2014 00:13)   <#>
UID имеют вроде только SYN-пакеты (в UDP просто первый пакет)
— Гость (22/07/2014 02:49)   <#>
Типичные зарезанные пакеты (очень много их) выглядят вот так:

— unknown (22/07/2014 10:21, исправлен 22/07/2014 10:21)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Дискуссия там завершилась этим:



Is it only happening in Ubuntu 13.04. I can not reproduce this in Ubuntu 12.04 (nothing in tcpdump). I've updated my iptables rules anyway, just incase. Thanks for sharing them!

Вот и у меня этого бага не наблюдалось.



В общем да, если считать, что исходно стойкой утилиты («примитива безопасности») не существует и надо иметь перестраховку на случай бага в ней. Но в предложенных мной правилах утеря UID приведёт к тому, что пользователь не соединится ни с локальным tor'ом, ни отправит пакет в сеть.

На страницу: 1, ... , 5, 6, 7, 8, 9, ... , 16 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3