Торификация 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 След.

Комментарии

—	unknown (07/01/2015 23:27, исправлен 07/01/2015 23:29) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

>«mutt* → privoxy → Tor → remote SSH-server → mail-server»

>в качестве MDA лучше использовать локальный SMTP-сервер, который в любом случае нужен.

>Это было бы уже совсем монструозно.

Может удалённо почтовый сервер поставить? На том же серваке, где крутится SSH. А если он будет запущен как скрытый сервис, то он будет гарантировано принимать почту для отправки, оставляя в логах в качестве адреса отправителя только локалхост. К тому же его можно настроить, чтобы он перебивал заголовки почтовой программы по типу ремейлера. Правда, смысл иметь ремейлер на одного пользователя неясен, но это зависит от того, куда перенаправлять собираются почту.

—	*Гость* (08/01/2015 10:32) <#>

Почту надо забирать, показывая mail-серверу нейтральный IP, т.е. Tor-эксит не канает, поэтому выбирается фиксированный SSH-сервер, доступ к которому уже идёт через Tor

Проще купить доступ к SOCKS-серверам и пользоваться proxychains с цепочкой из двух узлов – Tor и коммерческий SOCKS. Всё равно SSH-сервер у вас на платном VPS. SOCKS дешевле, не требует настройки и его легче сменить.

proxychains не умеет разные конфиги

В 4 версии путь к конфигурационному файлу можно указать опцией командной строки -f или переменной окружения PROXYCHAINS_CONF_FILE. В torsocks (бывший tsocks) тоже можно менять настройки переменными окружения (man 8 torsocks), по крайней мере в версиях до 1.3, новой версией 2.0 не пользовался. В torsocks.conf можно ещё указать свой SOCKS-сервер для каждой IP-сети или хоста.

из-за того, что какие-то программы надо выпустить просто через Tor, а другие ещё и через SSH-сервер за Tor'ом, нельзя обе SOCKS-прокси (Tor и SSH SOCKS) указать в конфиге proxychains как два звена одной цепочки прокси.

Как уже сказано, каждую программу можно запускать со своим proxychains.conf

Времени играться и перенастраивать все конфиги через другие тулзы пока нет.

Если разобраться с настройками msmtp, то осваивать mpop почти не требуется. Единственное существенное отличие – правильно указать строку с MDA. Конфигурационные файлы выглядят практически одинаково.

procmail запускается локально от того же юзера, который имеет доступ к почте

procmail может вызываться из fetchmail, mpop, SMTP-сервера и т.д., и наследует те же права. Речь шла от запуске MRA от пользователя, отличного от пользователя mutt, к почтовому ящику которого MRA->MDA не имеет прав доступа.

Уже есть какой-то иной proxychains — proxychains-ng

Немного усовершенствованния версия прежнего. Сейчас она самая актуальная, ей и пользуюсь.

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

Идеальный вариант – свой SMTP-сервер на VPS через Tor. Но иногда проще под конкретную задачу создать ящик на публичном сервисе. Иначе для каждого случая пришлось бы анонимно покупать VPS, что не всегда приемлемо по затратам.

—	*Гость* (08/01/2015 10:46) <#>

procmail может вызываться из fetchmail, mpop, SMTP-сервера и т.д., и наследует те же права

Поправка: в случае вызова из SMTP-сервера права root не наследуются, в этом весь смысл. Поскольку сервер запущен из под рута, он сам может сменить UID для procmail на пользователя mutt. Запускать procmail от рута небезопасно, программа старая и были какие-то сообщения о её уязвимостях.

—	*Гость* (08/01/2015 12:31) <#>

> Может удалённо почтовый сервер поставить? На том же серваке, где крутится SSH. А если он будет запущен как скрытый сервис, то он будет гарантировано принимать почту для отправки, оставляя в логах в качестве адреса отправителя только локалхост. К тому же его можно настроить, чтобы он перебивал заголовки почтовой программы по типу ремейлера.

Всё это можно, но гемор. Я вообще не люблю почтовый протокол, так уж сложилось. Так не хочется с этим всем глубоко разбираться... хотя можно было бы много чего сделать. Например, я без понятия, откуда msmtp/fetchmail черпают информацию о сертификатах, можно ли сделать своего рода certificate pinning и т.д.

> Проще купить доступ к SOCKS-серверам и пользоваться proxychains с цепочкой из двух узлов – Tor и коммерческий SOCKS. Всё равно SSH-сервер у вас на платном VPS.

