Настройка Tor-роутера под BSD (transparent Tor-proxy как anonymizing middlebox)

Пример, приведённый в официальном Tor-faq, на текущий момент не применим для OpenBSD PF из-за смены синтаксиса, и, на мой взгляд, содержит ряд неточностей. Ниже привожу пример настройки с дополнительным закручиванием гаек в PF. Цель — прозрачно выпускать несколько локальных подсетей в Tor, где каждая из них будет привязана к своему Tor-клиенту (в рассматриваемом примере две подсети).

Пусть выходной сетевой интерфейс — fxp0, а входные — vr0 и vr1. Тестировались только OpenBSD и NetBSD. При установке Tor из портов пользователь tor (_tor) и группа tor (_tor) создаются автоматически в NetBSD (OpenBSD). Далее с помощью vipw добавляем аналогичного юзера для второй подсети (достаточно сменить UID, сохранив ту же группу, имена пользователей для удобства можно упорядочить как, например, tor1 и tor2). Для tor-пользователей создаются конфигурационные файлы наподобие таких:

$ cat torrc_1 
SocksPort 9050 
SocksListenAddress 127.0.0.1 
RunAsDaemon 1
DataDirectory /tmp/tor_1
User tor1
AutomapHostsOnResolve 1
Log notice file /tmp/tor_1.log
VirtualAddrNetwork 10.192.0.0/10
TransPort 9060
DNSPort 5353

$ cat torrc_2 
SocksPort 8050 
SocksListenAddress 127.0.0.1 
RunAsDaemon 1
DataDirectory /tmp/tor_2
User tor2
AutomapHostsOnResolve 1
Log notice file /tmp/tor_2.log
VirtualAddrNetwork 172.16.0.0/12
TransPort 8060
DNSPort 5363

и кладутся в нужную директорию¹. Автозапуск при загрузке системы делается прописыванием в /etc/rc.local строчек наподобие

/usr/local/bin/tor -f /path/to/torrc_1
/usr/local/bin/tor -f /path/to/torrc_2

для OpenBSD и

/usr/pkg/bin/tor -f /path/to/torrc_1
/usr/pkg/bin/tor -f /path/to/torrc_2

для NetBSD.

Вопреки сказанному в Tor-faq, прав на чтение /dev/pf достаточно не только для OpenBSD, но и для NetBSD, потому назначаем:

# chgrp tor /dev/pf
# chmod g=r /dev/pf

Нижеследущий конфиг был проверен на работоспособность в NetBSD 5.0.2, NetBSD 5.1 и OpenBSD 4.5²:

# переменные:
in0  = "vr0"
IPin0 = "IP_НА_vr0"
net0 = "СЕТЬ_НА_vr0"
TransPort0 = "9060"
DnsPort0 = "5353"
 
in1  = "vr1"
IPin1 = "IP_НА_vr1"
net1 = "СЕТЬ_НА_vr1"
TransPort1 = "8060"
DnsPort1 = "5363"
 
out0  = "fxp0"
IPout0 = "IP_НА_fxp0"
 
lh  = "localhost"
tor_users = "{ tor1, tor2 }"
 
# опции по вкусу:
scrub all no-df random-id min-ttl 128
 
# редиректы:
rdr on $in0 inet proto tcp from $net0 to ! $IPin0             -> 127.0.0.1 port $TransPort0
rdr on $in0 inet proto udp from $net0 to ! $IPin0 port domain -> 127.0.0.1 port $DnsPort0
 
rdr on $in1 inet proto tcp from $net1 to ! $IPin1             -> 127.0.0.1 port $TransPort1
rdr on $in1 inet proto udp from $net1 to ! $IPin1 port domain -> 127.0.0.1 port $DnsPort1
 
# фильтрация:
block all
block in quick from any os NMAP
antispoof log quick for {$in0,$in1,$out0}
 
pass in  on $in0  inet proto tcp from $net0   to $lh port $TransPort0 user root
pass in  on $in0  inet proto udp from $net0   to $lh port $DnsPort0   user root
 
pass in  on $in1  inet proto tcp from $net1   to $lh port $TransPort1 user root
pass in  on $in1  inet proto udp from $net1   to $lh port $DnsPort1   user root
 
pass out on $out0 inet proto tcp from $IPout0 to any                  user $tor_users
 
block inet6 all

