Tor Browser Bundle и пакетный Tor

Имеется хост под Debian, на котором установлен пакет Tor и имеются несколько прозрачно торифицированных юзеров.
Установил tor-browser-bundle, запускаю под торифицированным юзером – запускается от юзера vidalla, tor и firefox.
Т.е., как я понимаю, tor локальный запускается внутри tor'а системного, что замедляет соединение.
При этом, в рассылке уже не рекомендуют пользоваться iceweasel + tor, а настоятельно рекомендуют переходить на browser bundle.
Но хочется запускать бразуер под прозрачно торифицированным юзером. Что делать?!

На страницу: 1, 2, 3, 4, 5, ... , 12, 13, 14, 15, 16 След.

Комментарии

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

FAQ планируется не дополнить, а удалить из него эту информацию, если руки дойдут. Перенести в серию документов. Это не вопрос для FAQ, так как предполагает разные варианты реализации (без претензий на абсолютную правильность каждого) и содержит слишком много текста.

Вот, что уже проверено сейчас, в варианте черновика.

В /etc/torrc:

SocksPort 9050 # what port to open for local application connections #Это закоментировано, т.к. устарело и по умолчанию всё и так слушается только с локалхоста #SocksListenAddress 127.0.0.1 # accept connections only from localhost AutomapHostsOnResolve 1 TransPort 9040 DNSPort 53 # Это так и всё и было, но что мешает добавить ещё немного с запасом: SocksPort 9051 SocksPort 9052 SocksPort 9053 SocksPort 9054 SocksPort 9055 TransPort 9041 TransPort 9042 TransPort 9043 TransPort 9044 TransPort 9045 DNSPort 54 DNSPort 55 DNSPort 56 DNSPort 57 DNSPort 58

# На всякий случай заблокируем это всё снаружи # Хотя tor по умолчанию слушает это только с локалхоста # цикл было составлять лень $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9050 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9051 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9052 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9053 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9054 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9055 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9040 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9041 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9042 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9043 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9044 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 9045 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 53 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 54 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 55 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 56 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 57 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p TCP --dport 58 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9050 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9051 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9052 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9053 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9054 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9055 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9040 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9041 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9042 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9043 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9044 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 9045 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 53 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 54 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 55 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 56 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 57 -j DROP $IPTABLES -A blocked_myports -i $INET_IFACE -p UDP --dport 58 -j DROP $IPTABLES -A INPUT -p TCP -j blocked_myports $IPTABLES -A INPUT -p UDP -j blocked_myports

#-#-#-# Tor-anonymity #tor anonymous users; # Системная группа с прямым выходом в инет мимо файрвола для TBB # Прощай анонимность при дыре в торбраузере, за что спасибо его создателям DIRECT_OUT_GID="tbb-tor" # Системный тор-пользователь в debian, # иначе не работало бы одно из правил в конце TOR_UID="debian-tor" # не обрабатываем прямые запросы на локалхост: $IPTABLES -t nat -A OUTPUT -o lo -j RETURN $IPTABLES -t nat -A OUTPUT -d 127.0.0.1 -j RETURN #Первый аноним пошёл на прозрачную торификацию: #anonym_1 $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonym_1 \ ! --gid-owner $DIRECT_OUT_GID -m tcp --syn -j REDIRECT --to-ports 9041 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonym_1 \ ! --gid-owner $DIRECT_OUT_GID -m udp --dport 53 -j REDIRECT --to-ports 54 # Логируем подозрительный трафик, не перенаправляющийся в тор # и перенаправляем на локалхост вместо того, чтобы его прибить # Если он не разроутится, то пакеты умрут сами # - уже успело помочь при неправильной # настройке DNS $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_1 \ ! --gid-owner $DIRECT_OUT_GID -j LOG \ --log-prefix "iptables anonym_1 redirect: " $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_1 \ ! --gid-owner $DIRECT_OUT_GID -j DNAT --to-destination 127.0.0.1 #другие анонимы прозрачно торифицируются по аналогии #anonym_2 $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonym_2 \ ! --gid-owner $DIRECT_OUT_GID -m tcp --syn -j REDIRECT --to-ports 9042 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonym_2 \ ! --gid-owner $DIRECT_OUT_GID -m udp --dport 53 -j REDIRECT --to-ports 55 $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_2 \ ! --gid-owner $DIRECT_OUT_GID -j LOG \ --log-prefix "iptables anonym_2 redirect: " $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_2 \ ! --gid-owner $DIRECT_OUT_GID -j DNAT --to-destination 127.0.0.1 #anonym_3 # похожие правила # <...> #anonym_4 -- а у него нет TBB #поэтому правила немного отличаются $IPTABLES -t nat -A OUTPUT -p tcp -m owner --uid-owner anonym_4 \ -m tcp --syn -j REDIRECT --to-ports 9044 $IPTABLES -t nat -A OUTPUT -p udp -m owner --uid-owner anonym_4 \ -m udp --dport 53 -j REDIRECT --to-ports 57 $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_4 -j LOG \ --log-prefix "iptables anonym_4 redirect: " $IPTABLES -t nat -A OUTPUT -m owner --uid-owner anonym_4 -j DNAT \ --to-destination 127.0.0.1 #-#-#-# #Выпускаем наружу сам тор: $IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT # Для TBB режем весь не tcp-трафик: $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID \ ! -p tcp -j LOG --log-prefix "iptables tbb reject: " $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID \ ! -p tcp -j REJECT #Режем трафик от TBB на 53 порт -- убережёмся хотя бы от утечки DNS при случайных дырках в TBB, но не более того. $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID \ -p tcp --dport 53 -j LOG --log-prefix "iptables tbb reject: " $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID \ -p tcp --dport 53 -j REJECT # Выпускаем наружу TBB по системной группе # и если будут серьёзные дырки в TBB-файрфоксе, # то гори эта анонимность синим пламенем: $IPTABLES -A OUTPUT -m owner --gid-owner $DIRECT_OUT_GID -j ACCEPT #-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#-#

