id: Гость   вход   регистрация
текущее время 15:03 28/03/2024
Владелец: 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/05/2013 00:39)   <#>
Правда, может ли он работать, как Tor-роутер
Tails не предназначен для роутинга. Только анонимный серфинг.

что она завернёт весь трафик на свой же локальный Tor?
например соксификатором + файервол?

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

где фокус в точности находится на вопросе
для меня это было не совсем очевидно, поэтому и возник вопрос.

там ещё, к счастью, нет.
почему к счастью? )) сам проект Тор не позиционируется, как "Для избранных". и если сей продукт будет создан для массового использования как, например ТВВ, проект что-то потеряет?

Для широкой массы пользователей есть только Tails, а также, возможно, Liberte и Qubes
они никаким боком не относятся к тор-рутерам. а уж Qubes так вообще отдельная песня, точно не для домохозяек.
— Гость (28/05/2013 01:15)   <#>

В случае Linux достаточно iptables, это файерволл.


Нет проблем указать в настройках файерволла, что конкретный юзер USER не может обращаться куда-то ещё помимо 127.0.0.1:9050. Можно сделать даже с прозрачной торификацией. Ну, ещё ICMP глобально надо будет прикрыть файерволлом и IPv6. Всё, после этого ни один пакет от него не сможет уйти в обход Tor.


Я в полном шоке. А ещё кого-то за газификацию луж ругаете в соседнем топе.


Насколько я помню скрины, которые смотрел много лет назад, там установочный диск, всё для домохозяек, ставится, устанавливается, работает. В подборке есть GUI, рабочий стол, куча программ. Основная проблема — всё прибито гвоздями. Сделать что-то, что не предполагалось штатно разработчиками — уже проблема. Даже флэшку подмонтировать:

А система действительно интересная... Думаю для домохозяек самое оно.

Другие «домохозяйки» тоже отписывались о своём опыте: /comment60839 и /comment60949 — не похоже, что это великие UNIX-гуру писали. Чем вы хуже их?


Есть плюсы и минусы. Плюсы — большая анонимность из-за распространённости, больше внимания к проекту. Это очевидно. Минусы — заточка под дебилов. Переход на идиотский интерфейс, где ничего не возможно толком найти, приходится пробираться через дебри разветвлённых меню. Акценты разработчиков смещаются не в сторону большей безопасности продукта, а в сторону того, что увеличит его популярность у средней массы, которая толком вообще не знает, что же такое анонимность. Всё это мы наблюдали и с TBB (здравствуй, видео и включённые скрипты по умолчанию). Такова жизнь.
— Гость (28/05/2013 01:51)   <#>
В случае Linux достаточно iptables
что делать с приложениями, которые не умеют работать через сокс? наверно без соксификатора не удастся обойтись.

опыте: /comment60839
вы на мой пост и ссылаетесь) я там в эмоциях отписался. так что я имею практический опыт установки. и восторгов в комментах "рядомписавших" о Qubes я не наблюдаю.

comment60949
здесь положительным опытом так же не пахнет.

что увеличит его популярность у средней массы,
на форуме множество раз обсуждалось: нужна ли "серая" масса в Тор.
— Гость (28/05/2013 03:09)   <#>

Прозрачная торификация решает все вопросы универсально и для всех программ сразу. Это один из типов прозрачного соксирования (соксификации) или проксификации (прозрачного проксирования).

Соксификатор — сторонняя программа, которая перенаправляет трафик заданных программ или всей ОС на заданную socks-прокси (socks — частный случай прокси).

С практической точки зрения почти каждая программа умеет хотя бы один тип прокси. Этого достаточно, чтобы её настроить на работу через Tor напрямую или через промежуточную http- или https-прокси (privoxy, polipo, squid и др.). То, что не проксифицируется никак — редкая экзотика. К тому же, при частой работе с экзотикой возникают другие проблемы, такие как излишнее профилирование. В частности, именно поэтому, например, работать с почтой рекомендуют через web-браузер TBB, хотя проксифицировать свою любимую почтовую программу можно.

/comment58276: прозрачная торификация в винде делается почти искаропки через Proxifier, но он работает как intercepting proxy — это самое популярное решение в винде для заворачивания всего трафика в Tor.


Не путайте Tor как сеть и конкретное приложение для работы с ним. Естественно, масса нужна. Минусы и плюсы этого я уже озвучил. На форуме они тоже многократно обсуждались.
— Гость (28/05/2013 03:16)   <#>

