Настройка 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, но я их не тестировал.
Вы это проверяли? Даже если так, это не оправдание. К тому же, я не держу запущенным DHCP-сервер при работе с Tor — это открывает ещё одно окно для манипуляций с трафиком машины со стороны ISP. Короче, DHCP-клиент запускается тогда, когда нужно (например, произошёл обрыв связи), а потом убивается. Получается, что все запуски идут в обход iptables.
Особенно в интернет-кафе, в дороге и других местах — у нас ведь каждый таскает с собой маленький хардварный роутер с закладками и проприетарной прошивкой.
Клиент, а не сервер. И он (dhclient) постоянно работает в фоне, если не завершён вручную командой kill или killall. Периодическая связь с сервером нужна чтобы проверять обновления конфигурации сети, это предусмотрено протоколом. Когда DHCP трафик не был разрешён фаирволом, в syslog постоянно валилось много сообщений о недоступности DHCP-сервера, а соединение с провайдером время от времени пропадало. После того, как добавил правило iptables, сообщения об ошибке в логах прекратились и соединение держится круглосуточно.
Лично мне представляется, что смена IP на лету при работе с критически важными к анонимости ресурсами — пример плохой политики, поэтому я предпочитаю pkill -9 dhclient после получения IP по DHCP. Я перепараноиваю? Может ли злонамеренный DHCP-сервер вдруг мне выделить IP=127.0.0.1 (не трудно догадаться, что при при этом произойдёт)? Или ещё какой другой специальный IP, облегчающий деанонимизацию? Вообще, тема, как должен вести себя DHCP-клиент при злонамеренном сервере, рассматривалась? Особенно, с точки зрения Tor и анонимности.
В Linux используется так назывемый ISC DHCP client, у него опция USE_RAW_SOCKETS задается при конфигурации. Видимо, тут вопросы к мейнтейнерам, или, возможно, под линуксом он просто не работает иначе. Hу, а вообще (концептуально) любая программа из-под рута может напрямую в сеть посылать какие хочешь пакеты — на уровне unix access control это не ловится, нужны более тонкие механизмы.
Что касается первых броадкастов (когда dhcp lease ещё нету), в OpenBSD наблюдается точно та же картина (другие ОС не проверялись) [1], [2], [3], [4]:
Воровство — оно ведь наказуемо, не так ли?
Похоже, в pf так же:
В заключение повторюсь:
Видимо, уже рассматривают. :)
В DHCP апприори считается, что сервер незлонамеренный, хотя помимо IP там можно выдавать много других интересных вещей: роуты, настройки прокси, настройки ttl и много чего другого. Например, в винде сконфигурированной по умолчанию злонамеренный DHCP-сервер может изменить настройки прокси в IE (в Linux тоже?). В частности, это значит, что любой ISP может элементарно сдеанонить всех виндовых IE-пользователей, кооторые полагаются на дефолтную конфигурацию, то же касается и Google Chrome. С TBB такое не прокатит, т.к., к счастью, TBB не полагается на настройки системной прокси.
Кстати, метод перехвата трафика винды через wpad одно время активно использовался хацкерами в локалках. Суть его такова: отслеживаем dhcp-запросы в сети и шлем dhcp-ответ, содержащий netbios nameserver опцию. Наш netbios nameserver отдает для имени WPAD адрес нашего хоста, где располагается файл wpad.dat, описывающий конфигурацию прокси. Механизм windows proxy auto discovery обнаруживает и применяет эти настройки, после чего весь трафик IE и других программ, берущих настройки из него, идет через нас. Замечательный механизм в винде. :-)
Здесь есть неполный список того, что DHCP-сервер может выдавать клиенту. Что из этого списка может перенять Linux или BSD — еще вопрос. Это дело можно поисследовать экспериментально, а то вдруг там зарыты еще мегатонны уязвимостей для анонимности.
Единственная проблема — пропадание сети, что нередко случается. Это значит, что надо закрывать все вкладки, везде разлогиниться, рестартнуть иксы и т.д. Короче, неудобно, зато даёт костыльный способ хоть как-то защититься от подобных атак, не вникая во внутренности dhclient'а.
или тому подобное
Это само собой
В момент перезапуска по netstat -apn висит можество критичных соединений. Если в этот момент dhclient получит не те параметры, боюсь, какие-то не те пакеты могут уйти ISP, так что мали ли чего... Когда не понимаешь всю внутреннюю машинерию, лучше перестраховаться/перебдеть, чем недобдеть.
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 511 документов: 2 редакций: 70
Я затрудняюсь сказать, что в точности означает опция owner (user) в PF для правил pass in. Официально утверждается следующее:
В случае правила «pass in ... keep state» будет подразумеваться разрешение соответствующих ответов с этого порта от демона, запущенного от имени user. Т.е. фактически user может иметь смысл только в смысле этих исходящих, которые неявно есть, но явно не анонсируются.
Однако, может быть, смысл всё же глубже. Если правило «pass in» без «keep state», и ответы от демона нас не интересуют, получит ли демон причитающийся ему пакет всегда, или только если он запущен от имени нужного user'а? К примеру, в iptables он его получит всегда. Если писать аналог правила «pass in ... keep state» на iptables (см. функцию allow_in), он будет подразумевать как входящие, так и ответы на входящие в рамках установленной сессии (--state ESTABLISHED), т.е. по сути исходящие, поэтому allow_in тоже будет иметь опцию фильтрации по пользователям. Иначе говоря, непонятно, user в «pass in» — это ровно то же, что и owner для allow_in, или нечто большее?
комментариев: 271 документов: 0 редакций: 0
Решил перечитать тему и вот натыкаюсь, естественно, что ссылки поменялись и часть информации на ресурсах обновилась.
Кто-нибудь следит в целом за ситуацией разработок Tor-роутера?
"TorBOX had to be renamed.
Whonix is the new project name."
The OpenWRT effort has a separate page – https://trac.torproject.org/pr.....tor/wiki/doc/OpenWRT
ну и т.д.