Tor: выходная нода своими руками
Хотелось бы на время сна (или постоянно) становится выходной нодой для Tor-пользователей. В связи с этим появилось несколько вопросов:
1. Какие порты нужно открывать для того, чтобы можно было работать как выходная нода?
2. Достаточно ли будет разрешить только исходящие порты?
3. Нужно ли что-нибудь дополнительно настраивать для большей безопасности? Или же можно просто скачать Tor Browser Bundle и запустить его на какой-нибудь Ubuntu?
комментариев: 9796 документов: 488 редакций: 5664
что мешает:
$ sudo apt-get install vidalia
В Видалии ставьте хоть релей хоть бридж.
Насколько помню, видалиа не развивается.
А чего там должно развиваться? Это ж GUI. Не нравится Видалиа, ставьте Arm.
А вообще посмотрите страницу загрузки для Вин. Там только Видалиа.
Там все bundle. Tor Browser Bundle (TBB), правда последнее время просто ТВ, и Vidalia Bridge Bundle, Vidalia Relay Bundle, Vidalia Exit Bundle, Expert Bundle. Вы то о чем говорите? Что хотите добиться-то?
А что значит отдельно скачать? Отдельно то ее нет. Ну хорошо, пусть когда нибудь появится видалия отдельно, как ее потом установить?
Вопросы -
1) что за новые строки с флеш- прокси конфигурацией?
2) Как обывателю на юниксе настраивать релей промежуточный, учитывая что сборок Tor Browser Bundle под юникс нет, и шевелить придеться мозгами, а не в ГУИ видалия, которую теперь убрали.
комментариев: 9796 документов: 488 редакций: 5664
Вот и выросло поколение пользователей типа юниксов…
Поставьте системный Tor (не из Bundle, а из пакета, и лучше не из своего дистра, а из репозитория торпроджекта) и поправьте в его конфиге пару строчек, не читайте, что сейчас осталось здесь, а смотрите здесь, хотя в попытке угодить чайникоподобным юзерам у торпроджекта на главных страницах вся документация теперь отвратительная. Читайте маны.
В простейшем случае в /etc/tor/torrc нужно будет выбрать опции ORPort, DirPort (хотя это с какого-то момента обещают убрать — статистика и соединения будут идти по одному порту), ExitPolicy reject *:*. Наверное, придёться задать RelayBandwithRate и RelayBandwithBurst, ну и про остальные опции в разделе конфига "Relays" хорошо бы почитать в мане, чтобы подумать над их выбором.
Это не для обычных промежуточных релеев, а для бриджей или их клиентов.
Оно очень приятно лезть руками в логику работы дистра. Первый же вопрос — как он будет проверять ключи? Откуда они возьмутся? Как проверить валидность устанавливаемых ключей для нового репа? А как это соотнести с правильной проверкой подписей? Я вроде не новичок, но поглядел на их инструкцию, и мне стало тоскливо, а что про других говорить?
комментариев: 9796 документов: 488 редакций: 5664
Правильная проверка подписей из схемы по приведённому вами коменту нужна для TBB, который не ставится из пакета. При установе пакетов всё автоматизировано так, что многие, к сожалению, не знают всей логики того, что происходит под капотом. Единственное, где там можно проколоться — внести фальшивый GnuPG-ключ в пакетный менеджер.
Там минимум вмешательства: добавка ключа стороннего репозитория и прописывание его в конфиге. Это штатная опция.
Все пакеты дистра заверены его подписью. Пакет без подписи поставить невозможно. В том числе пакет с кейрингом всех мантейнеров Debian. Если поставить этот пакет из дистра, то вы будете иметь подпись мантейнера, которого зовут Peter Palfrader. Он в топроджекте отвечает за упаковку пакетов для Debian. Но вам его ключ сам по себе не нужен. Вам нужен ключ торпроджекта:
gpg --keyserver keys.gnupg.net --search-keys 0xA3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg --keyserver keys.gnupg.net --recv-keys 0xA3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
Но этому отпечатку, который вы видите на форуме, доверять нельзя. Нельзя просто так скопировать его с форума, может его подменило АНБ.
Скачанный ключ надо проверить:
gpg --list-sigs 0xA3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
По идее, там должна быть подпись Питера из кейринга мэнтейнеров Debian. Но у меня в системе это работало только на момент первоначальной установки. Сейчас такая проверка не срабатывает. Придётся обновить ключ Питера с сервера. Из известных и доверяемых по множеству источников ключей я вижу, что ключ deb.keyrings.org заверен подписями Питера, Роджера и Эндрю Льюмана.
Т.е. доверие от вашего рабочего дистра автоматически протягивается к ключам всех разработчиков Tor вообще — они взаимоподписаны. Можно ещё упомянуть, что сам дистр Debian вы можете скачивать с серверов, подконтрольных потенциальному противнику (АНБ). Вы ведь также проверяете его по подписи и умеете это делать. А иначе, зачем вам крипто, Tor и всё сопутствующее?
Только после того, как вы сами проверили и поняли все взаимоотношения ключей (а не тупо скопировали отпечатки с форума), только тогда вы можете помещать ключ торпроджекта в свой пакетный менеджер:
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
Затем можете прописать репозиторий топроджекта в конфиг /etc/apt/sources.list
Туда надо прописать:
Затем, через sudo или рута:
apt-get update
apt-get upgrade
apt-get install tor tor-geoipdb deb.torproject.org-keyring
Представил как я поглядел на инструкцию, на вроде не новичка и мне стало тоскливо :( Неновичок хочет поставить Tor-ноду, при этом не хочет разбираться в азах работы с GnuPG и со своим дистром, которые касаются его безопасности и безопасности пользователей, которые будет обслуживать его Tor-узел.
Радует только man из команды tor-gencert, предназначенной для запуска корневых директорий:
Разработчики позаботились хотя бы о том, чтобы корневые директории нельзя было запустить на Windows и из стандартных гуёв, типа Видалии. Может, было бы лучше не доверять никаким операторам узлов, неспособным сконфигурировать Tor? Или разработчики считают, что лучше небезопасный, кем и как попало запущенный Tor-узел, ведь заведомо злоумышленный Tor-узел всё равно будет сконфигурирован правильно? Также, ещё раз возникает вопрос, что не нужно привлекать специально операторов узлов, у которы нет своей мотивации, например деньгами и пожертвованиями через Bitcoin. Иначе, толпа таких «не совсем новичков» массово понаставит что-угодно и как-попало, лишь бы побыстрее получить вознаграждение, наплевав на безопасность своих Tor-узлов.
Я так понял, что она нужна для всего критичного софта. Если его подписало n уполномоченных человек, членов проекта, нужно сверить подписи их всех. Подписи в Debian, как я понимаю, иные: там есть один ключ, им подписывается конкретный пакет. Или apt-get поддерживает в т.ч. и сверку нескольких подписей на пакете?
DA — вообще не массовые решения. Их всего штук 10, все друг друга знают лично, могут договориться запускать их на чём угодно.
комментариев: 9796 документов: 488 редакций: 5664
Там один ключ на все пакеты. Все мэнтейнеры имеют свои индивидуальные ключи и возможно даже подписывают апдейты своими ключами, но наружу это не попадает. Скорее всего, через внутренние коммуникации между ними принимается решение о доверии к апдейту, включаемому в апт, а снаружи можно проверить только подпись этим единственным ключом.
Более того, безопасность самого ключа, заверяющего дистры в пакете — это какое-то совсем непонятное obscurity. Кто его генерит, в каком подвале он храниться, как его используют для оперативной подписи большого числа срочных апдейтов, можно ли его стащить с сервера, можно ли им подписать какой-то левак, проникнув в команду разрабов. А Debian — это тысячи пакетов, у каждого м.б. по несколько разработчиков, лично они друг друга не знают. Ключ этот никем не подписан. Доверие к нему тянется только через кейринги от предыдущих выпусков дистров. Бардак и непонятки с выпуском самого этого нового ключа также бывали (наподобие, ключ выпущен, а в кейринг включить забыли, пару человек в рассылке спрашивает, а можно ли скачивать новый Debian, подписанный непонятно чем — впрочем это касается не подписи пакетов в текущем apt, а другого ключа — ключа дистра, это разные ключи, для Live-версии ещё какой-то отдельный ключ, толком их взаимоотношения нигде не расписано и возможно, только малая часть параноиков в мире разгребает этот бардак с подписями). Радует только то, что Debian раз в несколько лет приходиться обновлять — проверил один раз ключи, поставил, настроил и забыл на несколько лет, как оно там. Это касается и установки системного Tor: до выпуска нового релиза Debian ключ обычно не меняется, а если будет баг, как недавно в начале сентября, когда у Питера истёк ключ и он его неверно в начале продлил, то такой баг быстро приводит к ошибкам в apt, баг-репортам и исправлению кейринга через апдейт посредством самого apt.
С другой стороны, если кто-то может скомпрометировать архитектуру безопасности апдейтов Debian через утечку ключа, то тогда любой пользователь Debian может уже поверх этого особенно себе безопасность не накручивать.
Прямая ссылка http://cryptome.org/2014/12/snowden-on-tor.htm
Цитата
@Гость (18/12/2014 02:00) <#>
Почитай этот тред: https://lists.torproject.org/p.....2-August/025296.html
Тут он выложил прямо свои конфиги.
Это был тёплый август, четверг: Thu Aug 23 00:16:54 UTC 2012
Врядли у тебя 1gbps, так что такая *nix настройка для твоей машины вероятно будет валидной, где-то дальше там продолжение должно быть, Роджер или кто-нибудь расскажут, как правильно.