То есть, умеет ли какая-то программа работать через прокси или нет — в случае прозрачной торификации не важно, поскольку для программ проксирование происходит прозрачно. В этом и состоит смысл прозрачной торификации.
— Slon (30/07/2013 05:48)   <#>
Допустим, что TOR не нужен. Если поставить privoxy и просто настроить работу браузера через него, насколько privoxy будет полезен с настройками по умолчанию?
— SATtva (30/07/2013 08:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Это privoxy не нужен. Ну, рекламные баннеры им можно резать (но я не помню, в насколько умолчальной конфигурации), но не забывайте, что принципиально он может работать исключительно с незашифрованным http-трафиком. Тот же AdBlock не имеет таких ограничений.
— Slon (30/07/2013 10:03)   <#>
Выходит с сайтами по SSL не работает? Зачем тогда в настройках браузера указывается SSL прокси и порт 8118...(видел в сети рекомендации по настройке).
— unknown (30/07/2013 11:25, исправлен 30/07/2013 11:25)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Чтобы подключаться к разнообразным прокси.

— SATtva (30/07/2013 13:15)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
ачем тогда в настройках браузера указывается SSL прокси и порт 8118

Это прокси для трансляции трафика, а не его фильтрации. Тот же Privoxy благополучно умеет транслировать SSL-трафик, но по вполне понятной причине не способен его фильтровать, т.е. в случае HTTPS совершенно бесполезен (Вы ж его ставите для фильтрации, а не каких-то других нужд).
— Гость (30/07/2013 21:02)   <#>

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

Например, мало кто знает про такой классный сюрприз как то, что в новых Linux'ах есть особо привелегированные программы, которые ходят в сеть в обход iptables. Вы написали правила и думаете, что если под них не подходит ни один пакет, значит, он не уйдёт в сеть, и вы в безопасноти. Ага, не тут-то было:

When getting an IP address the dhcp daemon creates a raw socket to the network interface and handles the UDP protocol itself. Thus the UDP packets never go through iptables.

The reason the dhcp daemon has to implement UDP is that the kernel can only handle UDP (in fact all of the TCP/IP suite) when the interface has an IP address. Previously dhcp daemons would first give an interface the IP address of 0.0.0.0 but that no longer works.

Что ж, «no longer works», очередная бага исправлена, все радуются. Я проверил, всё так и есть. Какие бы ни были правила iptables, DHCP-пакеты идут мимо него всегда (Debian Wheezy). Пользуясь случаем, передаю привет SATtva'е и unknown'у.

Это называется, «здравствуйте, raw-сокеты!» — реализация протоколов в обход сетевого стека. Т.е. DHCP-клиент использует прямой доступ к сетевой карте мимо сетевого стека ОС. Кстати, в винде тоже есть raw-сокеты, но там, чтобы они заработали, надо в fw создать правило для приложения вида allow all (raw-сокеты проходят только сквозь правило allow all независимо от того, какой протокол будет внутри), а в Linux что делать? Запрещать через SELinux? Использовать другой DHCP-клиент?

Raw сокеты — это обычный механизм работы с сетью в обход всего, их нельзя нормально фильтровать: можно либо запретить, либо разрешить, но не фильтровать. Есть ряд библиотек и тулзов, которые через них работают — например, libpcap, через которую работают tcpdump, iftop и wireshark. Это библиотека для низкоуровневой работы с сетевой картой, которая позволяет получать доступ к сетевой карте, игнорируя любые надстройки ОС — в частности, захватывать весь трафик, посылать пакеты, изменять режимы и т.д. Конечно, всегда можно написать программу, которая будет юзать libpcap аналогично tcpdump'у и получать все пакеты, но тут претензии к одному — к DHCP-клиенту, который работает не так, как ожидается, и к мейнтейнерам дистрибутива, которые включили в него такой сервер по умолчанию.
— Гость (27/07/2014 23:19)   <#>

Точнее, так: библиотека libpcap работает не через raw-сокеты, libpcap — это еще более низкоуровневый механизм, работа непосредственно через драйвер сетевой карты. А raw-сокеты — эта работа на IP-уровне, но мимо стека протоколов ОС, поэтому через raw-сокеты нельзя менять MAC-адрес, нельзя посылать специфичныe ioctl'ы и нельзя делать захват чужих пакетов в сети (promicuous mode). libpcap — это самый низкий уровень работы с сетевой картой, доступный приложениям, но если хочется еще ниже, то это только через свой kernel-модуль.
— Гость (28/07/2014 01:00)   <#>
Privoxy благополучно умеет транслировать SSL-трафик, но по вполне понятной причине не способен его фильтровать, т.е. в случае HTTPS совершенно бесполезен

Рекламные сайты в основном режутся по доменному имени, а не по URL, поэтому для HTTPS фильтрация privoxy тоже работает. Для торификации разных программ тоже полезен, т.к. большинство имеет встроенную поддержку HTTP прокси, а SOCKS не имеет. Соксификаторы в большинстве своём кривые, поэтому на них не всегда можно положиться.

DHCP-пакеты идут мимо него всегда

Идут только при старте dhclient, когда запрашивается сетевая конфигурация. Потом, при периодическом обращении к DHCP-серверу (по умолчанию раз в 20 минут), они идут уже на конкретный IP-адрес и правила iptables действуют.
— Гость (28/07/2014 12:24)   <#>

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