Настройка 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
/usr/local/bin/tor -f /path/to/torrc_1 /usr/local/bin/tor -f /path/to/torrc_2
/usr/pkg/bin/tor -f /path/to/torrc_1 /usr/pkg/bin/tor -f /path/to/torrc_2
Вопреки сказанному в Tor-faq, прав на чтение /dev/pf достаточно не только для OpenBSD, но и для NetBSD, потому назначаем:
# chgrp tor /dev/pf # chmod g=r /dev/pf
# переменные: 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
Такая же конфигурация на OpenBSD 4.8 с учётом смены синтаксиса PF выглядит так4:
# редиректы: 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 (т.е. первый) работает для входящих только при опции user root, а для нового — только при user unknown5, при этом в описании опции user в man pf.conf ничего не менялось. Для работоспособности исходящих соединений tor нужно указывать user tor6, но и это не консистентно с документацией на PF, где чёрным по-белому указано, что при дропе привелегий владельцем сокета остаётся исходный пользователь (в нашем случае root, т.к. запуск из /etc/rc.local). Для входящих соединений, согласно документации, должен быть user unknown, если это — транслируемый траффик, либо пользователь, слушающий на заданном порту7. С этой точки зрения что должно быть на самом деле для pass in согласно букве документации вообще не ясно (траффик сначала перенаправляется rdr, а лишь затем передаётся на порт Tor. Если считать, что rdr не меняет критерий user, то по логике вещей для pass in должен стоять root [см. выше про дроп привелегий]).
- В Tor-faq указан более короткий вариант правил (совмещает в себе и разрешение входящих и редирект), но я для большей контролируемости предпочитаю писать фильтрацию и трансляцию/перенаправления отдельно. Как мне представлялось (и как пишется во многих руководствах), пакет проходит фильтрацию до перенаправления и после. На практике стало понятно, что фильтрацию до перенаправления он не проходит, потому соответствующие правила из PF были изъяты3.
Указанная конфигурация легко заливается с помощью скрипта mklivecd на NetBSD LiveCD, что позволяет сделать бездисковый Tor-рутер из любого старого компьютера8. Конфиг будет работать и на одной сетевой с одним интерфейсом (надо будет для in0 и in1 указать тот же интерфейс).
P.S.: Конфигурацию с local redirection пока не настраивал, потому PF-аналог Linux-настройки привести не могу.
1Раздел /tmp целесообразно монтировать в память посредством mfs.
2В NetBSD 3.0 текущая версия Tor через pkgsrc собирается без поддержки прозрачной торификации (причины мне не известны), потому протестить не удалось.
3Если кто объяснит, где я не прав и как всё на самом деле, буду очень благодарен.
4Начало конфига до "опций" совпадает с предыдущим.
5Определялось экспериментально.
6Если вообще указывать опцию user, что в данной заметке делается по умолчанию.
7Например, user root для входящих pass in на ssh.
8Сколь-нибудь автоматизированных средств сборки OpenBSD LiveCD в сети не обнаружено, а все how-to написаны для довольно старых версий OpenBSD и не работают на 4.8 (ядро не влазит в отведённый размер boot при дискетоподобной системе загрузки LiveCD). Под FreeBSD есть средства автоматизированной сборки LiveCD, но я их не тестировал.
комментариев: 1060 документов: 16 редакций: 32
комментариев: 1060 документов: 16 редакций: 32
Невнимательно читаете. :)
А tsocks, линукс-хидеры и прочее только предлагается к удалению как ненужные. Все они были установлены автоматически как зависимости, а не явно по запросу пользователя.
Ой, да, туплю :) Сделал, спасибо.
И ещё один вопрос: если печать используется только на принтере, доступном по сети, а к самому компьютеру никакой принтер не подсоединён, то нужен ли cupsd, слушающий на 127.0.0.1:631? Если нет, то как его правильно удалить или хотя бы задизейблить?
комментариев: 1060 документов: 16 редакций: 32
комментариев: 1060 документов: 16 редакций: 32
... и сохраняется в локальном cups. А иначе пришлось бы в каждой программе отдельно сетевой принтер прописывать, если конечно они поддерживаются.
torrc:
/etc/resolv.conf
iptables:
Во-первых, возможно, лучше создать отдельный документ, чтобы не было слишком много текста на странице и путанницы, но над этим ещё можно подумать. Во-вторых, не вижу больших отличий ваших правил от приведённых здесь. У меня не было цели дублировать информацию оттуда. Как видите по тексту для BSD, он был детально проработан, закручены гайки в правилах, указаны ряд тонкостей, поэтому имел смысл создания отдельного документа у нас на сайте.
Прежде всего, я категорически против обобщённых правил в духе этих: они столь же потенциально небезопасны, сколь и универсальны. Везде надо писать -d и -s (-i, -o), для начала, а то представьте, что какой-то другой юзер на этой же машине поднимает своё приложение, которое будет слушать на тех же портах, и трафик вместо Tor пойдёт туда. Все до одного правила поэтому должны быть написаны в формате, грубо говоря,
Трафик во внешнюю сеть должен быть разрешён только для того юзера, под которым запущен демон Tor'а.
Неподготовленному читателю проще из правил для двух подсетей сделать правила для одной подсети или трёх, чем из правил для одной подсети сделать правила для нескольких, поэтому я привёл пример сразу для двух подсетей. Возможно, для правил для Linux это тоже имело бы смысл.
Tor-роутер и JanusVM — слишком разные вещи. Есть три способа:
О том, будет ли продукт, уже отвечено и всё сказано, но зарекаться никто не будет. Если что и развивать, то лучше всё сразу.* Во всяком случае, в планах на ближайшее будущее что-то делать с Tor-роутерами нет. К тому же, решение на LiveCD мало кому интересно, а разбираться с конвертированием его на LiveUSB охоты нет никакой. Да и делалось всё это давно, а сейчас нет ни тех ОС, ни того железа.
*См. «Отрицание использования дискового шифрования и наличия скрытой операцонной системы. Методы и идеи организации».
хорошие ссылки, но не понятно что там смотреть )) как выбирать то? ну например это "нерекомендуемо" – где на той странице искать? там много чего )
по EFF: статья 2010 и что с этим делать? пойти купить или скачать? где?
что касается Torouter, это готовое решение? я не увидел как устанавливать и использовать. наверно нужно покопаться, но тогда это не широкой массы пользователей.
Всё в техническую реализацию и упирается как раз. С точки зрения идеологии ваш трафик идёт в 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 и настроить прозрачную торификацию — по уровню защищённости получим ровно то же самое.
ФПП требует туториала-хандбука по его использованию? Видим фразу
Замечаем, что слово «нерекомендуемо» пишется синими цветом. Раз так, значит это ссылка. Кликаем на неё. После клика открывается новая страница, где фокус в точности находится на вопросе (см. верх страницы, как только она открылась)
Сам вопрос синим, он кликабелен. Так сделано для того, чтобы можно было сослаться в тексте на сайте на любой конкретный вопрос, т.е. на любое место в том тексте, а не только на саму страницу. Справа от вопроса идут ссылки: [1], [2], и т.д. В данном случае ссылка только одна: [1]. Кликаем на неё, и попадаем на комментарий, в теле которого сказано:
Т.е. приводится пример элементарной деанонимизации примера настройки типа 2.A. Конечно, деанон бы не работал, не будь ошибки, но виртуалки за тем и наворачиваются, чтобы страховать от них, а не добавлять новых. И, не будь ошибки ни в чём, виртуалки и роутеры совсем были бы не нужны — всё и в искоробочном TBB будет безопасно работать.
Вообще-то справа от вопроса про EFF стоят четыре ссылки, а не одна: [1], [2], [3], [4]. В частности, четвёртая ссылка [4] — комментарий /comment53190, где unknown
чёрнымсиним по белому написал:Щёлкаем на ссылку «Torouter» и попадаем на страницу проекта (ссылку на него можно было бы и через pgpru-новость или с помощью гугла нарыть, но так проще). Судя по всему, проект ещё только разрабатывается, и не факт, что доступен для тестинга в виде скомпилированных исходников, поэтому большой зелёной кнопки для дебилов на полный экран по типу «Download Tor» там ещё, к счастью, нет.
Для широкой массы пользователей есть только Tails, а также, возможно, Liberte и Qubes. Всё остальное — для тех, кто умеет обращаться с программами и интерфейсами «не для людей».
В интернете был текст с интрукцией «как пользоваться туалетной бумагой». Чувствую, что от меня здесь хотят того же самого.