Выше строки

block all
block in quick from any os NMAP
antispoof log quick for {$in0,$in1,$out0}

можно заменить на

block return log (all)

и тогда сниффер

# tcpdump -i pflog0 -n -e action block

покажет все пакеты, блокируемые PF (полезно для отладки). Критерий actions поддерживается только в OpenBSD. Кроме того, ввиду правила "block all" блокирование nmap и антиспуфинг, возможно, избыточны³.

Такая же конфигурация на OpenBSD 4.8 с учётом смены синтаксиса PF выглядит так⁴:

# редиректы:
match in on $in0 inet proto tcp from $net0 to ! $IPin0             rdr-to 127.0.0.1 port $TransPort0
match in on $in0 inet proto udp from $net0 to ! $IPin0 port domain rdr-to 127.0.0.1 port $DnsPort0
 
match in on $in1 inet proto tcp from $net1 to ! $IPin1             rdr-to 127.0.0.1 port $TransPort1
match in on $in1 inet proto udp from $net1 to ! $IPin1 port domain rdr-to 127.0.0.1 port $DnsPort1
 
# фильтрация:
block all
block in quick from any os NMAP
antispoof quick for {$in0,$in1,$out0}
 
pass in  on $in0  inet proto tcp from $net0   to $lh port $TransPort0 user unknown
pass in  on $in0  inet proto udp from $net0   to $lh port $DnsPort0   user unknown
 
pass in  on $in1  inet proto tcp from $net1   to $lh port $TransPort1 user unknown
pass in  on $in1  inet proto udp from $net1   to $lh port $DnsPort1   user unknown
 
pass out on $out0 inet proto tcp from $IPout0 to any                  user $tor_users
block inet6 all

Данные конфиги PF разрешают выход в сеть исключительно Tor-клиентам. Чтобы разрешить что-то ещё (входящие по ssh, например) добавьте правила по вкусу.

Замечания:

Стоить отметить один важный феномен. Конфиг для старого синтаксиса PF (т.е. первый) работает для входящих только при опции user root, а для нового — только при user unknown⁵, при этом в описании опции user в man pf.conf ничего не менялось. Для работоспособности исходящих соединений tor нужно указывать user tor⁶, но и это не консистентно с документацией на PF, где чёрным по-белому указано, что при дропе привелегий владельцем сокета остаётся исходный пользователь (в нашем случае root, т.к. запуск из /etc/rc.local). Для входящих соединений, согласно документации, должен быть user unknown, если это — транслируемый траффик, либо пользователь, слушающий на заданном порту⁷. С этой точки зрения что должно быть на самом деле для pass in согласно букве документации вообще не ясно (траффик сначала перенаправляется rdr, а лишь затем передаётся на порт Tor. Если считать, что rdr не меняет критерий user, то по логике вещей для pass in должен стоять root [см. выше про дроп привелегий]).
В Tor-faq указан более короткий вариант правил (совмещает в себе и разрешение входящих и редирект), но я для большей контролируемости предпочитаю писать фильтрацию и трансляцию/перенаправления отдельно. Как мне представлялось (и как пишется во многих руководствах), пакет проходит фильтрацию до перенаправления и после. На практике стало понятно, что фильтрацию до перенаправления он не проходит, потому соответствующие правила из PF были изъяты³.

Указанная конфигурация легко заливается с помощью скрипта mklivecd на NetBSD LiveCD, что позволяет сделать бездисковый Tor-рутер из любого старого компьютера⁸. Конфиг будет работать и на одной сетевой с одним интерфейсом (надо будет для in0 и in1 указать тот же интерфейс).

P.S.: Конфигурацию с local redirection пока не настраивал, потому PF-аналог Linux-настройки привести не могу.

¹Раздел /tmp целесообразно монтировать в память посредством mfs.
²В NetBSD 3.0 текущая версия Tor через pkgsrc собирается без поддержки прозрачной торификации (причины мне не известны), потому протестить не удалось.
³Если кто объяснит, где я не прав и как всё на самом деле, буду очень благодарен.
⁴Начало конфига до "опций" совпадает с предыдущим.
⁵Определялось экспериментально.
⁶Если вообще указывать опцию user, что в данной заметке делается по умолчанию.
⁷Например, user root для входящих pass in на ssh.
⁸Сколь-нибудь автоматизированных средств сборки OpenBSD LiveCD в сети не обнаружено, а все how-to написаны для довольно старых версий OpenBSD и не работают на 4.8 (ядро не влазит в отведённый размер boot при дискетоподобной системе загрузки LiveCD). Под FreeBSD есть средства автоматизированной сборки LiveCD, но я их не тестировал.

