id: Гость   вход   регистрация
текущее время 15:34 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, ... , 8, 9, 10, 11, 12, ... , 16 След.
Комментарии [скрыть комментарии/форму]
— Гость (02/02/2015 18:17)   <#>
Тогда странно, что они добавляют «то, не знаю что» в стабильную ветку релиза, а не в альфу.
— Гость (15/02/2015 11:18)   <#>

Это плохо, но не настолько фатально, потому что уже существующие соединения не будут разорваны по сигналу kill -1. Внешний наблюдатель не заметит вообще ничего, а имеющий доступ к построенным цепочкам на экситах может ловить дополнительные крохи на корреляциях. По-простому говоря, если под каким-то юзером запущен SSH- или jabber-клиент, внезапного дисконнекта от kill -1 на Tor они не испытают.
— Гость (15/02/2015 14:03)   <#>
Время от времени апгрейжу свой pf2iptabels-транслятор DSL iptables specific language. Подскажите кто-нибудь, как победить кусок скрипта:
#/bin/sh
 
allow_in_tor(){
    # This function allows incoming tor traffic for tor user and the corresponding
    # replies. It also includes bug workaround to allow replies from user root.
    # The function accepts list of ports as argument.
 
    local allargs="$*"
    argslines=`echo $allargs | tr ' ' '\n'`
 
    intf=`echo $argslines | sed -n 1p`
    srcIP=`echo $argslines | sed -n 2p`
    dstIP=`echo $argslines | sed -n 3p`
    dstPORTs=`echo $argslines | sed '1,3d;$d'`
    our_user=`echo $argslines  | sed -n $p`
 
    echo $dstPORTs | while read $dstPORT ; do
        $pass_in  $on_i $intf $proto tcp $from $srcIP \
            $to $dstIP $dt_port $dstPORT
        $pass_out $on_o $intf $proto tcp $from $dstIP $st_port $dstPORT \
            $to $srcIP $user $our_user $keep_state
        $pass_out $on_o $intf $proto tcp $from $dstIP $st_port $dstPORT \
            $to $srcIP $user root $keep_state
    done
}
 
# Где-то потом вызываем эту функцию:
allow_in_tor lo $lh $lh 9050 9060-9070 9075 debian-tor
Дело в том, что количество портов переменное. Хочется первые несколько агументов функции загнать в одни перменные, последнюю в имя юзера, а всё, что между ними, представить в виде списка портов, который можно в while-цикле подсунуть на все нужные правила iptables.

Проблема в том, что в строке
argslines=`echo $allargs | tr ' ' '\n'`
всё, что после пайпа, тупо игнорируется. Строку переменных не удаётся преобразовать в столбец переменных. В командной строке zsh это работает:
$ F="aa bbb cc"           
$ G=`echo $F |tr ' ' '\n'`
$ echo $G                 
aa
bbb
cc
но внутри скрипта (даже в zsh) уже нет:
#/bin/zsh
 
myfun(){
        local origarg="$*"
        newarg=`echo $origarg | tr ' ' '\n'`
        echo $newarg
}
 
myfun aa bbb cc
(переменная $newarg не преращается в столбец).

Как решать такую задачу, причём наименее костыльно? И желательно сделать всё на чистом /bin/sh, т.к. иначе полезут проблемы с совместимостью с другими скриптами. Мне в голову приходит только идея присваивать фиксированные переменные по их номеру следования (первая, вторая, третья и последняя), а потом писать for-цикл по номерам переменных от четвёртой и до предпоследней. Будет грязно, сложно и некрасиво, даже если взлетит. Как-то проще можно?
— Гость (15/02/2015 15:14)   <#>
Наименее костыльно было бы воспользоваться bash arrays. Ну да ладно, попробуем без них:



Дальше сложнее. Не хотите сделать our_user четвёртым аргументом, а не последним? Если нет, придётся в цикле проверять нечто вроде


или изобретать счётчик для i от 1 до `expr $# – 1` и доставать аргумент под данным номером при помощи описанного выше костыля.

