id: Гость   вход   регистрация
текущее время 17:03 15/12/2017
Владелец: spinore (создано 24/06/2012 22:23), редакция от 26/05/2013 06:29 (автор: spinore) Печать
Категории: софт, анонимность, tor, операционные системы
создать
просмотр
редакции
ссылки

Настройка 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
и кладутся в нужную директорию1. Автозапуск при загрузке системы делается прописыванием в /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.52:
# переменные:
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 и антиспуфинг, возможно, избыточны3.

Такая же конфигурация на 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 разрешают выход в сеть исключительно Tor-клиентам. Чтобы разрешить что-то ещё (входящие по ssh, например) добавьте правила по вкусу.

Замечания:

  • Стоить отметить один важный феномен. Конфиг для старого синтаксиса 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, но я их не тестировал.


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии [скрыть комментарии/форму]
— Гость (28/07/2014 12:53)   <#>

Вы это проверяли? Даже если так, это не оправдание. К тому же, я не держу запущенным DHCP-сервер при работе с Tor — это открывает ещё одно окно для манипуляций с трафиком машины со стороны ISP. Короче, DHCP-клиент запускается тогда, когда нужно (например, произошёл обрыв связи), а потом убивается. Получается, что все запуски идут в обход iptables.


Особенно в интернет-кафе, в дороге и других местах — у нас ведь каждый таскает с собой маленький хардварный роутер с закладками и проприетарной прошивкой.
— Гость (28/07/2014 13:22)   <#>
Про DHCP: можно посмотреть в сторону фильтрации средствами ebtables.
— Гость (28/07/2014 14:21)   <#>
Вы это проверяли? Даже если так, это не оправдание. К тому же, я не держу запущенным DHCP-сервер при работе с Tor

Клиент, а не сервер. И он (dhclient) постоянно работает в фоне, если не завершён вручную командой kill или killall. Периодическая связь с сервером нужна чтобы проверять обновления конфигурации сети, это предусмотрено протоколом. Когда DHCP трафик не был разрешён фаирволом, в syslog постоянно валилось много сообщений о недоступности DHCP-сервера, а соединение с провайдером время от времени пропадало. После того, как добавил правило iptables, сообщения об ошибке в логах прекратились и соединение держится круглосуточно.
— Гость (29/07/2014 04:51)   <#>

Лично мне представляется, что смена 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]:

Looks like someone doesn't even know how dhcp works, but keeps suggesting silly things and ignoring wise man (@claudio) sayings. dhcp clients may and will send requests directly to dhcp servers, apart from the fact that dhcpd ignores pf at all.

dhcp packets are grabbed by dhclient or dhcpd before pf sees them.

Neither dhcpd nor dhclient need any pass rules in pf. Both tools use bpf to steal the packets before they're checked by pf.

Воровство — оно ведь наказуемо, не так ли?


Похоже, в pf так же:

My dhclient.leases.em1 file is not updated. My dhclient is unable to renew its lease. As time goes on, dhclient makes more and more DHCPREQUESTs at shorter and shorter intervals.
when dhclient sends an unicast message, such as when renewing a lease, it doesn't use bpf fd... it uses a "regular" socket and writes to it using sendmsg()

В заключение повторюсь:

скоро надо будет вообще привыкать к тому, что полагаться на внутренний файерволл ОС будет нельзя — только на внешний (т.е. нужны либо виртуалки, либо дополнительная железяка).
— Гость (29/07/2014 05:18)   <#>

Видимо, уже рассматривают. :)