На страницу: 1, 2, 3, 4, 5, 6 След.

Комментарии [скрыть комментарии/форму]

—	sentaus (18/11/2012 01:06) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

У вас команда неверная, замените autoremove на remove. Если применять autoremove, то apt-get в дополнение к зависимостям попытается ещё удалить неиспользуемые пакеты (которые были установлены неявно как зависимости, но теперь не нужны, поскольку зависящие от них пакеты удалены).

—	*Гость* (18/11/2012 01:36) <#>

У вас команда неверная, замените autoremove на remove.

# apt-get remove avahi-daemon 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libqt4-opengl linux-headers-2.6.32-21 mesa-common-dev tsocks socat linux-headers-2.6.32-21-generic-pae
  libdrm-dev libreadline5
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  avahi-daemon avahi-utils libnss-mdns telepathy-salut
0 upgraded, 0 newly installed, 4 to remove and 3 not upgraded.
After this operation, 1,384kB disk space will be freed.
Do you want to continue [Y/n]?

Почти то же самое. Tsocks, линукс-хидеры и прочее, что может быть фатально необходимо для работоспособности ОС или каких-то уже установленных программ. Что я делаю не так?

—	sentaus (18/11/2012 01:42) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

Что я делаю не так?

Невнимательно читаете. :)

The following packages will be REMOVED:
  avahi-daemon avahi-utils libnss-mdns telepathy-salut

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

—	*Гость* (18/11/2012 03:19) <#>

Невнимательно читаете. :)

Ой, да, туплю :) Сделал, спасибо.

И ещё один вопрос: если печать используется только на принтере, доступном по сети, а к самому компьютеру никакой принтер не подсоединён, то нужен ли cupsd, слушающий на 127.0.0.1:631? Если нет, то как его правильно удалить или хотя бы задизейблить?

—	sentaus (18/11/2012 14:12) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

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

—	*Гость* (18/11/2012 14:23) <#>

В каком смысле "узнавать"? IP сетевого принтера назначается в настройках вроде бы руками...

—	sentaus (18/11/2012 14:30) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

IP сетевого принтера назначается в настройках вроде бы руками...

... и сохраняется в локальном cups. А иначе пришлось бы в каждой программе отдельно сетевой принтер прописывать, если конечно они поддерживаются.

—	*Гость* (19/11/2012 01:00) <#>

Понятно. Спасибо.

—	*Гость* (28/01/2013 13:42) <#>

Расширить раздел Linux-ом не хотите?

torrc:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 9040
TransListenAddress 127.0.0.1
TransListenAddress 192.168.1.1
DNSPort 53
DNSListenAddress 127.0.0.1
DNSListenAddress 192.168.1.1

/etc/resolv.conf

nameserver 127.0.0.1

iptables:

# destinations you don't want routed through Tor
NON_TOR="192.168.1.0/24 192.168.0.0/24"
 
# Tor's TransPort
TRANS_PORT="9040"
 
# your internal interface
INT_IF="eth0"
 
iptables -F
iptables -t nat -F
 
for NET in $NON_TOR; do
 iptables -t nat -A PREROUTING -i $INT_IF -d $NET -j RETURN
done

iptables -t nat -A PREROUTING -i $INT_IF -p udp --dport 53 -j REDIRECT --to-ports 53
iptables -t nat -A PREROUTING -i $INT_IF -p tcp --syn -j REDIRECT --to-ports $TRANS_PORT

—	*Гость* (29/01/2013 14:22) <#>

Расширить раздел Linux-ом не хотите?

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

Прежде всего, я категорически против обобщённых правил в духе этих: они столь же потенциально небезопасны, сколь и универсальны. Везде надо писать -d и -s (-i, -o), для начала, а то представьте, что какой-то другой юзер на этой же машине поднимает своё приложение, которое будет слушать на тех же портах, и трафик вместо Tor пойдёт туда. Все до одного правила поэтому должны быть написаны в формате, грубо говоря,

SrcIF:SrcIP:SrcPORT → DstIF:DstIP:DstPORT, if ( USER=USERNAME & PROTO=PROTOCOL & FAMILIY_PROTO=IPv4 ).

Трафик во внешнюю сеть должен быть разрешён только для того юзера, под которым запущен демон Tor'а.

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

—	*Гость* (26/05/2013 11:32) <#>

Вчера хотел поднять вопрос с Тор-рутером (но постеснялся)), а тут тема на главно странице. Хотелось бы поинтересоваться, в каком состоянии находится эта тема? Будет ли продукт, аля JanusVM?

—	*Гость* (26/05/2013 23:11) <#>

> в каком состоянии находится эта тема? Будет ли продукт, аля JanusVM?

Tor-роутер и JanusVM — слишком разные вещи. Есть три способа:

Tor-роутер (физически отдельный компьютер, который пропускает через себя чужой трафик и заворачивает его в Tor).
Виртуальные машины:
1. Трафик host OS заворачивается в guest OS. Это просто в использовании, но нерекомендуемо. К этому случаю относятся решения типа JanusVM, запуска Tor в qemu, в virtualbox и др. юзерофильных виртуалках, простых в использовании.
2. Трафик guest OS заворачивается в host OS. Сложнее в использовании и настройке, рекомендуемо. Это можно потенциально настроить как на основе Xen или kvm, так и на основе простых виртуалок. Технические проблемы:
  1. Раз под host OS запущен Tor, она не может быть любой, т.к. именно она критична к безопасности. На практике это выливается в то, что host OS подбирается специально под задачу, ставится и настраивается с нуля.
  2. Обычная юзерская активность в игрушечных виртуалках, не предназначенных для высокой производительности, будет сильно тормозить, а настройка серьёзных виртуалок, которые являются гипервизорами (Xen и kvm), достаточно сложно для неподготовленных.

О том, будет ли продукт, уже отвечено и всё сказано, но зарекаться никто не будет. Если что и развивать, то лучше всё сразу.^* Во всяком случае, в планах на ближайшее будущее что-то делать с Tor-роутерами нет. К тому же, решение на LiveCD мало кому интересно, а разбираться с конвертированием его на LiveUSB охоты нет никакой. Да и делалось всё это давно, а сейчас нет ни тех ОС, ни того железа.

^*См. «Отрицание использования дискового шифрования и наличия скрытой операцонной системы. Методы и идеи организации».

—	*Гость* (26/05/2013 23:21) <#>

Обратите внимание на решение от EFF: Torouter. По-моему, оно до сих пор в α-стадии, а ведь за ним EFF стоит, с которым PGPru тягаться тяжело несмотря на заявления некоторых анонимов.

—	*Гость* (27/05/2013 13:44) <#>

Tor-роутер и JanusVM — слишком разные вещи

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

хорошие ссылки, но не понятно что там смотреть )) как выбирать то? ну например это "нерекомендуемо" – где на той странице искать? там много чего )

Обратите внимание на решение от EFF: wwwTorouter.

по EFF: статья 2010 и что с этим делать? пойти купить или скачать? где?
что касается Torouter, это готовое решение? я не увидел как устанавливать и использовать. наверно нужно покопаться, но тогда это не широкой массы пользователей.

—	*Гость* (27/05/2013 22:49) <#>

> в чем такая сильная разница? в технической реализации, но не в идеологии.

Всё в техническую реализацию и упирается как раз. С точки зрения идеологии ваш трафик идёт в Tor, не важно каким образом. Хоть через сеть рутеров с виртуалками, хоть вы просто распаковали TBB и запустили его. Самое интересное — в том, что происходит, когда TBB начинает работать не так, как предполагалось разработчиками, и вот тут-то на помощь и приходят множественные технические страховки.

> какая разница где он будет установлен? ставить можно как на отдельную машину, так и на виртуальную

Что мешает в виртуальной машине запустить Tails, чем тут некоторые хвастались? Правда, может ли он работать, как Tor-роутер — это другой вопрос.

> в последнем случае, сложнее июо нужно будет жестко загнать весь трафик хоста в гостя (тор-рутер).

Я бы сказал больше того: не просто сложнее, а банально не имеет смысла.

