Торификация mutt
Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.
Ссылки
[link1] https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO/EMail
[link2] https://lists.torproject.org/pipermail/tor-talk/2011-June/020535.html
[link3] https://www.pgpru.com/comment42306
[link4] https://code.google.com/p/torsocks/
[link5] http://tsocks.sourceforge.net/faq.php#local
[link6] https://www.pgpru.com/comment47030
[link7] https://www.pgpru.com/comment70462
[link8] https://github.com/rofl0r/proxychains-ng
[link9] https://www.pgpru.com/comment85858
[link10] https://www.pgpru.com/comment70392
[link11] https://www.pgpru.com/comment81962
[link12] http://mpop.sourceforge.net/comparison.html
[link13] http://mpop.sourceforge.net/doc/mpoprc.txt
[link14] https://www.pgpru.com/comment85905
[link15] https://www.pgpru.com/comment47679
[link16] https://www.pgpru.com/comment47662
[link17] http://tsocks.sourceforge.net/faq.php#ssh
[link18] https://www.pgpru.com/comment35644
[link19] https://www.pgpru.com/comment88091
[link20] https://www.pgpru.com/comment88108
[link21] https://www.pgpru.com/comment86348
[link22] https://www.pgpru.com/comment86347
[link23] http://pkgsrc.se/wip/proxychains
[link24] https://www.pgpru.com/comment87151
[link25] https://www.pgpru.com/forum/unixlike/voprospohederammutt
[link26] https://www.pgpru.com/comment57673
[link27] https://www.pgpru.com/comment63746
[link28] https://www.pgpru.com/forum/anonimnostjvinternet/staryebagioglavnom
[link29] https://www.pgpru.com/novosti/2013/fpdetectivevyjavljaetpopytkiopredelenijaprofiljasistemyizpodbrauzera
[link30] https://www.pgpru.com/comment87359
[link31] https://lists.torproject.org/pipermail/tor-dev/2014-November/007738.html
[link32] https://www.pgpru.com/comment75114
[link33] https://www.pgpru.com/comment58822
[link34] https://www.pgpru.com/comment52147
[link35] https://www.pgpru.com/comment88111
[link36] https://www.pgpru.com/comment88308
[link37] https://www.pgpru.com/comment58312
[link38] https://www.pgpru.com/biblioteka/rukovodstva/setevajaanonimnostj/prodvinutoeispoljzovanietorvunix/nastrojjkatorruterapodbsdtransparenttorproxykakanonymizingmiddlebox
[link39] https://www.pgpru.com/comment88148
[link40] https://www.pgpru.com/novosti/2013/fbroficialjnopriznalasjvkontrolenadanonimnojjsetjjutor
[link41] https://www.pgpru.com/comment57667
[link42] https://www.pgpru.com/comment68237
[link43] https://www.pgpru.com/forum/unixlike/xeniprofilianonimnostiprivatnosti
[link44] https://www.pgpru.com/comment54190
[link45] https://www.pgpru.com/comment73398
[link46] https://www.pgpru.com/comment34713
[link47] https://www.pgpru.com/comment67944
[link48] https://www.pgpru.com/comment88323
[link49] https://trac.torproject.org/projects/tor/wiki/doc/torsocks
[link50] https://lists.torproject.org/pipermail/tor-talk/2012-April/024010.html
[link51] https://www.pgpru.com/comment93136
[link52] https://www.pgpru.com/comment88373
[link53] https://blog.torproject.org/blog/tor-0269-released
[link54] https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00025.html
[link55] https://lists.gnu.org/archive/html/bug-wget/2015-08/msg00050.html
[link56] https://www.pgpru.com/comment11759
[link57] https://www.pgpru.com/comment55516
Можно практически всё под данным torifyWiki[link1] из вышеперечисленного и много чего ещё.
Тема непроработана и пользователям давались неоднократные предупреждения в рассылке по поводу того, как легко на этом всём проколоться, пока не разработано единое для всех унифицированное решение по аналогии с Torbutton (только для почты). И пока (и уже много лет и ещё будет наверное столько же) анонимность почты на отправку в стадии "Experimental". Вот из недавнего[link2].
unknow, я понимаю,что почтовые клиенты "срут" лишней инфой, но иногда скорость важнее, чем сокрытие клиента, а главное – это сокрытие места нахождения. (Есть случаи, когда действуешь вообще под своим реальным именем, но ненужно, чтобы всякие скоты знали, где ты физически локализуешься).
Вот по поводу этих моментов есть вопросы:
TZ же можно задать UTS через переменную? По крайней мере с громоптицей это работает. А вот чем будет "срать" exim в случае отправки с mutt, не совсем ясно. Наверное, он будет свои какашки дополнять к какашкам mutt?
По поводу "mutt на своем почтовом сервере", который юзается через ssh over Tor.
Чем это решение хуже использования там же веб-морды, того же Squirell Mail? Имхо, разницы большой нет. Кроме того, что mutt по ssh over Tor будет существенно быстрее, чем веб-морда over Tor. нет?
P.S. А если при отправки с локалхоста пользователю, под которым запущен exim, сделать прозрачную торификацию, будет это работать? (При том, что этот exim занимается: а) доставкой локальной почты; б) связью с публичным почтовым сервером, для отправки почты с помощью mutt, и больше не для чего не используется).
Да, чуть не забыл, а что, почтовые клиенты умеют "срать" в заголовки и аптайм машины?
Прозрачная торификация — самое простое, чтобы не играть в опасные игры с проксями и не мучиться. Заголовки решаются железно методом испльзования специальной guest OS в виртуалке, в которой будет своё время и свой часовой пояс (наверное, так можно сделать).
Я не в курсе exim, но, насколько я знаю, mutt'у указывается дополнительные 2 команды в конфиге: для чтения почты и для отправки почты. Первое умеет fetchmail/getmail, второе — msmtp. Эти тулзы с проксями не дружат, так что можно их попытаться использовать с proxychains. Это на случай, если без прозрачной торификации.
Нет. ssh — вообще требовательный к скорости протокол, работать с ним под Tor'ом не очень приятно, особенно, если мало опыта набора команд вслепую. Тормозить будет адски. Так что годится это только для минимальный действий типа "переслать письмо через sftp" и "отправить его мейлером с сервера", а набирать всё равно у себя на localhost'е будете.
Обязано.
Какой-то бред. Если что-то прозрачно торифицировано, оно ушло в инет и вернуться не может, если нет реального IP. Для программ прозрачная торификация прозрачна, а потому работать должно всё, если им просто надо отсылать данные в сеть и получать их (но не быть интернет-сервером).
Читайте, есть ли там такие опции в документации.
Пара рекомендаций общего характера:
Можно, но если сервер свой и хочется полагаться на его анонимность, то и регистрировать его надо анонимно, и оплачивать хостинг анонимно, что как бы не так просто.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Даже если можно, это всё опасные игры. Соломоново решение — под такие задачи делать свою guest ОС в виртуалке.
Ну, например, локлальный IP машины может (скорее, точно будет) писать.
Особой разницы нет, вопрос удобства. Просто гемориться с настраиванием почты через Tor стоит, имхо, только если почты очень много и работа с ней через Tor — основное занятие в Tor. Проще не заморачиваться и пользоваться веб-мордами, благо что torbutton для браузера есть, а для мейлеров — нет.
На 100% ничего не исключено :)
Но потенциальный аптайм в самих tcp-sequences нейтрализуется за счёт Tor.
Рекомендую связку mutt+fdm+msmtp.fdm заменяет fetchmail+procmail,два в одном так сказать,и нативно поддерживает socks (set proxy "socks://127.0.0.1:9050" – директивой в своем конфиге).msmtp – сама простота,воистину unix-way,торифицируется через torify.Утечек не замечал,но не помешает:
Можно поспорить,хотя все относительно.С какими не заладилоь?
Если фильтрация не нужна, getmail лучше fetchmail (последний не может работать без procmail).
Как заставить Tor работать через корпоративную socks-прокси? А ssh? Я имею в виду напрямую, без промежуточной http-прокси типа privoxy. mcabber тоже сокс не умеет. msmtp, как вы сами пишете, требует внешней тулзы torify. ssh при настройке для работы через http-прокси требует внешней тулзы corkscrew. Сокс вообще мало кто умеет. links тоже сокс не умел (наверное, и сейчас так же). Те тулзы, которые умеют http-прокси, не умеют https-прокси. Как заставить работать wget через socks-прокси или https-прокси? Это не в конексте Tor'а, а вообще. Понятно, что под каждую тулзу можно соорудить свой костыль из стороних методов, туннелированрия через промежуточные прокси, прозрачной проксификации и универсальных проксификаторов а-ля proxychains.
P.S.: пробелы ставьте между словами, ОК?
Такая возможность реализована в tor-devel:
из man-а
wget через socks старая – непостижимая история,возможность задекларировали,а как реализовать утаили :)
proxychains,privoxy,torsocks,etc – не такие уж и костыли,свои задачи они выполняют хорошо.Может быть это unixway )
Да, про wget и https-прокси ступил. С http-прокси сам её так юзал, через задание переменной.
Не надо мешать всё в одну кучу. privoxy/tor — это прокси, proxychains — проксификатор. По факту не всё и не всегда проксифицируется. proxychains подменяет библиотечные вызовы, но прога это может и игнорировать. Особенно это начинает проявляться при запуске сложных прог типа браузеров через proxychains (хотя некоторые гуйные могут так работать). Вот, например, почему Tor не работает[link3] с proxychains, в котором сидит ssh'ный socks?
Возможно с proxychains погорячился ),мне не довелось его использовать,ибо под свои задачи хватало privoxy и torsocks.Поэтому ответ на вопрос:
мне не известен.Но,если еще актуально,то Tor(девелоперская его версия) может работать через "ssh'ный socks" самостоятельно(см.выше).
Спасибо за информацию.
и давно ли занемог?
Раньше не мог. Для складирования почты в хранилище mutt приходилось пользоваться procmail. Возможно, это было народным поверьем. Я в те времена настраивал вслепую.
Мне интересна прозрачная торификация (хотя я обычно по-возможности торифицирую и сами программы, запускаемые в режиме прозрачнойторификации, на случай если "упадут" правила iptables, а я этого не замечу, и т.п.).
Как я понимаю, сам mutt с внешней сетью не общается, поэтому от того, торифицирован ли прозрачно юзер, под которым он запускается, не зависит, уходят ли пакеты через Tor, или напрямую. Или я не прав?
fdm, как я вижу, работает через отдельного юзера. Т.е. прозрачно торифицировать надо этого юзера?
А что касается msmtp, от какого юзера она работает?
Или они от юзера запускаются, от которого же mutt? Что-то я не совсем пойму...
все будут работать от юзера запустившего их и читать настройки в конфигах находящихся в $HOME этого юзера.конфиги придется создать\отредактировать под потребности.
Если надо,то будет.
Упадут правила iptables? Это как? Само ядро ОС упадёт что ли? С виндой не путаете?
Руками уроню,например. Перепишу правила, обнулю существующие, а в период до загрузки новых – отвлекусь, и пойду куда-нибудь, забыв, и пропалюсь.
Как сказал герой одного знаменитого кинофильма, "Никому нельзя доверять, даже себе".
Речь шла о защите от программных ошибок, а не о раздолбайстве. Консоль рута — это вещь, которую на критических работающих системах трогают только при большой надобности, очень внимательно и на трезвую голову.
Гость (10/06/2011 22:11)
Замечательно настроил отправку почты через mutt + msmtp, а вот с конфигурированием fdm затруднился.
В дистре есть несколько примеров конфигов, и все они какие-то очень сложные.
Не могли бы Вы поделиться своим конфигом? (Ессно, без конфиденциальных данных)
example .fdm.conf:
Testing
Once you have this setup to your satisfaction, attempt to collect your mail by manually running fdm.
This will keep your mail untouched on the server incase there are errors. Look over the output to make sure everyting worked as planned. Open your favorite mail reader (MUA) and make sure that you can read the mail that was just delivered.
Гость (10/08/2011 20:57)
Премного благодарен.
А можно ли заставить msmtp работать через soks-прокси? Скажем, заюзать proxychains или tsocks?
proxychains – не юзал, не знаю.
tsocks – да .
torsocks[link4] is new generation of tsocks – рекомендую.
А если я хочу юзать проксю после Tor ?
Я вот попробовал заюзать proxychains, указав в ней socks4 и socks5 прокси (много), но почему то соединение по 25 порту отвергается.
Видимо, операторы прокси зафаерволили этот порт, негодяи
Кстати, в результате тестинга mutt выявилось, что он срет в заголовках:
а) Своим названием и версией, как и все почтовые клиенты;
б) Он способен срать именем и доменом хоста. Типа vasya@pupkin.
Но почему-то этот "сер" в заголовках не всех входящих писем – когда я отправляю с одного email-провайдера этот сер есть, когда с другого – нет.
Но, по-видимому, это зависит от почтового сервера провайдера – что он в итоге вставляет в заголовки, что нет. Поэтому, не исключено, что есть еще какой-то сер, который может видеть почтовый сервер, который обычно (даже если он на твоем дедике) контролируется враждебной стороной.
Кстати сказать, данный сер лечиться просто – запуском mutt с предварительной инициализацией фейковых переменных $HOSTNAME и $DNSDOMAIN.
Но вот как выявить возможный иной сер?! Чем он еще может серить?!
Да. Например, gmail не проставляет originating IP (ваш) при отправке писем, а mail.ru — проставляет. Ничего более, чем то, что расскажет мейлер + IP адрес ваш. Как сайдэффект протокола ещё может засветиться точное время на машине и ещё какие-нибудь параметры TCP, тот же TTL... (последние два — если не через Tor). Как ещё одна возможность — сделать прозрачную торификацию, после чего штатно указать сокс-сервер в настройках мейлера или какого-нибудь проксификатора (уже не обязательно такого, который умеет работать с цепочками прокси).
Это нормально для настроек по умолчанию. Предпочтения и пожелания сами что ли в конфиг материализуются? Читайте доки и маны, настраивайте как считаете нужным .
отправить мэйл самому себе, открыть его в mutt и нажать h
хотя б встроенную в mutt справку посмотрите )
hint : ?
— Гость (12/08/2011 22:49), спс большое, я сдуру только man смотрел и образец конфига, первый очень лапидарен, во втором не все сразу понятно, да и многих опциев нету :)
— Гость (12/08/2011 22:34)
Ну вот я так и пытаюсь решать, а что касается проксификатора – что-то сразу на ум пришел proxychains, и я стал пытаться заюзать его.
Но не знаю, правильно получается или нет.
Создал такой пользовательский конфиг:
Указал лист из множества прокси, пробовал random_chain – не отправляется (с единственным звеном), пробывал динамичную – не отправляется.
Правильно ли я задал этот конфиг?
Mutt выводит такой лай:
Ну или на 25 порт лается.
Как понять, правильно ли у меня сконфигурирован .proxychains, отвергает ли прокси исходящие соединения по данному порту или же это соединение отвергает почтовый сервер?
Да, и правильно ли я задал команду в конфиге Mutt?
Сейчас пробую tsocks вместо proxychains, нашел неск. рабочих внешних socks-4 проки.
В man tsocks и man tsocks.conf не указано, как должен быть сохранен конфиг tsocks (равно как не указано опции tsocks для юзанья альтернативного конфига).
Правильно ли я делаю, сохраняя его как $HOME/.tsocks, по аналогии с другими конфигами? Или он должен быть $HOME/tsocks?
Конфиг записал таким образом:
Чекаю его, получаю такое:
Ч.я.н.т.д?
Странное дело, у проксика порты 25 и 587 открыты, nmap кажет, траю :
tcpdump -n host ip_addr_of_proxy_server не показывает ни исходящих соединений с ним, ни входящих от него.
Юзается указанный конфиг proxychains (с указанием единственного сервера), запускаюсь под прозрачно заторенным юзером.
Что за беда такая?!
в отличие от muttrc(5)
port 1080 у 212.11.28.25 открыт ?
можно попробовать через Tor :
это может зависеть от системы/дистрибутива. Хозяину видней где что располагается в его_OS. У кого-то конфиг может быть, например, в /etc
P.S
server_port = 1080
1) Через Tor – работает. Но этот же хост в "local subnet"!!!
2) Порт – открыт:
(Тот ip изменен, из параноидных соображений, у реального открыт).
И утилита из tsocks – inspectsocks, показывала, что проксик рабочий (специально брал с сайта свежие прокси, а чекал их по списку, по ip и номеру порта, этой утилитой).
3) server_port = 1080 – ругани "Invalid pair type (port) specified on line 2 in configuration file, "port = 1080"" нет, спс.
Но, не работает:
P.S. Я пробовал в браузере (в ГУЕ браузера) указывать эту проксю (как socks проксю) – работает, а если запускать браузер из комстроки через tsocks или proxychains – вышеописанная беда.
это конечно не порок, но, вы пишите IP, а используете hostname, вот так запутывать не надо. Пробуйте :
Последнее китайское предупреждение – курите man'ы )
I keep getting an error like "SOCKS server is not on a local subnet!", what's going on?[link5]
— Гость (14/08/2011 17:16)
Насчет dns, так я запускаю tsocks под прозрачно торифицированным юзером, там dns заворачивается в tcp и резолвится через tor. Как я понимаю, на выходе из tor он остается tcp? (dns ведь умеет и tcp). Тогда не должно быть проблем с резолвингом dns через socks-проксю после tor'а. Или exit-нода tor'а резолвит dns через udp запросы, хотя и получает их в виде tcp? Что-то я не совсем тогда понимаю как и зачем.
Спс, но ничерта не понимаю, как это сделать.
Согласно man tsocks.conf, как я понял, есть две интересные директивы:
Если я прописываю что-то типа local = 212.11.28.00/24, выходит такой лай об ошибках:
Если что-то типа reaches = 212.11.0.0/16:80 – 1080:212.12.0.0./16, то такой:
Э...,тогда все зря. Что может tsocks? перехватить запрос от msmtp и отправить его socks-proxy, которым может быть в частности и Tor тоже. под прозрачно торифицированным юзером все исходящие в обход Tor блокируются файрволом, поэтому
а через 212.11.28.25 и др. нет.
— Гость (14/08/2011 22:59) <#>
Я почему-то думал,что tsocks пошлет пакеты через Tor (куда его завернет фаервол) на прокси-сервер, а тот уже – вовне.
Так как, например, если в браузере, запускаемом под прозрачно торифицированным юзером, указать настройки прокси, то прозрачная торификация заворачивает все в тор, из экзита оно идет на прокси, а уже из прокси – по назначению.
С tsocks так не работает?
Кстати, из-под незаторенного юзера проблема сохраняется. Так что, имхо, дело не в tor, а в неправильной конфигурации tsocks.
Может быть, кто-нибудь бы выложил образец своего работающего конфига?! Ессно, без чувствительных данных.
Я сомневаюсь, что вы понимаете, что такое прозрачная торификация и как она работает. Но, допустим, всё именно так как вы говорите и это работает. Тогда это означает, что трафик дважды идёт через Tor, т.е. цепочки длиной 6, а не 3.
Имеется ввиду внешний прокси, не Tor. Если tcpdump'ить, все идет через Tor, если смотреть ip на выходе (на тех же tor-детекторах или всяких чекалках ip) – ip внешнего проксика (я как то так делал, чтобы tor-ноды не абузить, их и так мало).
Что же касается указания в браузере под прозрачно торифицированным юзером, думаю, здесь Вы не правы – те же три цепочки, просто уходит на привокси или на полипу и идет обычным порядком, я тестил.
iptables -L -v -t nat не показывает, что пакеты заворачиваются в Tor фаерволом, если нет утечки, конечно. (Например, FF с торбаттоном утечки не давал, а джаббер-клиенты зачастую пытаются выпустить пакеты напрямую, тогда они режутся).
Но это оффтоп, а вот пример рабочего конфига tsocks или proxychains никто не привел, и не гуглится ни фига.
Кстати, а ssmtp умеет прокси без всяких tsocks, сам по себе?
Да, ошибся. Почему-то подумалось о случае Tor-рутера, т.е. когда первый Tor-клиент находится на другой машине вообще, и там это было бы так (если Tor-рутер + свой Tor-клиент на машине за Tor-рутером).
Гуглите как proxychains site:pgpru.com в гугле. Уже задолбался его конфиг сюда писать. Всё работает. Что не работает — тоже освещалось в топиках. Грубо говоря, не все прокси-серверы имплеменчены одинаковы, не все прокси-клиенты имплеменчены одинаково, так что сыпать все шишки на proxychains — нехорошо. Он проксифицирует как умеет. С цепочками прокси я его не использовал, но в качестве проксификатора через одну socks- или http-прокси — многократно. С tsocks не работал, потому ничего не подскажу.
Ну что Вы как маленький, право дело! Откройте man, посмотрите поиск по слову proxy (после открытия man введите: -i/proxynnnnnn) — если ничего не найдено, то значит нет.
В тему сабжа:
Схема «mutt[link7]* → privoxy → Tor → remote SSH-server → mail-server»
fetchmail и msmtp соксифицирются через proxychains, которая завязана на SOCKS-порт, открываемый ssh'ем (опция -D), идущим через Tor.
ssh торифицируется через corkscrew, которая перенаправляет его трафик на privoxy, зацепленную на Tor. Нужно, чтобы коннект на все хосты по ssh заворачивался на privoxy, а туннельные коннекты по ssh, т.е. к 127.0.0.1 (localhost), шли напрямую. И тут вылазят нюансы.
Во-первых, не забываем, что с точки зрения ssh хосты localhost и 127.0.0.1 разные: если в командной строке указывается ssh login@localhost, а в ~/.ssh/config особые правила указаны только для 127.0.0.1, то localhost будет обработан как произвольный хост (подпадает под секцию Host *). Во-вторых, из-за весьма больной логики OpenSSH (смотрим в сорс) если имя хоста не соответствует паттерну (тут не важно, с отрицанием или без), то данный элемент списка паттернов игнорируется.
Вариант 4 — это явная болезнь логики. Что курили (имели в виду) авторы? Если в строке Host указывать один отрицательный паттерн, из вышеизложенного следует, что эта секция не выполняется никогда. Вот что пишут на этот счёт в мане:
Т.е., надо писать «Host !127.0.0.1 *», тогда в случае типа 4 будет вот что:
Есть и другой вариант, как в Tails:
P.S. Два равнозначных конфига ~/.ssh/config, написанных с учётом сказанного:
*Работает как связка msmtp+fetchmail+procmail.
Вместо fetchmail удобней использовать mpop, его написал тот же автор что msmtp. Конфигурационные файлы msmtprc и mpoprc выглядят почти одинаково, имена всех опций одни и те же. mpop по сравнению с fetchmail проще в настройке и намного быстрей доставляет почту. К тому же fetchmail сейчас слабо поддерживается.
Проблем с торификацией msmtp и mpop никаких, через torsocks/proxychains4 работают нормально. Для изоляции цепочек для каждой торифицируемой программы (msmtp, mpop, gpg, wget и т.д.) нужно использовать отдельный конфигурационный файл torsocks.conf или proxychains.conf с указанием своего пользователя для username-авторизации на Tor. User и password могут быть любыми, главное чтобы отличались, Tor их сейчас не проверяет, использует только для разделения путей.
Если mpop запускается от отдельного пользователя (так безопасней), то в качестве MDA лучше использовать локальный SMTP-сервер, который в любом случае нужен. В противном случае procmail для доступа к почтовому ящику пользователя mutt требует рута или setuid, что небезопасно.
Смысл запуска mutt на удалённом сервере неясен, т.к. в этом случае письма хранятся на недоверяемой машине. ssh через corkscrew нужен только для прямого доступа (не через Tor) через HTTP-прокси, что позволяет сделать и proxychains. Через Tor достаточно torsocks/proxychains4 ssh, комбайны с corkscrew и privoxy не нужны.
По заголовкам тут уже сказали – User-Agent убрать, Message-ID модифицировать (опции user_agent и hostname). Принимающий SMTP-сервер добавит заголовок с IP-адресом эксит-ноды, даже если бы торифицируемый ПК имел белый адрес. Чтобы видеть и редактировать заголовки при наборе письма, лучше установить опции edit_headers и autoedit.
mutt запускается локально.
Там всё хитрее. Почту надо забирать, показывая mail-серверу нейтральный IP, т.е. Tor-эксит не канает, поэтому выбирается фиксированный SSH-сервер, доступ к которому уже идёт через Tor. Дальше возникает технический нюанс: proxychains не умеет разные конфиги (другие соксификаторы не курил; возможно, зря). Когда SSH-тунель проброшен, proxychains'ом в SOCKS-порт SSH'а заворачиваются msmtp и fetchmail. А как тогда завернуть в Tor сам SSH? Под тем же юзером отдельный конфиг proxychains для него не сделать, поэтому он торифицируется через комбайн с corkscrew и privoxy.
Кроме перечисленного, есть и другие нюансы: под этим же юзером надо выпускать mcabber через Tor с учётом того, что mcabber не умеет найтивно SOCKS-прокси, зато дружит с HTTP-прокси. Соответственно, ему в настройках проще всего указать privoxy, зацепленную на Tor. Это работает стабильнее, чем через proxychains, даже если бы вариант с proxychains был бы совместим.
Наконец, из-за того, что какие-то программы надо выпустить просто через Tor, а другие ещё и через SSH-сервер за Tor'ом, нельзя обе SOCKS-прокси (Tor и SSH SOCKS) указать в конфиге proxychains как два звена одной цепочки прокси. Короче, комбайн очень специфичен. Возможно, с другим проксификатором было бы меньше плясок.
Да, есть альтернативы и для msmtp и для fetchmail (тот же getmail и др.), но глубоко я с ними не разбрался, связка устоялась, а теперь главенствует принцип «не сломано — не чини». Времени играться и перенастраивать все конфиги через другие тулзы пока нет.
Это было бы уже совсем монструозно.
Зачем? Только чтобы системные логи собирать?
procmail запускается локально от того же юзера, который имеет доступ к почте. Насколько я знаю, никакого рута или суидности в этом случае не требуется. Вот если запускать от другого юзера, то могли бы быть нюансы, но и там это разруливается: procmail запускается от того, который имеет доступ к почте, а работа с почтой идёт от другого юзера, которому выдали доступ хозяйничать в нужной директории.
За советы спасибо.
P.S. Уже есть какой-то иной proxychains — proxychains-ng[link8].
Может удалённо почтовый сервер поставить? На том же серваке, где крутится SSH. А если он будет запущен как скрытый сервис, то он будет гарантировано принимать почту для отправки, оставляя в логах в качестве адреса отправителя только локалхост. К тому же его можно настроить, чтобы он перебивал заголовки почтовой программы по типу ремейлера. Правда, смысл иметь ремейлер на одного пользователя неясен, но это зависит от того, куда перенаправлять собираются почту.
Проще купить доступ к SOCKS-серверам и пользоваться proxychains с цепочкой из двух узлов – Tor и коммерческий SOCKS. Всё равно SSH-сервер у вас на платном VPS. SOCKS дешевле, не требует настройки и его легче сменить.
В 4 версии путь к конфигурационному файлу можно указать опцией командной строки -f или переменной окружения PROXYCHAINS_CONF_FILE. В torsocks (бывший tsocks) тоже можно менять настройки переменными окружения (man 8 torsocks), по крайней мере в версиях до 1.3, новой версией 2.0 не пользовался. В torsocks.conf можно ещё указать свой SOCKS-сервер для каждой IP-сети или хоста.
Как уже сказано, каждую программу можно запускать со своим proxychains.conf
Если разобраться с настройками msmtp, то осваивать mpop почти не требуется. Единственное существенное отличие – правильно указать строку с MDA. Конфигурационные файлы выглядят практически одинаково.
procmail может вызываться из fetchmail, mpop, SMTP-сервера и т.д., и наследует те же права. Речь шла от запуске MRA от пользователя, отличного от пользователя mutt, к почтовому ящику которого MRA->MDA не имеет прав доступа.
Немного усовершенствованния версия прежнего. Сейчас она самая актуальная, ей и пользуюсь.
Идеальный вариант – свой SMTP-сервер на VPS через Tor. Но иногда проще под конкретную задачу создать ящик на публичном сервисе. Иначе для каждого случая пришлось бы анонимно покупать VPS, что не всегда приемлемо по затратам.
Поправка: в случае вызова из SMTP-сервера права root не наследуются, в этом весь смысл. Поскольку сервер запущен из под рута, он сам может сменить UID для procmail на пользователя mutt. Запускать procmail от рута небезопасно, программа старая и были какие-то сообщения о её уязвимостях.
Всё это можно, но гемор. Я вообще не люблю почтовый протокол, так уж сложилось. Так не хочется с этим всем глубоко разбираться... хотя можно было бы много чего сделать. Например, я без понятия, откуда msmtp/fetchmail черпают информацию о сертификатах, можно ли сделать своего рода certificate pinning и т.д.
Опять не угдалали. SSH-сервер крутится в организации, к которой я имею вполне конкретное отношение. Более того, я лично собственными руками настраивал этот SSH-сервер и подсоединял его к сети. И, да, я не плачу за его аренду ни копейки. Если этот сервак сдохнет, будет другой, но там уже без рутового доступа (или с рутовым, но без права хозяйничать, как захочется). Просто я не считаю нужным сообщать организации, на каком IP я работаю и где в каждый момент времени нахожусь, незачем это, потому доступ через Tor. Да и ISP не стоит знать о том, кто я такой, и на какие сервера я хожу, где работаю и т.д.
[пафос]
Даже временные контрактники
Booz Allen Hamiltonнекоторых организаций имеют ряд пожизненных привелегий — к примеру, служебный email-адрес, который никогда не будет отобран, доступ к служебным PROXY- или SSH-серверам и т.д. Т.е. достаточно один раз в жизни попасть в спискимеченных властью, и потом всю оставшуюся жизнь можно иметь привелегии. Всё сильно зависит от страны и организации, но тренд такой прослеживается. Например, насколько я знаю, ящик в домене mit.edu является пожизненным. Среди иных приятных бонусов помимо собственно ящика у SSH- или PROXY-серверов обычно имеется подписка на огромную кучу журналов и трудов конференций, (множество оригиналов работ можно скачать бесплатно), а также бесплатный доступ к разным БД (scopus, ISI WoS и т.п.). В широких кругах мало об этом знают, но это очень приятные бонусы, т.к. персональная подписка на эти вещи стоит больших денег, и её мало кто себе может позволить. Если не оверклочить доступ, как Аарон Шварц, то всё будет ОК.[/пафос]
В текущих стабильных Debian/Ubuntu по прежнему 2-3 версия, увы. Но tsocks можно было бы покурить, это хороший совет.
В чём преимущество mpop перед msmtp?
Вот только в Debian/Ubuntu в пакетах я её не вижу, а с сорсов компилить не хочется.
Никто не спорит, вот только далеко не все публичные сервисы радушны к тем, кто входит в ящик через Tor. А из тех, кто не против, многие блокируются популярными почтовиками (из-за спама или ещё чего), да ещё имеют множество типичных проблем (маленький размер ящика, драконовские ограничения на размер аттачей и т.д.).
P.S. Моё понимание тренда таково: любой годный интернет-ресурс (будь то web-сайт, XMPP- или mail-сервер или что иное) должен давать доступ к себе как к HS. К счастью, с течением времени таких ресурсов становится всё больше.
Тут логика, видимо, была такой: сначала парсятся юзерские конфиги, а потом системные, поэтому, чтобы первые имели приоритет перед вторыми, срабатывает именно первое упоминание ProxyCommand. Однако, могло бы быть иначе (причём это более традиционный, IMHO, способ в UNIX): сначала парсились бы системные конфиги, а потом домашние, а приоритет был бы у тех, которые парсятся последними, и тогда домашние так же перекрывали бы системные. В этом случае именно последнее упоминание ProxyCommand в конфиге перекрывало бы все остальные. Претензия здесь к тому, что в man'е используемая логика не отражена.
Всё хорошо, но это не дружит с keychain-костылём [1][link10], [2][link11]. Более общо вопрос звучит так: как указать ssh-агенту, закэширевшему ключи, какой из ключей для какого сервера использовать? IdentityFile этот вопрос не разруливает. Если ssh-агенту не указывать ничего, он подсовывает все ключи попорядку, пока не найдётся правильный. Тут ещё проблема в том, что на некоторых SSH-серверах стоят драконовские ограничения на число неуспешных попыток залогиниться, и каждый лишний подсунутый ключ — такая неудачная попытка авторизации. Из-за этого в каких-то случаях приходится либо редактировать серверный /etc/ssh/sshd_config (если вам это дадут), либо удалять лишние ключи со связки. В ~/.ssh/authorized_keys можно указать, соединения с каких IP авторизовывать по данному публичному ключу, а было бы интересно иметь такую же опцию, но для приватного ключа на клиенте (~/.ssh/X.X.X.X-keyfile.ssh) — указать, что данный ключ может быть использован только для заданного сервера / IP-адреса.
Ещё один минус ~/.ssh/config — невозможность разбить опции по портам. Есть только опция Host, но нельзя специфицировать порт. К примеру, если пробрасывается несколько тунелей, это будет соответствовать разным SSH-серверам, все из которых будут слушать на 127.0.0.1, но на разных портах. Впрочем, записи в ~/.ssh/known_hosts, кажется, тоже не учитывают порт. :(
Проще наверное создать локальный SOCKS-прокси, который через Tor соединяется с SSH-сервером, тогда отсутствует завязка на privoxy
Потом ходить через него почтовыми клиентами, тоже с proxychains4, так получается более унифицированный подход.
В смысле mpop перед fetchmail?
1. Доставляет почту в разы быстрее
2. Настройки msmtp целиком переносятся на mpop, в том числе настройки SSL и местонахождение сертификатов. Заменить только номера портов (995 вместо 465) и указать MDA.
3. Простой компактный код вместо старого и разросшегося, содержащего ненужные возможности. Полнофункциональный POP3-клиент (в fetchmail ещё ещё IMAP) и ничего лишнего, типичный unix-way. Объём и качество кода напрямую влияют на безопасность.
4. Отличная документация, которую можно рассматривать и как учебник. Мануал mpop в 3 раза меньше.
mpop vs fetchmail[link12]
Не так долго пользовался fetchmail, поэтому не эксперт в нём, возможно что-то упустил.
компиляция ./congifure; make; make install занимает пару минут. Зависимости отсутствуют, за исключением стандартного libc.
В теме про gmail приводился список бесплатных сервисов, ориентированных на приватность и лояльных к тору. Возможно, не так активно пользуюсь электонной почтой, но с блокировками доступа через Tor пока не сталкивался.
Интересный метод, не подумал бы о таком, спасибо.
Наверно. :)
Это мне нравится. А у кого-нибудь из аналогов msmtp есть такой же pinning?
Номера портов, на которых слушает POP3-сервер, определяет сервер. Как они могут зависеть от типа POP3-клиента?
Из популярных почтовиков:
Опция tls-fingerprint удобна когда сертификат сервера подписан УЦ, которого нет в стандартного связке или сама связка по какой-то причине отсутствует. Можно опцию всегда использовать, так даже безопасней, т.к. указывается хеш сертификата напрямую, а не полагается на доверие к УЦ. Но в таком случае нужно периодически менять хеш вручную в mpoprc/msmtprc при смене сертификата. Насчёт аналогичных опций в других клиентах не знаю.
Номера портов нужно менять после копирования настроек из msmtprc в mpoprc.
msmtp-таки тоже поддерживает pinning, значит?
Да, поддерживает. Как уже писал, опции msmtp и mpop идентичны и отличаются только по части протоколов (SMTP и POP3).
Перевёл mcabber и ssh с proxychains и privoxy на torsocks, полёт нормальный. Спасибо ещё раз за совет.
msmtp не тестировал, но с fetchmail (хотел его тоже перевести) не взлетело. Открываю SOCKS-порт через ssh -D, натравливаю на него fetchmail. Если это делать через torsocks, то он пишет:
Наверно, это не имеет смысла: use_from — это же только простановка email-адреса отправителя(?).
Сделал:
tsocks doesn't seem to be working for SSH, why?[link17] Неясно, о чём это.
proxychains4 msmtp и mpop нормально работают через ssh-прокси. torsocks действительно не работает (нет DNS разрешения), почему – не знаю.
Не ясно, зачем включать опцию hidden_host, которая судя по описанию не влияет на Message-ID.
Лучшее значение hostname для Message-ID это адрес SMTP-сервера, как наиболее распространённое поведение. В идеале msmtp должен автоматически модифицировать этот заголовок, используя значение host из msmtprc. Возможно имеет смысл обратиться по этому поводу к разработчику в рассылке, там сейчас наблюдается движение в сторону поддержки Тора. В последние версии msmtp и mpop включена поддержка SOCKS-прокси.
Раньше SSH-клиент был суидным, а для таких программ динамические библиотеки не подгружаются в целях безопасности.
А как 4-я версия делает DNS-резолвинг? В третьей адрес 4.2.2.2 вбит гвоздями. Те, кому не нравится, должны редактировать[link18].* По уму резволвинг должен делаться на стороне SOCKS-сервера (в случае ssh -D — на сторое SSH-сервера, используя его локальные настройки DNS). Так ли это в четвёртой версии?
Странно то, что он, как и proxychains, работает через LD_PRELOAD, поэтому отличий быть не должно. В man torsocks хотя поддержка DNS и заявлена, в секции BUG сказано, что она не работает — видимо, всё дело в этом.
ОК, убрал опции
Хорошая новость, но мой msmmtp стар, в нём такой поддержки нет. Нового msmtp, наверно, не будет ещё очень долго.**
ОК, теперь некоторые странные замечания в мануале стали более понятными.
* Вписывать свой резолвер через конфиг proxychains не получится, поэтому придётся для каждого создавать свою копию системного файла в /usr — иначе резволверы для Tor'ов, работающих через разные порты, будут делаться через один порт, а это дополнительная корреляция.
** В jessie версии софта замораживаются? Если да, то они же потом войдут в будущий стабильный релиз, а обновление софта будет только в ещё более новом jessie/stable.
В ssh ещё ладно (я вписал IP-адреса вместо DNS-имён), но в mcabber написано именно DNS-имя для jabber-сервера, и это работает. Т.е. torsocks в каких-то случаях DNS-резолвинг всё-таки делает.
В proxychains4 с разрешением имён проблем нет, по умолчанию включена опция proxy_dns (она вроде и в версии 3.1 была). В torsocks аналогичная опция tordns_enable, по умолчанию тоже включена. С ними никаких DNS-утечек быть не должно.
Опцию mutt hostname на всякий случай лучше оставить.
И для apt-get DNS-резолвинг он тоже делает[link20].
Да, но дело не в DNS-утечках, а в том, через что[link21] они резволят и как.
ОК. По моим представлениям, msmtp должен её перезаписывать теми настройками, какие указаны в его конфиге (опция host), нет?
Выше уже написал, что proxychains4 (proxychains-ng) и torsocks (v1.3) по дефолту резолвят через SOCKS. У меня нет проблем с доступом к onion-сайтам через wget.
Не знаю, как там в некроверсиях (мне это не особо интересно), но даже в proxychains-3.1 нет принудительного разрешения через стронний DNS.
Для этого есть скрипт proxyresolv
Можно вообще без скриптов обходиться если определить переменную окружения
или
Ранее написал как в идеале должно быть, но пока этого нет и лучше определить переменную mutt hostname.
Да, через SOCKS, но через какой DNS-сервер-то? Всё, что я делаю через Tor, в норме резолится на экситах через те DNS-сервера, которые указаны локально в настройках этих экситов. Если это не так, это профилирование и лишняя утечка. Когда я использую proxychains, это не так, да.
Взаимоисключающие параграфы? Если я не горожу дополнительные костыли, хаки и переменные, при запуске proxychains (т.е., по умолчанию) весь резолвинг идёт через 4.2.2.2 — это профилирует по полной.
Раз onion-сайты загружаются, значит разрешение средствами Tor. Попробуйте .onion через 4.2.2.2 разрешить – не получится.
Да, в версии 3.1 скорей всего есть, библиотека-so видимо вызывает скрипт proxyresolv, который использует 4.2.2.2, поэтому onion-сайты наверное не открываются (это верно?). Но в новых версиях это не так, скрипт proxyresolv отсутствует, как и proxychains, вместо которого теперь бинарный файл proxychains4.
Даже если бы было так, то соединение с 4.2.2.2 всё-равно через Tor. Кроме этого, при использовании username-авторизации для разных приложений запросы идут по разным цепочкам, т.е. выходят с разных экситов. Так что не стоит драматизировать. А в новых версиях dig через 4.2.2.2 вообще нет, всё на экситах Tor разрешается.
Правда ваша:
По-моему, для некоторых доменов это работает, иначе я такие[link22] чудеса[link21] никак не могу объяснить.
Я для себя решил авторизацией не заморачиваться, а вместо этого всё разрулить по разным SocksPort'ам Tor'а — это намного проще.
Перед тем, как лезть руками в proxyresolv, решил понять, можно ли для некоторых хостов вручную прописать IP. Сделал так для fetchmail, после этого он мне пишет:
Кстати, эти предупреждения пишутся и писались всегда. Неужели каждый раз, когда я скачиваю почту, fetchmail пытается сделать DNS-резволинг моего локального hostname через внешний DNS-сервер? И что не так с моим hostname? Прописал удобное слово в качестве него (естественно, резолвится по DNS оно не будет, но это и не нужно). В /etc/hosts закомментировал всё, что касается IPv6, оставил только это:
Кстати, ssh-туннели при запуске через костыль corkscrew → privoxy → tor сдыхают крайне быстро. Возможно, дело в каких-то таймаутах privoxy. А при торификации через torsocks туннели живут долго.
В стандартном pkgsrc его нет, но он есть[link23] в wip'е. В принципе, можно рискнуть поставить[link24]...
Добавить произвольную строку на место user/pass в proxychains.conf или torsocks.conf проще чем создавать под каждое приложение свой SocksPort и помнить соответствие между ними. В torsocks авторизация добавляется путём изменения двух строк в глобальном /etc/torsocks.conf (можно изменить при конфигурации ./configure опцией conf-file FILE)
Вместо имени пользователя автоматически будет подставляться системный пользователь, от имени которого запускается приложение. Но надёжней указывать пользователя в командной строке
По умолчанию 5 минут, меняется опцией socket-timeout. Есть ещё keep-alive-timeout и default-server-timeout, но они по-видимому для обычных HTTP-запросов, а не TCP-туннеля через CONNECT.
А разве в torrc не нужно будет также указывать все эти логины и пароли? Их что, совсем от балды задают?
Да, Tor их не проверяет. Главное чтобы они отличались, тогда работает флаг IsolateSOCKSAuth и используются разные цепочки.
Если юзер один, а пароли разные, этого тоже будет достаточно для разделения?
А кто знает ответ на такой вопрос:
в одном конфиге нашел строку:
Эта информация присутствует в хедере и получивший письмо может её прочитать. Однако, судя по смыслу текста, эта информация предназначена не получателю, а митму. Вопрос: какими средствами митм (да что там митм, просто админ сети, в которой пересылается сообщение) может прочитать этот хедер? Речь идет о линуксах или freebsd.
сорри, не отвечайте здесь. Создал новую тему[link25].
Если это часть заголовков почты, то просмотром заголовков прочитать можно. Большинство web-интерфейсов имеют эту опцию (show original).
Достаточно, это несложно проверить. Авторизация в Tor отличается от стандартной username, и у меня информация только из экспериментов. Не уверен, что все детали где-то описаны, кроме программного кода. Многие вещи проще самому проверить, чем искать в документации.
А как проверяли? Читали код? Или анализировали строящиеся цепочки на низком уровне через какой-нибудь tor-arm?
Конкретно эта фича вроде как заявлена, так что должно работать, но трудность её верифицируемости (как и многих других фич) меня смущает. Трудно жить, когда ни к чему нет стопроцентного доверия. В документации они могут написать одно, а на деле будет происходить другое; они могут знать об этом, но ничего не делать.
Заявлено, что TBB ничего не пишет вне своей директории, а это не так[link26]. Разработчики об этом знают, но не исправляют. Уже три года как не исправляют. Ими признанный всесторонний анализ утечек[link27] ещё более удручающ, но они не чешутся. А на бумаге и в документации всё гладко, да. Исправили ли они утечку[link28] версии ОС (и ещё много чего) при включённом JS? Непонятно. Также непонятна ситуация с вытягиванием списка шрифтов[link29] из системы (даже без JS). Внимательно следящие за багтрекером наверняка скажут, что в любой момент времени известны десятки критических уязвимостей, которые могут не исправляться годами. Судя по всему, к разработке самого Tor'а они примерно так же[link30] относятся.* Это всё снова возвращает к тому же вопросу: во что мы верим и чему доверяем.
Да, но есть риск завязаться на некоторое свойство, которое не заявлено в документации, и которое в следующих релизах может поменяться, а вы не заметите — это даже при условии, что в одного можно проанализировать код Tor'а. В индустрии оупенсорца такое часто бывало: огромное количество софта решило завязаться на недокументированные особенности интерфейсов, а когда разработчики выпустили новую версию и «всё сломалось», начинается вой и поиск виноватых.
Разделение по портам для изоляции цепочек явно оговорено в документации и имеет то преимущество, что можно разнести юзеров файерволлом. Когда нужно железно исключить вмешательство одних программ (из-под одного юзера) в работу других (из-под другого юзера), изоляция по портам — самое то. В этом случае зловред при всём желании не сможет залезть в чужую цепочку (если только в самом Tor'е на эту тему баги не будет).
* У unknown'а был комментарий (всё перерыл, не могу найти) на тему того, что какую-то редкую опцию в Tor-клиенте (то ли поддержка приватных скрытых сервисов, то ли ещё что) они несколько раз ломали, из-за чего чуть ли ни месяцами все такие сервисы были де факто нерабочими. При всём этом в рассылке и багтрекере никто не пожаловался ни разу.
А я в том коментарии хотел найти то ли соответствующий комент в рассылке, то ли в торблоге, то ли в тикетах, всё перерыл, так и не нашёл. Но проблема такая точно есть.
Для проверки можно просто запрашивать страницу, меняя имя пользователя
В первом и третьем случаях адрес будет одинаковым, отличным от второго.
То же можно сказать про всё остальное, в том числе разделение цепочек по портам.
Разделение цепочек по пользователям официально заявлено и применяется по умолчанию. Использование разных имён пользователей должно давать разные цепочки, является логичным и скорей всего такое поведение сохранится в дальнейшем. Конкретно ваш вопрос по смене цепочек для разных паролей в документации не отражён, но проверяется легко если возник такой интерес, но полагаться на такое поведение в будущем не стоит.
Разделение по пользователям тоже явно оговорено, разнести их ещё легче – запускать программы с правами разных системных пользователей (что само по себе повышает безопасность), у которых конфигурационные файлы, содержащие user/pass, недоступны для чтения всем. Например, файлы /.torsocks.conf или /.proxychains/proxychains.conf будут одинаковы для всех пользователей, отличаясь только двумя строками – для user и password. Разные системные пользователи не будут знать эти данные друг у друга. Если один из них скопрометирован, он не сможет получить доступ к цепочках других пользователей, т.к. не знает их имён и паролей на Tor. В итоге получается проще – не нужно создавать для каждого пользователя SOCKS-порт, защищать его файрволом и помнить соответствие между именем пользователя и номером порта.
Если не используется прозрачная торификация, то проксифицировать программы в любом случае нужно, независимо от того, разделяются ли цепочки по портам или именам пользователей. Но в первом случае необходимо ещё править torrc и правила iptables, а во-втором достаточно лишь добавить строку в torsocks.conf или proxychains.conf. Т.е. в первом случае нужно править три файла и помнить связи между ними, а во втором только один файл и помнить ничего не нужно, т.к. SOCKS-порт один на всех.
В целом согласен, но, с другой стороны, появляется единая точка отказа: если где-то по ошибке забыли поставить уникальный пароль (при копировании конфигов между пользователями) или вообще забыли указать какой-либо пароль, то цепочки смешаются, а при разделении по портам, если где-то будет ошибка в конфигурировании, то, скорей всего, она будет выявлена намного быстрее, потому что просто не заработает.
Потом есть впрос диагностики. Я иногда смотрю на монитор типа netstat, там есть статистика. Есть статистика пакетов и в правилах iptables-save -c. Она показывает, через какой порт сколько пакетов прошло, кто через какой порт работает и т.д. Это даёт дополнительную степень свободы для контроля.
Ещё мне интуитивно кажется, что когда на один и тот же порт суются программы от разных юзеров, которые не должны взаимодействовать между собой (в идеале) вообще никак, шансы на утечки информации между ними повышаются. Возможно, это мои необоснованные иррациональные страхи из-за недостатка знаний.
Unknown, перестаньте издеваться, дайте ссылку на тот свой комментарий! ☺ Или вы его теперь тоже не можете найти? На форуме под 100k комментариев, и хотя память у меня не совсем дырявая, я уже приближаюсь к своему
квантовомуфизическому пределу на то, чтобы помнить всё, где, что и по какому случаю было сказано. Сейчас за несколько месяцев здесь появляется больше новых и содержательных комментариев, чем раньше появлялось за несколько лет, тема ИБ разрастается и в ширь и в глубь...Нашёл не свой[link31]:
И это ноябрь 2014 года, а оно всё ещё не работает гарантированно.
Спасибо! Буду ссылаться теперь на вас при надобности.
Одну точку отказа легче контролировать, чем несколько. Всё зависит от того, как организовать. Можно например держать где-нибудь (/somedir) конфигурационные файлы, на которые при очередной установке делается символическая ссылка из нужного места
Или создать скрипт для запуска torsocks/proxychains, который берёт имя пользователя из /dev/urandom. Тогда даже приложения с одинаковыми системными правами не будут знать друг у друга аутентификационные данные на Tor.
По отношению уровня безопасности к затратами на его поддержание, способ с аутентификацией представляется более выгодным и не таким костыльным, как с разделением по портам.
Мне так не кажется, порт это лишь способ передачи данных между процессами, а построение цепочек определяется ядром Tor-клиента. Ему без разницы, как получены данные – через один порт или несколько, номер порта это просто различитель, помечающий разные приложения, также как имя/пароль.
Ещё из старых обсуждений:
Аналогичное можно сказать про «для разных пользователей забыли указать разную авторизацию, или она у обоих слетела».
Если искать баланс между безопасностью и анонимностью, то, как уже в некоторых местах говорилось (и unknown соглашался, но точную цитату будет трудно найти), в критических случаях лучше одновременно не работать под разными несмешиваемыми профилями одновременно (даже через разные цепочки). Это даст некоторую вредную корреляцию, но прирост подстраховки в плане безопасности будет, наверно, её перекрывать.
Тоже про это подумал.
Да, технически его поддерживать проще (но с безопасностью я поспорил бы).
При разделении по портам нескольких точек отказа не возникает. Если вы напартачите в каких-то настройках, с вероятностью почти 100% трафик не сможет выйти в сеть. В случае с авторизацией если вы сделаете что-то не так, оно продолжит работать, как и раньше, внешне ничего не будет заметно.
Мне нравится идея финального контроля над трафиком со стороны рута. В случае разуливания файерволлом это так. Т.е. как бы юзеры ни извращались, и что бы и как бы там у них ни слетало (даже если они сговорятся вместе и согласовнно обнулят авторизацию), к чужим портам, а потому и цепочкам, они подцепиться не смогут. Считате, что под разными юзерами запущены трояны, и они должны понять, на одной машине они работают или на разных. Только если у них не получается это выяснить, система безопасна.
Кстати, по поводу разделения цепочек: Tor мог бы делать их разными по умолчанию, если трафик идёт от разных системных юзеров. Делает ли он так? Или у него юзеры только в смысле явных имён в SOCKS-авторизации?
Трояны укажут переменной свой конфиг для proxychains/torsocks, где не будет никакой авторизации. Так два разных юзера пойдут по одним цепочкам. В случае разруливания файерволлом эта дырка закрывается, а в вашем нет.
Как и для gpg[link36].
Торовский демон не резолвит имена системных юзеров. Для того, чтобы парсить имена юзеров в локальном трафике нужно иметь права рута, без которых тор, к счастью, обходится.
При прозрачной торификации ему уже дают[link37] права, сравнимые с правами рута для чтения всего трафика, без них прозрачка не заработает. Например, в случае BSD это право на чтение[link38] /dev/pf.
Т.е. конкретно в случае прозрачной торификации от добавления ещё и разруливания трафика по разным системным пользователям Tor мало бы что потерял.
Можно указать в настройках пользователя и iptables не тот порт, тогда для разных пользователей будет одна цепочка. Но в целом да, вероятность выйти в сеть с неправильными настройками меньше.
Уже упоминал[link39] в этой теме, что для torsocks это так. Достаточно определить опции server_port и default_pass в глобальном конфигурационном файле, тогда для разделения цепочек можно обойтить без файлов для каждого пользователя (/home/wget/.torsocks.conf и т.д.). Можно ли полагаться на это в будущих версиях – не знаю, но как дополниительная подстраховка сойдёт.
Во-первых, у каждого системного пользователя свои переменные окружения, которые друг с другом не пересекаются. Во-вторых, указывать пользователей и пароли в переменных окружения вообще не рекомендуется, т.к. их можно увидеть в списке процессов. Лучше указывать только путь к конфигурационному файлу, права на чтение которого имеет только правильный пользователь.
Это делает не Tor, а torsocks если в его настройках указана версия SOCKS 5 и дефолтный пароль. Тогда он видимо подставляет при аутентификации на Tor имя или идентификатор системного пользователя в случае когда он не указан опцией или переменной окружения. В proxychains такой особенности не наблюдается.
Да, мне нужно будет ошибиться в двух местах сразу: как в конфигах целевого пользователя, так и в конфиге для iptables. Если ошибка будет только в одном месте, программы просто не соединятся с сетью. Более того, пока я настраивал разруливание трафика и его фильтрацию, неоднократно отлавливал разные баги в конфигурации именно этим методом: вдруг не работало что-то, что должно было работать.
Не понимаю, что мешает трояну создать свой файл torsocks.conf, а потом выполнить команду[link40]
В моём примере всё так и есть. Под двумя разными системными юзерами работают трояны. Они согласованно через TORSOCKS_CONF_FILE выставляют себе одинаковые конфиги torsocks.conf и начинают работать через одинаковые цепочки.
Такое возможно, т.к. Tor не проверяет имя и пароль. При нормальной username-аутентификации подобная возможность была бы исключена. Эту проблему можно решить добавлением между приложениями и Тором SOCKS-сервера со стандартной аутентификацией, но такое решение вряд ли подходит для всех, несмотря более высокую защиту и возможность подробной статистики (по пользователям, портам, IP-адресам, объёму трафика).
Если ваши трояны могут выполнять произвольные команды в системе (как torsocks/proxychains), значит они могут посылать на заданный внешний адрес идентификационные данные системы, например вывод dmesg. Это более сильная и вероятная атака, чем смешение трафика пользователей в одной цепочке, и ваш разброс по портам от неё не защитит. Так что вопрос целесообразности усложнения от разброса пользователей по SOCKS-портам остаётся.
Внеся дополнительные опции в torrc его разве нельзя научить проверять имя/пароль?
Верно. По-хорошему, можно хоть своё DPI замутить (не вы ли его предлагали[link41]?), но есть решение для бедных: разнести по разным портам и ловить статистику на них, iptables-save -c её показывает. Наверняка есть ещё более удобные инструменты. Лично мне нравится pftop, наверняка для iptables есть подобный инструмент. В некотором смысле tor-arm, правда, даёт это и даже больше из коробки. Там, наверно, тоже как раз удобно смотреть в зависимости не от авторизации, а от номера SocksPort'а (unknown бы точнее сказал).
Совершенно верно, но никто и не говорил, что это единственная контрмера. Дальше будет паравиртуализация[link42] с целой деревней домов[link43]. Впереди нас ждёт много увлекательных открытий и срачей на pgpru на тему Xen и ему нужных приблуд. Strong anonymity — наше всё[link44]. Лично я голосую за беспомпромиссную безопасность[link45].
Если найдёте в мане эти дополнительные опции, сообщите. Пока видел только аутентификацию для контрольного порта, а также для HTTP и SOCKS-проксей между клиентом а входной нодой.
Если дальше накручивать, то возможно дополнительные тор-порты усилят безопасность. Но в контекте рядового использования особого преимущества в них не нахожу.
В системе может быть с десяток заторенных приложений, если для каждого свою виртуалку создавать, то никаких ресурсов не хватит. Вы ради каждой консольной утилиты типа wget, msmtp, fetchmail, gpg и т.д. собираетесь это делать? Понимаю, когда сложное и критичное приложение, как веб-браузер, запускают в виртуалке, но для консольных утилит проще chroot организовать, идентификация системы при этом тоже сильно затрудняется.
Виртуалки создаются не на приложения, а не «профиль» (на юзера). Дальше этот юзер может запускать сам, что захочет.
Конечно, в первую очередь, для него.
Нет. Допустим, есть профиль «работа с почтой». Его можно запустить в отдельной гостевой ОС и дать возможность выполнять оттуда всё, что захочется (получение почты, отправка; при желании и надобности — другие консольные утилиты). Важно, что информация будет только почтовая, поэтому при компрометации ничего более, чем БД почты, утечь не может.
Использование чрута для безопасности/анонимности — распространённое заблуждение[link46]. Даже LXC заблуждение:
А SELinux'а для анонимности нет (скрытие информации о железе), поэтому остаются только (настоящие) виртуалки.
Мне кажется, вы не понимаете, о чём идёт речь. Тут нет никаких «из-под одного юзера через sudo/su/gksu выполняем что-то». Есть физически разные иксы, они на разных дисплеях, под разными иксами выполяняются разные задачи. Например, под одними — только работа с вебом через TorBrower (при желании можно и ситуативное консольное что-то запускать, но никакой информации к настоящим хоумам там нет). Под другим — только джабберы, почта, ssh-тунели и gpg и некоторые приложения, не требующие работы с сетью (pdf, TeX, djview). Под третьим — только мультимедиа, он вообще доступа к сети не имеет, только на lo (музыка, проигрыватели видео, gimp'ы и прочая работа с графикой). Как-то так. Но сейчас это, допустим, три разных пользователя, а могло бы быть три разных гостевых ОС в виртуалке. Деление не обязательно должно быть именно таким, это просто общий набросок идеи. Деление идёт, в первую очередь, не по программам, а по ролям доступа к информации того или иного класса.
Вот у меня скажем 5-8 профилей и иксы с минималистичным оконным менеджером железо потянет, но не пять или восемь виртуалок, которые на некотором старье не взлетят.
Да и обновлять все пакеты и конфиги в каждой из пяти виртуалок — то ещё развлечение. Я понимаю все преимущества виртуалок и когда-нибудь может до них дойду, но пока долго буду сидеть на компромиссе с параллельными иксами.
Правильней наверное создавать профили не под приложения, а под виртуальные личности. Например: пользователь госуслуг, обычный пользователь для сёрфинга, блоггер, компьютерный специалист и т.п. Если вы в одном профиле смешаете почту для разных виртуалов, это приведёт к профилированию каждого из них и подрыву анонимности тех, для кого она наиболее критична.
Внутри одного профиля, создаваемого виртуальной машиной, разделение цепочек для разных приложений тоже необходимо. Трафик веб-сёрфинга лучше не смешивать с почтой и мессенджерами, иначе профилирование псевдонима накапливается и способствует раскрытию его реальных данных.
При использовании виртуальных машин разброс по портам и SOCKS-аутентификация дополняют друг друга. Для каждой вирт. машины выделяете тор-порт, а цепочки каждого приложения внутри одной машины изолируете аутентификацией. Приложения внутри одной ВМ тоже можно по портам раскидать вместо аутентификации на Tor, но особого смысла в таком усложнении уже нет – от идентификации виртуальной системы это не спасёт при компрометации её пользователей.
Разные машины, реальные или виртуальные, которые по-разному идентифицируются, наверное имеет смысл по разным Tor-портам раскидать. Но приложения внутри одной машины практичней разделить Tor-аутентификацией.
В таком случае ещё проще – трафик разных машин автоматически разделяется по внутренним IP-адресам, а трафик разных приложений внутри одной машины разделяется аутентификацией, и достаточно одного тор-порта. Вместо добавления новых портов для мониторинга лучше наверное arm использовать.
Да, это и имелось в виду, просто плохо выразился. В моём случае большинство юзеров очень специфичны, поэтому разделение по программам почти эквивалентно разделению по «виртуальным личностям», но в общем случае, это, конечно, не так.
Здесь[link49] есть предостережения общего характера, которые непонятны (в некоторых случаях wget может пытаться отрезолвить localhost через локальный DNS?). Ещё есть старое обсуждение[link50] в рассылке с участием Руны Сандвик, Каммерера и других лиц. Понятно, что торифицировать wget можно по-разному (через переменные среды или через LD_PROLOAD, как это делает torsocks/proxychains), и утечки DNS могут быть как зарезаны, так и нет файерволлом, в зависимости от этого будут разные выводы про «безопасность использования».
Вопрос профилирования тоже ясен, это не TBB, но всё может быть ещё хуже, если в каких-то случаях wget сообщает локальный IP-адрес машины, где он запущен. В рассылке были спекуляции на тему пассивного режима ftp, когда это якобы может происходить, но Каммерер говорит, что даже в этом случае такого не наблюдается, wget передаёт всего лишь адрес localhost'а. Впрочем, так ли это при всех типах торификаций wget (в т.ч. через torsocks) — непонятно. Может ли злонамеренный HTTP-сервер сделать редирект на ftp, принудив wget передать локальный IP-адрес хоста? Достаточно ли надёжно вариант torsocks wget от этого застрахован?
Проще, конечно, не надеяться на костыли, а по возможности запускать всё в виртуалках. Впрочем, если системные апдейты качаются через torsocks wget, эта проблема возникнет и на хостовой системе.
В man wget пишут
Правда, это не про редирект, но информация полезная.
Проверил редирект. Увы, работает:
Скорее, всё же активного. По умолчанию, судя по
режим может быть только пассивным:
Спасибо за проверку. Похоже, wget — слишком умная тулза, чтобы быть анонимной и безопасной. Умеет намного больше, чем от неё могут поначалу ожидать.
Мне тоже кажется, что будет отдавать IP=127.0.0.1. Обычно FTP-клиент определяет локальный IP так: он делает getsockname для основного FTP-соединения (исходящего) и отдает полученный IP. Основное соединение будет с 127.0.0.1. Вот если там прозрачная торификация, то не знаю, может быть засада.
Похоже, что изоляция цепочек по портам вообще не работала. Фатальный баг.
Баг[link54] исправлен[link55].
Даа, ничему нельзя доверять, подставы на каждом шагу:(
Спасибо за ссылки.
Консольные утилиты при прочих равных считаются безопаснее комбайнеров, но не стоит забывать про пределы применимости этого мнения: