id: Гость   вход   регистрация
текущее время 02:21 02/05/2024
Автор темы: Гость, тема открыта 10/06/2011 12:01 Печать
Категории: софт, анонимность, инфобезопасность, tor, защита email, свободный софт
создать
просмотр
ссылки

Торификация mutt


Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.



 
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Комментарии
— Гость (12/02/2015 23:13)   <#>
В proxychains4 с разрешением имён проблем нет, по умолчанию включена опция proxy_dns (она вроде и в версии 3.1 была). В torsocks аналогичная опция tordns_enable, по умолчанию тоже включена. С ними никаких DNS-утечек быть не должно.

Опцию mutt hostname на всякий случай лучше оставить.
— Гость (13/02/2015 00:02)   <#>

И для apt-get DNS-резолвинг он тоже делает.


Да, но дело не в DNS-утечках, а в том, через что они резволят и как.
$ cat /usr/lib/proxychains3/proxyresolv
#!/bin/sh
# This script is called by proxychains to resolve DNS names
 
# DNS server used to resolve names
DNS_SERVER=${PROXYRESOLV_DNS:-4.2.2.2}
 
 
if [ $# = 0 ] ; then
        echo "  usage:"
        echo "          proxyresolv <hostname> "
        exit
fi
 
 
export LD_PRELOAD=libproxychains.so.3
dig $1 @$DNS_SERVER +tcp | awk '/A.+[0-9]+\.[0-9]+\.[0-9]/{print $5;}'
В третьей версии DNS=4.2.2.2 по-прежнему зашито статикой. ☹ В четвёртой также? В отличие от proxychains torsocks, думаю, корректно резволит DNS через Tor — хотя бы по-этому его использование там, где возможно, предпочительнее.


ОК. По моим представлениям, msmtp должен её перезаписывать теми настройками, какие указаны в его конфиге (опция host), нет?
— Гость (13/02/2015 01:06)   <#>
дело не в DNS-утечках, а в том, через что они резволят и как

Выше уже написал, что proxychains4 (proxychains-ng) и torsocks (v1.3) по дефолту резолвят через SOCKS. У меня нет проблем с доступом к onion-сайтам через wget.

Не знаю, как там в некроверсиях (мне это не особо интересно), но даже в proxychains-3.1 нет принудительного разрешения через стронний DNS.



Для этого есть скрипт proxyresolv



Можно вообще без скриптов обходиться если определить переменную окружения



или



msmtp должен её перезаписывать теми настройками, какие указаны в его конфиге (опция host)

Ранее написал как в идеале должно быть, но пока этого нет и лучше определить переменную mutt hostname.
— Гость (13/02/2015 01:41)   <#>

Да, через SOCKS, но через какой DNS-сервер-то? Всё, что я делаю через Tor, в норме резолится на экситах через те DNS-сервера, которые указаны локально в настройках этих экситов. Если это не так, это профилирование и лишняя утечка. Когда я использую proxychains, это не так, да.


Взаимоисключающие параграфы? Если я не горожу дополнительные костыли, хаки и переменные, при запуске proxychains (т.е., по умолчанию) весь резолвинг идёт через 4.2.2.2 — это профилирует по полной.
— Гость (13/02/2015 02:39)   <#>
Раз onion-сайты загружаются, значит разрешение средствами Tor. Попробуйте .onion через 4.2.2.2 разрешить – не получится.

нет принудительного разрешения через стронний DNS

Да, в версии 3.1 скорей всего есть, библиотека-so видимо вызывает скрипт proxyresolv, который использует 4.2.2.2, поэтому onion-сайты наверное не открываются (это верно?). Но в новых версиях это не так, скрипт proxyresolv отсутствует, как и proxychains, вместо которого теперь бинарный файл proxychains4.
— Гость (13/02/2015 02:47)   <#>
весь резолвинг идёт через 4.2.2.2 — это профилирует по полной

Даже если бы было так, то соединение с 4.2.2.2 всё-равно через Tor. Кроме этого, при использовании username-авторизации для разных приложений запросы идут по разным цепочкам, т.е. выходят с разных экситов. Так что не стоит драматизировать. А в новых версиях dig через 4.2.2.2 вообще нет, всё на экситах Tor разрешается.
— Гость (13/02/2015 03:15)   <#>

Правда ваша:
$ proxychains wget http://zqktlwi4fecvo6ri.onion/wiki/index.php/Main_Page
ProxyChains-3.1 (http://proxychains.sf.net)
--2015-02-13 00:07:10--  http://zqktlwi4fecvo6ri.onion/wiki/index.php/Main_Page
Resolving zqktlwi4fecvo6ri.onion (zqktlwi4fecvo6ri.onion)...
|DNS-request| zqktlwi4fecvo6ri.onion 
|S-chain|-<>-127.0.0.1:9050-<><>-4.2.2.2:53-<><>-OK
|DNS-response|: zqktlwi4fecvo6ri.onion does not exist
failed: Unknown error.
wget: unable to resolve host addresszqktlwi4fecvo6ri.onion
Всё так.


По-моему, для некоторых доменов это работает, иначе я такие чудеса никак не могу объяснить.


Я для себя решил авторизацией не заморачиваться, а вместо этого всё разрулить по разным SocksPort'ам Tor'а — это намного проще.
— Гость (13/02/2015 03:30)   <#>
Перед тем, как лезть руками в proxyresolv, решил понять, можно ли для некоторых хостов вручную прописать IP. Сделал так для fetchmail, после этого он мне пишет:
fetchmail: Warning: the connection is insecure, continuing anyways.
(Better use --sslcertck!)
От греха подальше вернул всё как было. Потом думаю, ладно, пропишу сервер в /etc/hosts. Прописал, после этого:
ProxyChains-3.1 (http://proxychains.sf.net)
|DNS-response|: MYHOSTNAME does not exist
gethostbyname failed for MYHOSTNAME
Unknown errorCannot find my own host in hosts database to qualify it!
Trying to continue with unqualified hostname.
DO NOT report broken Received: headers, HELO/EHLO lines or similar problems!
DO repair your /etc/hosts, DNS, NIS or LDAP instead.
|S-chain|-<>-127.0.0.1:XXXXX-<><>-X:X:X:X:XXX-<><>-OK
fetchmail: No mail for LOGIN at POP3_SERVER
С одной стороны, хорошо, оно более не резолвится, но я же не хочу давать права на чтение файла /etc/hosts с уникальными хостами вообще всем, а если дам на чтение только конкретной группе, то у других программ из-за этого могут начаться проблемы (не будут ли они 127.0.0.1 пытаться разрешить через внешний DNS-сервер?).

Кстати, эти предупреждения пишутся и писались всегда. Неужели каждый раз, когда я скачиваю почту, fetchmail пытается сделать DNS-резволинг моего локального hostname через внешний DNS-сервер? И что не так с моим hostname? Прописал удобное слово в качестве него (естественно, резолвится по DNS оно не будет, но это и не нужно). В /etc/hosts закомментировал всё, что касается IPv6, оставил только это:
127.0.0.1       localhost
127.0.1.1       MYHOSTNAME
Что ему не нравится? Даже скрипт /etc/init.d/hostname.sh выполнил на всякий случай.
— Гость (13/02/2015 07:47)   <#>
Кстати, ssh-туннели при запуске через костыль corkscrewprivoxytor сдыхают крайне быстро. Возможно, дело в каких-то таймаутах privoxy. А при торификации через torsocks туннели живут долго.
— Гость (13/02/2015 08:54)   <#>

В стандартном pkgsrc его нет, но он есть в wip'е. В принципе, можно рискнуть поставить...
— Гость (13/02/2015 10:22)   <#>
Я для себя решил авторизацией не заморачиваться, а вместо этого всё разрулить по разным SocksPort'ам Tor'а — это намного проще.

Добавить произвольную строку на место user/pass в proxychains.conf или torsocks.conf проще чем создавать под каждое приложение свой SocksPort и помнить соответствие между ними. В torsocks авторизация добавляется путём изменения двух строк в глобальном /etc/torsocks.conf (можно изменить при конфигурации ./configure опцией conf-file FILE)



Вместо имени пользователя автоматически будет подставляться системный пользователь, от имени которого запускается приложение. Но надёжней указывать пользователя в командной строке



дело в каких-то таймаутах privoxy

По умолчанию 5 минут, меняется опцией socket-timeout. Есть ещё keep-alive-timeout и default-server-timeout, но они по-видимому для обычных HTTP-запросов, а не TCP-туннеля через CONNECT.
— Гость (13/02/2015 10:34)   <#>
А разве в torrc не нужно будет также указывать все эти логины и пароли? Их что, совсем от балды задают?
— Гость (13/02/2015 11:10)   <#>
Их что, совсем от балды задают?

Да, Tor их не проверяет. Главное чтобы они отличались, тогда работает флаг IsolateSOCKSAuth и используются разные цепочки.
— Гость (13/02/2015 14:09)   <#>
Если юзер один, а пароли разные, этого тоже будет достаточно для разделения?
— koshkin (13/02/2015 14:36)   <#>
А кто знает ответ на такой вопрос:

в одном конфиге нашел строку:


Эта информация присутствует в хедере и получивший письмо может её прочитать. Однако, судя по смыслу текста, эта информация предназначена не получателю, а митму. Вопрос: какими средствами митм (да что там митм, просто админ сети, в которой пересылается сообщение) может прочитать этот хедер? Речь идет о линуксах или freebsd.
На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3