Опять не угдалали. SSH-сервер крутится в организации, к которой я имею вполне конкретное отношение. Более того, я лично собственными руками настраивал этот SSH-сервер и подсоединял его к сети. И, да, я не плачу за его аренду ни копейки. Если этот сервак сдохнет, будет другой, но там уже без рутового доступа (или с рутовым, но без права хозяйничать, как захочется). Просто я не считаю нужным сообщать организации, на каком IP я работаю и где в каждый момент времени нахожусь, незачем это, потому доступ через Tor. Да и ISP не стоит знать о том, кто я такой, и на какие сервера я хожу, где работаю и т.д.

[пафос]
Даже временные контрактники ~~Booz Allen Hamilton~~ некоторых организаций имеют ряд пожизненных привелегий — к примеру, служебный email-адрес, который никогда не будет отобран, доступ к служебным PROXY- или SSH-серверам и т.д. Т.е. достаточно один раз в жизни попасть в списки ~~меченных властью~~, и потом всю оставшуюся жизнь можно иметь привелегии. Всё сильно зависит от страны и организации, но тренд такой прослеживается. Например, насколько я знаю, ящик в домене mit.edu является пожизненным. Среди иных приятных бонусов помимо собственно ящика у SSH- или PROXY-серверов обычно имеется подписка на огромную кучу журналов и трудов конференций, (множество оригиналов работ можно скачать бесплатно), а также бесплатный доступ к разным БД (scopus, ISI WoS и т.п.). В широких кругах мало об этом знают, но это очень приятные бонусы, т.к. персональная подписка на эти вещи стоит больших денег, и её мало кто себе может позволить. Если не оверклочить доступ, как Аарон Шварц, то всё будет ОК.
[/пафос]

В текущих стабильных Debian/Ubuntu по прежнему 2-3 версия, увы. Но tsocks можно было бы покурить, это хороший совет.

> Если разобраться с настройками msmtp, то осваивать mpop почти не требуется. Единственное существенное отличие – правильно указать строку с MDA. Конфигурационные файлы выглядят практически одинаково.

В чём преимущество mpop перед msmtp?

> Немного усовершенствованния версия прежнего. Сейчас она самая актуальная, ей и пользуюсь.

Вот только в Debian/Ubuntu в пакетах я её не вижу, а с сорсов компилить не хочется.

> иногда проще под конкретную задачу создать ящик на публичном сервисе.

Никто не спорит, вот только далеко не все публичные сервисы радушны к тем, кто входит в ящик через Tor. А из тех, кто не против, многие блокируются популярными почтовиками (из-за спама или ещё чего), да ещё имеют множество типичных проблем (маленький размер ящика, драконовские ограничения на размер аттачей и т.д.).

P.S. Моё понимание тренда таково: любой годный интернет-ресурс (будь то web-сайт, XMPP- или mail-сервер или что иное) должен давать доступ к себе как к HS. К счастью, с течением времени таких ресурсов становится всё больше.

—	*Гость* (08/01/2015 13:43) <#>

> Т.е., секция «Host *» должна идти в конце.

Тут логика, видимо, была такой: сначала парсятся юзерские конфиги, а потом системные, поэтому, чтобы первые имели приоритет перед вторыми, срабатывает именно первое упоминание ProxyCommand. Однако, могло бы быть иначе (причём это более традиционный, IMHO, способ в UNIX): сначала парсились бы системные конфиги, а потом домашние, а приоритет был бы у тех, которые парсятся последними, и тогда домашние так же перекрывали бы системные. В этом случае именно последнее упоминание ProxyCommand в конфиге перекрывало бы все остальные. Претензия здесь к тому, что в man'е используемая логика не отражена.

> Два равнозначных конфига ~/.ssh/config, написанных с учётом сказанного