В 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 — еще вопрос. Это дело можно поисследовать экспериментально, а то вдруг там зарыты еще мегатонны уязвимостей для анонимности.
— Гость (29/07/2014 17:04)   <#>
Если DHCP-сервер даст адрес 127.x.x.x, то это наверное создаст угрозу. Клиентские порты можно защитить фильтрацией на lo, но серверные доступны, т.к. для входящих пакетов нет UID. Напрямую на деанонимизацию это скорей всего не скажется, т.к. через интрефейс ppp0 может ходить только Tor, но локальные сервисы (почта, Tor) будут открыты. Лучше всего самому написать dhclient-script и указать его в dhclient.conf. Все активные действия (перезапись resolv.conf, поднятие интерфейса ifconfig, изменение таблицы route) производятся в этом скрипте. Сам процесс dhclient только общается с сервером и по событиям вызывает dhclient-script, передавая ему конфигурацию сети в переменных окружения (IP-адрес машины, шлюза, DNS и т.п.). В нём можно сделать проверку IP-адреса и заодно запретить перезапись resolv.conf. Или поступить проще – dhclient-script самому не писать, а создать мини-скрипты dhclient-*-hooks, которые изменяют поведение некоторых функций основного dhclient-script. Другой вариант – использовать роутер, без сервисов на lo, а находящимся за ним машинам IP-адреса назначать статически.
— Гость (29/07/2014 21:14)   <#>
Когда я пишу dhclient -v -4 eth0, я в выхлопе вижу, что и кому назначено. Если это критично, то перед запуском dhclient все сервисы на ПК предварительно вырубаются. Потом, после успешной отработки dhclient, он тут же убивается через pkill -9 dhclient, и работа продолжается дальше.

Единственная проблема — пропадание сети, что нередко случается. Это значит, что надо закрывать все вкладки, везде разлогиниться, рестартнуть иксы и т.д. Короче, неудобно, зато даёт костыльный способ хоть как-то защититься от подобных атак, не вникая во внутренности dhclient'а.
— Гость (29/07/2014 22:22)   <#>
Чтобы восстановить соединение не нужно ничего закрывать, тем более перезапускать X-сервер. Ctr-Alt-F2, залогиниться в консоли под root и выполнить команды



или тому подобное
— Гость (30/07/2014 07:35)   <#>

Это само собой


В момент перезапуска по netstat -apn висит можество критичных соединений. Если в этот момент dhclient получит не те параметры, боюсь, какие-то не те пакеты могут уйти ISP, так что мали ли чего... Когда не понимаешь всю внутреннюю машинерию, лучше перестраховаться/перебдеть, чем недобдеть.
— Гость (09/12/2014 03:28)   <#>
Впервые вижу на pgpru картинку! unknown – как? :)
— unknown (09/12/2014 21:15)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Обычным пользователям форума, к сожалению, никак.
— unknown (02/02/2015 15:20)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
2 /comment81931: По поводу dhclient, если беспокоят возможные проблемы с dhcp-запросами, то кое-что советуют здесь.
— Гость (02/02/2015 17:13)   <#>
Спасибо, но факт остаётся фактом: dhclient вылезет в сеть, скачает, что хочет, но потом должен учесть свои настройки, чтобы не менять некоторые параметры. В любом случае, dhclient вылезет. Если я по ошибке его запущу, он пролезет несмотря на блокировку iptables'ом. Получается, они друг с другом равноправны, и я должен доверять первому так же, как последнему. А чем больше программ с безусловным доверием, тем хуже. Я ещё давно принял для себя максиму не пользоваться DHCP везде, где только можно, от него одни дыры в системе.
— pgprubot (18/10/2015 13:49, исправлен 18/10/2015 14:01)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Я затрудняюсь сказать, что в точности означает опция owner (user) в PF для правил pass in. Официально утверждается следующее:


user 〈user〉

This rule only applies to packets of sockets owned by the specified user. For outgoing connections initiated from the firewall, this is the user that opened the connection. For incoming connections to the firewall itself, this is the user that listens on the destination port.

When listening sockets are bound to the wildcard address, pf(4) cannot determine if a connection is destined for the firewall itself. To avoid false matches on just the destination port, combine a user rule with source or destination address self.

All packets, both outgoing and incoming, of one connection are associated with the same user and group. Only TCP and UDP packets can be associated with users.

User and group refer to the effective (as opposed to the real) IDs, in case the socket is created by a setuid/setgid process. User and group IDs are stored when a socket is created; when a process creates a listening socket as root (for instance, by binding to a privileged port) and subsequently changes to another user ID (to drop privileges), the credentials will remain root.

В случае правила «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, или нечто большее?

— гыук (24/06/2017 13:28, исправлен 24/06/2017 13:29)   профиль/связь   <#>
комментариев: 263   документов: 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


ну и т.д.

На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3