—	*Гость* (21/06/2012 21:22) <#>

То же, но в /comment53711, но для pf:

pass out on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT1 user USERNAME1
pass  in on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT1 user TOR_USERNAME
pass out on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT2 user USERNAME2
pass  in on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT2 user TOR_USERNAME
pass out on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT3 user USERNAME2
pass  in on lo0 inet proto tcp from 127.0.0.1 to 127.0.0.1 port PORT3 user TOR_USERNAME

TOR_USERNAME — служебный (системный) пользователь, от имени которого запущен Tor, или root (разные версии pf могут приводить, возможно, к разным ответам).

—	*Гость* (21/06/2012 21:34) <#>

Сорри, надо заменить USERNAME2 на USERNAME3 во 2ой строчке снизу.

—	*Гость* (22/06/2012 14:03) <#>

А если я все-таки запускаю TBB под "прозрачно заторенными юзерами", причем каждый раз руками меняю настройки TBB (может это неск. хуже, как отмечали где-то, с точки зрения профилирования,но это лучше, чем поставить себя под удар, раскрыв "органам" свой физический адрес – профилирование угрожает вероятностным выводом, что те и те действия совершил предположительно один человек, а раскрытие физ. адреса всегда угрожает немедленным арестом или умерщвлением), то можно как-то эти настройки "гвоздями" прибить к TBB?
А то каждый раз указывать для каждого TBB свой SocksPort – можно легко запутаться.

—	unknown (22/06/2012 14:54, исправлен 23/06/2012 15:11) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Так и профилирование в некоторых сценариях угрожает тем же самым и вероятностные оценки будут несильно меньше единицы:

Tor proposals implemented in Tor 0.2.3.x

171 Separate streams across circuits by connection metadata

For example, if you make a connection to an
SSH host and log into a website over the same circuit, the exit
node can learn that the same person has accounts both at the
SSH host and the website. If the SSH host and website are
colluding, then over time, they can become certain which
account on the SSH host corresponds with which activities on
the website.

>каждый раз руками меняю настройки TBB

Есть неопробованная идея соединить оба подхода, развязав TBB-связку. Так чтобы работала и прозрачная торификация для всего не-TBB и заворачивание в системный тор всех TBB (без запуска локальных торов), каждого на свой порт и чтобы не было никаких утечек (весь TBB-трафик или заворачивается на локалхост, откуда может выйти только посредством системного тора или никак). И руками ничего править не нужно будет каждый раз если это получится.

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

—	unknown (24/06/2012 17:41, исправлен 24/06/2012 17:50) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Черновой рабочий вариант работы TBB с системным тором изложен здесь[создать].

—	*Гость* (24/06/2012 18:34) <#>

В комментариях к коду в /comment53712 unknown так сильно извинялся и произносил всевозможные предостережения, что мне даже неудобно стало. Вот напугал человека... Хотя оно и к лучшему: пусть сразу не будет иллюзий по поводу того, что firewall обязательно спасёт.

—	unknown (24/06/2012 19:25) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Мне такое решение самому не нравилось :) Но критика пошла на пользу, в текущем варианте системная группа TBB, которая выводила трафик наружу весь TBB-трафик практически без фильтрации, убрана.

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

Текущий вариант, даже если получится разнести TBB по портам также будет сохранять массу недостатков и скорее предназначен для изучения новых опций Tor с возможностью что-то попросить у разработчиков.

На страницу: 1, 2, 3, 4, 5, ... , 12, 13, 14, 15, 16 След.

Ваша оценка документа [показать результаты]