Всё хорошо, но это не дружит с keychain-костылём [1], [2]. Более общо вопрос звучит так: как указать 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, кажется, тоже не учитывают порт. :(

—	*Гость* (08/01/2015 14:29) <#>

SSH-сервер крутится в организации, к которой я имею вполне конкретное отношение

Проще наверное создать локальный SOCKS-прокси, который через Tor соединяется с SSH-сервером, тогда отсутствует завязка на privoxy

proxychains4 ssh -D 127.0.0.1:1080 user@ssh-server.com

Потом ходить через него почтовыми клиентами, тоже с proxychains4, так получается более унифицированный подход.

В чём преимущество mpop перед msmtp?

В смысле mpop перед fetchmail?

1. Доставляет почту в разы быстрее
2. Настройки msmtp целиком переносятся на mpop, в том числе настройки SSL и местонахождение сертификатов. Заменить только номера портов (995 вместо 465) и указать MDA.
3. Простой компактный код вместо старого и разросшегося, содержащего ненужные возможности. Полнофункциональный POP3-клиент (в fetchmail ещё ещё IMAP) и ничего лишнего, типичный unix-way. Объём и качество кода напрямую влияют на безопасность.
4. Отличная документация, которую можно рассматривать и как учебник. Мануал mpop в 3 раза меньше.

mpop vs fetchmail

Не так долго пользовался fetchmail, поэтому не эксперт в нём, возможно что-то упустил.

Вот только в Debian/Ubuntu в пакетах я её не вижу, а с сорсов компилить не хочется.

компиляция ./congifure; make; make install занимает пару минут. Зависимости отсутствуют, за исключением стандартного libc.

далеко не все публичные сервисы радушны к тем, кто входит в ящик через Tor. А из тех, кто не против, многие блокируются популярными почтовиками

В теме про gmail приводился список бесплатных сервисов, ориентированных на приватность и лояльных к тору. Возможно, не так активно пользуюсь электонной почтой, но с блокировками доступа через Tor пока не сталкивался.

—	*Гость* (09/01/2015 01:50) <#>

> proxychains4 ssh -D 127.0.0.1:1080 user@ssh-server.com

Интересный метод, не подумал бы о таком, спасибо.

> В смысле mpop перед fetchmail?

Наверно. :)

# As an alternative to tls_trust_file/tls_crl_file, you can use tls_fingerprint
# to pin a single certificate. You have to update the fingerprint when the
# server certificate changes, but an attacker cannot trick you into accepting
# a fraudulent certificate. Get the fingerprint with
# $ mpop --serverinfo --tls --tls-certcheck=off --host=pop.freemail.example
tls_fingerprint 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33

Это мне нравится. А у кого-нибудь из аналогов msmtp есть такой же pinning?

> Заменить только номера портов (995 вместо 465)

Номера портов, на которых слушает POP3-сервер, определяет сервер. Как они могут зависеть от типа POP3-клиента?

> но с блокировками доступа через Tor пока не сталкивался.

Из популярных почтовиков:

Гмыло не дружит (вроде был какой-то трюк зарегаться и залогиниться без Tor, потом не тереть куки и дальше можно продолжать использовать ящик через Tor; позже, кажется, было разъяснение от гугла, что они целево блочат Tor — ссылки на оба факта тут на форуме приводились).
mail.ru вроде дружит, но не хочется хранить всю инфу на серверах ФСБ.
ukr.net позволяет регистрироваться только с украинских IP.

—	*Гость* (09/01/2015 06:57) <#>

Опция tls-fingerprint удобна когда сертификат сервера подписан УЦ, которого нет в стандартного связке или сама связка по какой-то причине отсутствует. Можно опцию всегда использовать, так даже безопасней, т.к. указывается хеш сертификата напрямую, а не полагается на доверие к УЦ. Но в таком случае нужно периодически менять хеш вручную в mpoprc/msmtprc при смене сертификата. Насчёт аналогичных опций в других клиентах не знаю.

Номера портов, на которых слушает POP3-сервер, определяет сервер. Как они могут зависеть от типа POP3-клиента?

Номера портов нужно менять после копирования настроек из msmtprc в mpoprc.

—	*Гость* (09/01/2015 11:46) <#>

> Нужно периодически менять хеш вручную в mpoprc/msmtprc при смене сертификата.

msmtp-таки тоже поддерживает pinning, значит?

—	*Гость* (10/01/2015 06:13) <#>

Да, поддерживает. Как уже писал, опции msmtp и mpop идентичны и отличаются только по части протоколов (SMTP и POP3).

—	*Гость* (11/02/2015 17:42) <#>

> Через Tor достаточно torsocks/proxychains4 ssh, комбайны с corkscrew и privoxy не нужны.

Перевёл mcabber и ssh с proxychains и privoxy на torsocks, полёт нормальный. Спасибо ещё раз за совет.

msmtp не тестировал, но с fetchmail (хотел его тоже перевести) не взлетело. Открываю SOCKS-порт через ssh -D, натравливаю на него fetchmail. Если это делать через torsocks, то он пишет:

fetchmail: getaddrinfo("pop.gmail.com","pop3s") error: 
  Non-recoverable failure in name resolution
POP3 connection to pop.gmail.com failed: No such file or directory
fetchmail: Query status=2 (SOCKET)

