Настройка 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, но я их не тестировал.
например соксификатором + файервол?
в этом то весь и смысл, что завернув весь трафик хоста через NAT в рутер, мы не получим (наверно) утечек на сторону. а наружу запросы будут идти от тор-рутера.
для меня это было не совсем очевидно, поэтому и возник вопрос.
почему к счастью? )) сам проект Тор не позиционируется, как "Для избранных". и если сей продукт будет создан для массового использования как, например ТВВ, проект что-то потеряет?
они никаким боком не относятся к тор-рутерам. а уж Qubes так вообще отдельная песня, точно не для домохозяек.
В случае Linux достаточно iptables, это файерволл.
Нет проблем указать в настройках файерволла, что конкретный юзер USER не может обращаться куда-то ещё помимо 127.0.0.1:9050. Можно сделать даже с прозрачной торификацией. Ну, ещё ICMP глобально надо будет прикрыть файерволлом и IPv6. Всё, после этого ни один пакет от него не сможет уйти в обход Tor.
Я в полном шоке.
А ещё кого-то за газификацию луж ругаете в соседнем топе.Насколько я помню скрины, которые смотрел много лет назад, там установочный диск, всё для домохозяек, ставится, устанавливается, работает. В подборке есть GUI, рабочий стол, куча программ. Основная проблема — всё прибито гвоздями. Сделать что-то, что не предполагалось штатно разработчиками — уже проблема. Даже флэшку подмонтировать:
Другие «домохозяйки» тоже отписывались о своём опыте: /comment60839 и /comment60949 — не похоже, что это великие UNIX-гуру писали. Чем вы хуже их?
Есть плюсы и минусы. Плюсы — большая анонимность из-за распространённости, больше внимания к проекту. Это очевидно. Минусы — заточка под дебилов. Переход на идиотский интерфейс, где ничего не возможно толком найти, приходится пробираться через дебри разветвлённых меню. Акценты разработчиков смещаются не в сторону большей безопасности продукта, а в сторону того, что увеличит его популярность у средней массы, которая толком вообще не знает, что же такое анонимность. Всё это мы наблюдали и с TBB (здравствуй, видео и включённые скрипты по умолчанию). Такова жизнь.
вы на мой пост и ссылаетесь) я там в эмоциях отписался. так что я имею практический опыт установки. и восторгов в комментах "рядомписавших" о Qubes я не наблюдаю.
здесь положительным опытом так же не пахнет.
на форуме множество раз обсуждалось: нужна ли "серая" масса в Тор.
Прозрачная торификация решает все вопросы универсально и для всех программ сразу. Это один из типов прозрачного соксирования (соксификации) или проксификации (прозрачного проксирования).
Соксификатор — сторонняя программа, которая перенаправляет трафик заданных программ или всей ОС на заданную socks-прокси (socks — частный случай прокси).
С практической точки зрения почти каждая программа умеет хотя бы один тип прокси. Этого достаточно, чтобы её настроить на работу через Tor напрямую или через промежуточную http- или https-прокси (privoxy, polipo, squid и др.). То, что не проксифицируется никак — редкая экзотика. К тому же, при частой работе с экзотикой возникают другие проблемы, такие как излишнее профилирование. В частности, именно поэтому, например, работать с почтой рекомендуют через web-браузер TBB, хотя проксифицировать свою любимую почтовую программу можно.
Не путайте Tor как сеть и конкретное приложение для работы с ним. Естественно, масса нужна. Минусы и плюсы этого я уже озвучил. На форуме они тоже многократно обсуждались.
То есть, умеет ли какая-то программа работать через прокси или нет — в случае прозрачной торификации не важно, поскольку для программ проксирование происходит прозрачно. В этом и состоит смысл прозрачной торификации.
комментариев: 11558 документов: 1036 редакций: 4118
Это privoxy не нужен.Ну, рекламные баннеры им можно резать (но я не помню, в насколько умолчальной конфигурации), но не забывайте, что принципиально он может работать исключительно с незашифрованным http-трафиком. Тот же AdBlock не имеет таких ограничений.комментариев: 9796 документов: 488 редакций: 5664
Чтобы подключаться к разнообразным прокси.
комментариев: 11558 документов: 1036 редакций: 4118
Это прокси для трансляции трафика, а не его фильтрации. Тот же Privoxy благополучно умеет транслировать SSL-трафик, но по вполне понятной причине не способен его фильтровать, т.е. в случае HTTPS совершенно бесполезен (Вы ж его ставите для фильтрации, а не каких-то других нужд).
Не читайте устаревших на несколько лет инструкций.
Например, мало кто знает про такой классный сюрприз как то, что в новых Linux'ах есть особо привелегированные программы, которые ходят в сеть в обход iptables. Вы написали правила и думаете, что если под них не подходит ни один пакет, значит, он не уйдёт в сеть, и вы в безопасноти. Ага, не тут-то было:
Что ж, «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-клиенту, который работает не так, как ожидается, и к мейнтейнерам дистрибутива, которые включили в него такой сервер по умолчанию.
Точнее, так: библиотека libpcap работает не через raw-сокеты, libpcap — это еще более низкоуровневый механизм, работа непосредственно через драйвер сетевой карты. А raw-сокеты — эта работа на IP-уровне, но мимо стека протоколов ОС, поэтому через raw-сокеты нельзя менять MAC-адрес, нельзя посылать специфичныe ioctl'ы и нельзя делать захват чужих пакетов в сети (promicuous mode). libpcap — это самый низкий уровень работы с сетевой картой, доступный приложениям, но если хочется еще ниже, то это только через свой kernel-модуль.
Рекламные сайты в основном режутся по доменному имени, а не по URL, поэтому для HTTPS фильтрация privoxy тоже работает. Для торификации разных программ тоже полезен, т.к. большинство имеет встроенную поддержку HTTP прокси, а SOCKS не имеет. Соксификаторы в большинстве своём кривые, поэтому на них не всегда можно положиться.
Идут только при старте dhclient, когда запрашивается сетевая конфигурация. Потом, при периодическом обращении к DHCP-серверу (по умолчанию раз в 20 минут), они идут уже на конкретный IP-адрес и правила iptables действуют.
имхо, уже стало широко распространненым правилом настраивать выход в инет через разного рода роутеры с nat, firewall и с возможностью подмены mac.