Рассматрим случай 2.A «Трафик host OS заворачивается в guest OS». В этом случае заворачивание трафика в гостевую ОС страхуется исключительно host-осью. Следовательно, уязвимость «local root» позволяет отменить это действие, поэтому 2.A от него не страхует.

Возьмём самую распространённую конфигурацию: host OS — ваша основная ось, под которой работают (не важно, одновременно или нет) анонимный и неанонимный пользователь. При такой конфигурации локальная уязвимость в TBB не спасает от полной деанонимизации. Если под неанонимным пользователем (а он, возможно, запускал Flash, Skype и др. подобные штуки) утекла информация об ОС и используемом железе, то, подсунув анонимному пользователю этой же машины эксплоит, можно «подтвердить гипотезу», что он — это и есть он.

Допустим теперь, что вы не рассматриваете проблему уязвимостей в TBB, приводящих к однозначному профилированию, вы лишь беспокоитесь о том, чтобы весь трафик от данного пользователя шёл в Tor, а что сможет сделать злоумышленник на вашей системе с полными правами анонимного пользователя — не важно. В этом случае не обязательно запускать Tor в отдельной гостевой системе — достаточно запустить Tor под другим служебным пользователем (к которому анонимный не имеет доступа), и настроить TBB на работу через его Tor. Это решается штатным образом изменением настроек прокси.

Итак, я не вижу никаких веских преимуществ 2.A перед тем случаем, когда нет ни виртуалок, ни роутеров. Грубо говоря, если вы доверяете тому, что ваша система будет заворачивать весь трафик на гостевую, почему вы не можете доверять тому, что она завернёт весь трафик на свой же локальный Tor? На самом деле, я знаю причину, и эта причина — убогость винды, которая не имеет возможностей для настройки фильтрации трафика по пользователям. Так или иначе, для достижения минимума, предоставляемого системами типа JanusVM, достаточно установить Linux и настроить прозрачную торификацию — по уровню защищённости получим ровно то же самое.

> хорошие ссылки, но не понятно что там смотреть )) как выбирать то? ну например это "нерекомендуемо" – где на той странице искать? там много чего )

ФПП требует туториала-хандбука по его использованию? Видим фразу

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

Замечаем, что слово «нерекомендуемо» пишется синими цветом. Раз так, значит это ссылка. Кликаем на неё. После клика открывается новая страница, где фокус в точности находится на вопросе (см. верх страницы, как только она открылась)

О проприетарных виртуальных машинах и об уязвимости конфигураций, при которых host OS туннелирует свой трафик через guest OS [1].

Сам вопрос синим, он кликабелен. Так сделано для того, чтобы можно было сослаться в тексте на сайте на любой конкретный вопрос, т.е. на любое место в том тексте, а не только на саму страницу. Справа от вопроса идут ссылки: [1], [2], и т.д. В данном случае ссылка только одна: [1]. Кликаем на неё, и попадаем на комментарий, в теле которого сказано:

Такое закономерно заканчивается вот таким вот

Т.е. приводится пример элементарной деанонимизации примера настройки типа 2.A. Конечно, деанон бы не работал, не будь ошибки, но виртуалки за тем и наворачиваются, чтобы страховать от них, а не добавлять новых. И, не будь ошибки ни в чём, виртуалки и роутеры совсем были бы не нужны — всё и в искоробочном TBB будет безопасно работать.

по EFF: статья 2010 и что с этим делать? пойти купить или скачать? где?

Вообще-то справа от вопроса про EFF стоят четыре ссылки, а не одна: [1], [2], [3], [4]. В частности, четвёртая ссылка [4] — комментарий /comment53190, где unknown ~~чёрным~~ синим по белому написал:

Проект Torouter как-то развивается.

Щёлкаем на ссылку «Torouter» и попадаем на страницу проекта (ссылку на него можно было бы и через pgpru-новость или с помощью гугла нарыть, но так проще). Судя по всему, проект ещё только разрабатывается, и не факт, что доступен для тестинга в виде скомпилированных исходников, поэтому большой зелёной кнопки для дебилов на полный экран по типу «Download Tor» там ещё, к счастью, нет.

> тогда это не широкой массы пользователей.

Для широкой массы пользователей есть только Tails, а также, возможно, Liberte и Qubes. Всё остальное — для тех, кто умеет обращаться с программами и интерфейсами «не для людей».

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

На страницу: 1, 2, 3, 4, 5, 6 След.

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