Если через tsocks, то пишет

fetchmail: getaddrinfo("pop.gmail.com","pop3s") error: 
  Temporary failure in name resolution
POP3 connection to pop.gmail.com failed: Resource temporarily unavailable
fetchmail: Query status=2 (SOCKET)

ssh через такую соксификацию работает, только если вместо хоста указать IP-адрес. Тут упоминали, что msmtp надо напрямую кормить IP-адресом. Здесь, видимо, та же проблема. А с proxychains всё работает и по DNS-именам.

> unset use_from

Наверно, это не имеет смысла: use_from — это же только простановка email-адреса отправителя(?).

> По заголовкам тут уже сказали – User-Agent убрать, Message-ID модифицировать (опции user_agent и hostname)

Сделал:

set user_agent=no
set hostname=""
set hidden_host=yes
set use_domain=no

Так будет нормально?

—	*Гость* (11/02/2015 17:48) <#>

tsocks doesn't seem to be working for SSH, why? Неясно, о чём это.

—	*Гость* (12/02/2015 19:13) <#>

proxychains4 msmtp и mpop нормально работают через ssh-прокси. torsocks действительно не работает (нет DNS разрешения), почему – не знаю.

Не ясно, зачем включать опцию hidden_host, которая судя по описанию не влияет на Message-ID.

Лучшее значение hostname для Message-ID это адрес SMTP-сервера, как наиболее распространённое поведение. В идеале msmtp должен автоматически модифицировать этот заголовок, используя значение host из msmtprc. Возможно имеет смысл обратиться по этому поводу к разработчику в рассылке, там сейчас наблюдается движение в сторону поддержки Тора. В последние версии msmtp и mpop включена поддержка SOCKS-прокси.

Раньше SSH-клиент был суидным, а для таких программ динамические библиотеки не подгружаются в целях безопасности.

—	*Гость* (12/02/2015 21:14) <#>

> proxychains4 msmtp и mpop нормально работают через ssh-прокси.

А как 4-я версия делает DNS-резолвинг? В третьей адрес 4.2.2.2 вбит гвоздями. Те, кому не нравится, должны редактировать.^* По уму резволвинг должен делаться на стороне SOCKS-сервера (в случае ssh -D — на сторое SSH-сервера, используя его локальные настройки DNS). Так ли это в четвёртой версии?

> torsocks действительно не работает (нет DNS разрешения), почему – не знаю.

Странно то, что он, как и proxychains, работает через LD_PRELOAD, поэтому отличий быть не должно. В man torsocks хотя поддержка DNS и заявлена, в секции BUG сказано, что она не работает — видимо, всё дело в этом.

> Не ясно, зачем включать опцию hidden_host, которая судя по описанию не влияет на Message-ID. Лучшее значение hostname для Message-ID это адрес SMTP-сервера, как наиболее распространённое поведение. В идеале msmtp должен автоматически модифицировать этот заголовок, используя значение host из msmtprc.

ОК, убрал опции

set hostname=""
set hidden_host=yes

из конфига. В msmtprc, конечно, host прописан. Главное — чтоб локальный hostname не утекал.

> В последние версии msmtp и mpop включена поддержка SOCKS-прокси.

Хорошая новость, но мой msmmtp стар, в нём такой поддержки нет. Нового msmtp, наверно, не будет ещё очень долго.^**

> Раньше SSH-клиент был суидным, а для таких программ динамические библиотеки не подгружаются в целях безопасности.

ОК, теперь некоторые странные замечания в мануале стали более понятными.

^* Вписывать свой резолвер через конфиг proxychains не получится, поэтому придётся для каждого создавать свою копию системного файла в /usr — иначе резволверы для Tor'ов, работающих через разные порты, будут делаться через один порт, а это дополнительная корреляция.
^** В jessie версии софта замораживаются? Если да, то они же потом войдут в будущий стабильный релиз, а обновление софта будет только в ещё более новом jessie/stable.

—	*Гость* (12/02/2015 21:19) <#>

>> Перевёл mcabber и ssh с proxychains и privoxy на torsocks, полёт нормальный.

> В man torsocks хотя поддержка DNS и заявлена, в секции BUG сказано, что она не работает — видимо, всё дело в этом.

В ssh ещё ладно (я вписал IP-адреса вместо DNS-имён), но в mcabber написано именно DNS-имя для jabber-сервера, и это работает. Т.е. torsocks в каких-то случаях DNS-резолвинг всё-таки делает.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.

Ваша оценка документа [показать результаты]