И вообще, когда логика аргументов достигает такой сложности, стоит обратиться к getopts (есть, как минимум, в dash), а не костылять строковые операции.
— unknown (15/02/2015 16:56, исправлен 15/02/2015 17:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Игнорируйте штатный системный скрипт для iptables и поместите в /etc/network/if-pre-up.d свой, который всё делает сам, сбрасывая для iptables все предыдущие настройки. Или руки Леннарта уже дотянулись до вашей системы и systemd такое больше не позволяет?


Иначе, я не пойму, чего вы такое сложное хотите сделать? Не хотите массивы, ну напишите так:

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

— Гость (16/02/2015 08:14)   <#>

Спасибо, интересный факт, не знал о таком трюке.


Всё можно, но в условном псевдоDLS используется PF-подобный синтаксис, там по унификации юзер идёт последним (есть исключения) во всех правилах файерволла. Не хотелось бы делать исключение для данной функции.


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

изобретать счётчик для i от 1 до `expr $# – 1` и доставать аргумент под данным номером при помощи описанного выше костыля.


Если бы я знал шелл получше, можно было бы всё переписать на что-то иное, но сейчас в одном месте меняешь интерпретатор на zsh — в другом месте лезут проблемы и всё отваливается, причём я не могу легко сказать, из-за чего. Тут уже не знаешь, с чем будет проще разобраться. Ну, и стандартный аргумент в пользу /bin/sh — портируемость между системами.


Я не пользуюсь системной автоматикой вообще, считая её небезопасной. У меня система сама не поднимает сетевые интерфейсы. Если это нужно, я выполняю вручную определённый скрипт. Если нужно запустить правила iptables, то тоже, и т.п.


Дотянулись, но мы тоже не лыком шиты.


Хотелось сделать красиво, а не подпирать костыли костылями. ☺


Хотелось написать относительно универсальное решение для параноиков, вынести всю труху и низкоуровневую грязь в отдельный скрипт, чтобы в основном скрипте всё было красиво, понятно и концептуально, не нужно было путаться, копипастить и городить очередные циклы на лету. По-простому говоря, iptables, в отличие от pf — не policy based filtering, а мне хочется именно этого. Я не хочу думать по 100 раз, как каждый пакет проходит через этот конечный автомат, и что в нём меняется. Даже зная, как это работает, рано или поздно я совершаю ошибку в очередной копипасте. Хотелось бы этого избежать.

Я очень не люблю выкладывать сырые недоделанные наработки, но, наверно, рискну, потому что иначе это может висеть во внутренних черновиках годами. Там вам после ознакомления с документом будет более понятно, в чём цель. Я поглядел, кто как скрипты iptables тут на форуме городит, и ужаснулся. Некоторым надо объяснять, зачем фильтровать на lo. Надо бы задать иное направление мысли. ☺
— Гость (16/02/2015 09:32)   <#>
Гость (15/02/2015 15:14), спасибо ещё раз. Первый работающий PoC:
#/bin/sh
 
myfun(){
        local origarg="$*"
        f_firsr=$1
        f_second=$2
        f_third=$3
        f_last=$(eval echo "\$$#")
        echo $f_last
        for i in `seq 4 $(($#-1))` ; do
            f_var=$(eval echo "\$$i")
            echo $f_var
        done
}
 
myfun aa bbb cc ddd eeee 93w4 888 8343-34 3443 USser
В целом получилось вполне читабельно и некостыльно, хоть и на чистом /bin/sh.
— Гость (16/02/2015 10:12)   <#>

Сейчас её сделали с задержкой. Если не хочется играть следующий ролик, есть несколько секунд на то, чтобы закрыть браузерную вкладку.


Кстати, должен вам сказать спасибо за поддержку этого документа в актуальном состоянии. Когда мне нужно было перецеплять свой TBB на системный Tor, ваш документ сильно помог. В частности, отключение старта локального Tor'а, похоже, никак штатно не делается. Даже если я запущу TBB обычным образом без файерволлов, а потом поменяю в настройках адрес SOCKS-порта, при последующих стартах TorBrowser всё равно будет ждать, пока запустится локальный Tor, т.е. с файерволлом это органически не дружит.

Поидее, логика должна быть такой: если видим, что вписана не дефолтная (на 9050), а другая SOCKS-прокси, коннектимся к ней и проверяем её на работоспособность; если всё ОК, то запускаем TorBroser, а локальный Tor не трогаем вообще. Тут ещё стоит учитывать, что TBB не может легко отличить ситуацию смены дефолтного порта локального Tor'а в TBB от ситуации перецепления TorBrowser'а с локального Tor'а на системный — обе SOCKS-прокси крутятся на 127.0.0.1. В любом случае, я не понимаю их логику. Почему бы не делать так: сначала проверять работоспособность заявленной в настройках прокси, а только потом (при необходимости) запускать локальный Tor?
— unknown (16/02/2015 10:52, исправлен 16/02/2015 10:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Пожалуйста! Мне самому удобно видеть его перед глазами в сети, когда под рукой нет черновиков для настройки.



Даже так?



Логика рассчитана на интересы большинства пользователей. Тонким ценителям оставлена возможность поизвращаться без автоматизации.

— Гость (16/02/2015 11:06)   <#>

Они там хотят

давать браузеру пароль от системного тора,

что в моём случае неприемлемо. Без этого их метод не заработает почти 100%, поэтому я даже не пытался их квест проходить.


Даже в Tor'е не любят первертов! :-)
— unknown (16/02/2015 11:18)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Можно и не давать, тогда по крайней мере не будет работать "new identity" («смена личины») от браузера. Вопрос, будет ли при этом глючить запуск? Или можно проигнорировать ошибки старта, он не сконнектится с системным тором, не будет запускать локальный и продолжит работать?

В любом случае, мне их инструкция не нравится из-за громоздкости.
— Гость (16/02/2015 11:30)   <#>
Ну, я не проверял. Вы, так понимаю, тоже(?). У вас другой случай — вам не нужно указывать иные параметры прокси, вам нужно просто отключить все настройки прокси.

Главное — чтобы при удалении Tor-ланчера (xpi-файл) ничего не ломалось внутри, а то начнёт ещё TorBrowser уникальные параметры HTTP-серверам о себе выдавать...


Мне тоже.
— unknown (16/02/2015 11:58)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Что-то начал делать, но не сработало и забросил.


Это возможно. Ещё хуже, что может быть способ принципиально различать поведение TBB, работающего через системный и локальный тор. Наконец, в рассылке ходили некие слухи о возможности каких-то компрометирующих запросов от пользователя и необходимости каких-то особо специфичных способов резать специфические запросы при прозрачной торификации. Пока я это не нашёл, воспринимайте это как непроверенную и возможно оишбочную информацию, но для осторожности держите в голове.
— Гость (16/02/2015 12:54)   <#>

An Isolating Proxy is much different from a Transparent Proxy. A pure Transparent Proxy suffers from Transparent Proxy Leaks. While a Transparent Proxy routes all 1 traffic through Tor and blocks the rest 1, an Isolating Proxy solves the Transparent Proxy Leaks problem and is about security by isolation.

Я недавно взял в лоб устаревшие инструкции с Tor-сайта для такого случая. Вроде там всё просто, а потом гляжу в tcpdump и вижу пакеты в обход Tor, причём пакеты именно на тот сайт, куда заходил в браузере. И это при том, что check.torproject.org распознаёт, что я за Tor'ом и показывает иной IP. Плюнул и снёс, разбираться некогда было. Вспомнил, что прозрачка — это вообще мутное дело.

Смотри, Транспарент Прокси ( Прозрачный прокси ) был с багом, утекали удп пакеты, поэтому появилась инструкция Изолированного прокси, читай его.

Вы ещё пользуетесь прозрачной торификацией всех соединений? Тогда деанон уже тут

Кто-нибудь может объяснить, на каком основании и зачем Tor шлёт ICMP? Или это ядро начинает слать за него?

Прозрачная торификация, как и сам iptables — сплошные баги. Кстати, эти утечки ведь не вчера появились поди. Наверно, после того, как правила прозрачной торификации написали в Tor-wiki, они там годами висели, и никто не замечал, что что-то утекает в обход Tor. Лично мне те правила сразу не понравились, потому что элементарным требованиям, указанным в «Как правильно писать безопасные правила для файерволлов?», они не удовлетворяют.

Кстати, мой iptables стабильно блочит огромное количество всевозможных легитимных пакетов, причина чего до сих пор остаётся невыясненной. Например, блочатся TCP-пакеты к guard'ам, блочатся вроде бы нормальные легитимные TCP-пакеты на lo. Не знаю, почему. Вроде на работоспособность это не влияет, поэтому приходится закрывать глаза. Я только могу сказать, что это было так на wheezy, и это остаётся так же на jessie.

Перефразируя известную фразу «emacs — хорошая ОС, вот только нормального редактора ей не хватает», можно сказать, что Linux — неплохая в целом ОС, но ей жизненно не хватает нормального файерволла — хотя бы такого, как PF. Я вообще последнее время всё больше склоняюсь к мысли, что в инфраструктуре с виртуалками правильнее написать простейшие правила iptables, которые будут закидывать весь трафик на какую-то BSD в domU, вот она пусть с ним через PF и разбирается. Это будет просто, логично, более контролируемо и естественно.
— Гость (16/02/2015 21:56)   <#>

Нате, пинайте. Я играл скриптовал, как умел. ☹
На страницу: 1, ... , 8, 9, 10, 11, 12, ... , 16 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3