Торификация mutt
Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.
комментариев: 9796 документов: 488 редакций: 5664
Может удалённо почтовый сервер поставить? На том же серваке, где крутится 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], [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, кажется, тоже не учитывают порт. :(
Проще наверное создать локальный 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
Не так долго пользовался fetchmail, поэтому не эксперт в нём, возможно что-то упустил.
компиляция ./congifure; make; make install занимает пару минут. Зависимости отсутствуют, за исключением стандартного libc.
В теме про gmail приводился список бесплатных сервисов, ориентированных на приватность и лояльных к тору. Возможно, не так активно пользуюсь электонной почтой, но с блокировками доступа через Tor пока не сталкивался.
Интересный метод, не подумал бы о таком, спасибо.
Наверно. :)
Это мне нравится. А у кого-нибудь из аналогов msmtp есть такой же pinning?
Номера портов, на которых слушает POP3-сервер, определяет сервер. Как они могут зависеть от типа POP3-клиента?
Из популярных почтовиков:
Номера портов нужно менять после копирования настроек из msmtprc в mpoprc.
msmtp-таки тоже поддерживает pinning, значит?
Перевёл mcabber и ssh с proxychains и privoxy на torsocks, полёт нормальный. Спасибо ещё раз за совет.
msmtp не тестировал, но с fetchmail (хотел его тоже перевести) не взлетело. Открываю SOCKS-порт через ssh -D, натравливаю на него fetchmail. Если это делать через torsocks, то он пишет:
Наверно, это не имеет смысла: use_from — это же только простановка email-адреса отправителя(?).
Сделал:
Не ясно, зачем включать опцию hidden_host, которая судя по описанию не влияет на Message-ID.
Лучшее значение hostname для Message-ID это адрес SMTP-сервера, как наиболее распространённое поведение. В идеале msmtp должен автоматически модифицировать этот заголовок, используя значение host из msmtprc. Возможно имеет смысл обратиться по этому поводу к разработчику в рассылке, там сейчас наблюдается движение в сторону поддержки Тора. В последние версии msmtp и mpop включена поддержка SOCKS-прокси.
Раньше SSH-клиент был суидным, а для таких программ динамические библиотеки не подгружаются в целях безопасности.
А как 4-я версия делает DNS-резолвинг? В третьей адрес 4.2.2.2 вбит гвоздями. Те, кому не нравится, должны редактировать.* По уму резволвинг должен делаться на стороне 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-резолвинг всё-таки делает.