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

Комментарии

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

Т.е. конкретно в случае прозрачной торификации от добавления ещё и разруливания трафика по разным системным пользователям Tor мало бы что потерял.

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

При разделении по портам нескольких точек отказа не возникает.

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

Tor мог бы делать их разными по умолчанию, если трафик идёт от разных системных юзеров

Уже упоминал в этой теме, что для torsocks это так. Достаточно определить опции server_port и default_pass в глобальном конфигурационном файле, тогда для разделения цепочек можно обойтить без файлов для каждого пользователя (/home/wget/.torsocks.conf и т.д.). Можно ли полагаться на это в будущих версиях – не знаю, но как дополниительная подстраховка сойдёт.

Трояны укажут переменной свой конфиг для proxychains/torsocks, где не будет никакой авторизации. Так два разных юзера пойдут по одним цепочкам. В случае разруливания файерволлом эта дырка закрывается, а в вашем нет.

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

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

Это делает не Tor, а torsocks если в его настройках указана версия SOCKS 5 и дефолтный пароль. Тогда он видимо подставляет при аутентификации на Tor имя или идентификатор системного пользователя в случае когда он не указан опцией или переменной окружения. В proxychains такой особенности не наблюдается.

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

> Можно указать в настройках пользователя и iptables не тот порт, тогда для разных пользователей будет одна цепочка. Но в целом да, вероятность выйти в сеть с неправильными настройками меньше.

Да, мне нужно будет ошибиться в двух местах сразу: как в конфигах целевого пользователя, так и в конфиге для iptables. Если ошибка будет только в одном месте, программы просто не соединятся с сетью. Более того, пока я настраивал разруливание трафика и его фильтрацию, неоднократно отлавливал разные баги в конфигурации именно этим методом: вдруг не работало что-то, что должно было работать.

> Уже упоминал в этой теме, что для torsocks это так. Достаточно определить опции server_port и default_pass в глобальном конфигурационном файле

Не понимаю, что мешает трояну создать свой файл torsocks.conf, а потом выполнить команду

$ TORSOCKS_CONF_FILE=/path/to/torsocks.conf torsocks СтучимДомойНаFBIVerizon

В конфиге можно указать другого подставного юзера или не указывать вообще никакого. Так один системный юзер может залезть в цепочки другого системного.

> Лучше указывать только путь к конфигурационному файлу, права на чтение которого имеет только правильный пользователь.

В моём примере всё так и есть. Под двумя разными системными юзерами работают трояны. Они согласованно через TORSOCKS_CONF_FILE выставляют себе одинаковые конфиги torsocks.conf и начинают работать через одинаковые цепочки.

—	*Гость* (16/02/2015 16:58) <#>

Под двумя разными системными юзерами работают трояны. Они согласованно через TORSOCKS_CONF_FILE выставляют себе одинаковые конфиги torsocks.conf и начинают работать через одинаковые цепочки.

Такое возможно, т.к. Tor не проверяет имя и пароль. При нормальной username-аутентификации подобная возможность была бы исключена. Эту проблему можно решить добавлением между приложениями и Тором SOCKS-сервера со стандартной аутентификацией, но такое решение вряд ли подходит для всех, несмотря более высокую защиту и возможность подробной статистики (по пользователям, портам, IP-адресам, объёму трафика).

Если ваши трояны могут выполнять произвольные команды в системе (как torsocks/proxychains), значит они могут посылать на заданный внешний адрес идентификационные данные системы, например вывод dmesg. Это более сильная и вероятная атака, чем смешение трафика пользователей в одной цепочке, и ваш разброс по портам от неё не защитит. Так что вопрос целесообразности усложнения от разброса пользователей по SOCKS-портам остаётся.

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

> Такое возможно, т.к. Tor не проверяет имя и пароль.

Внеся дополнительные опции в torrc его разве нельзя научить проверять имя/пароль?

> Эту проблему можно решить добавлением между приложениями и Тором SOCKS-сервера со стандартной аутентификацией, но такое решение вряд ли подходит для всех

Верно. По-хорошему, можно хоть своё DPI замутить (не вы ли его предлагали?), но есть решение для бедных: разнести по разным портам и ловить статистику на них, iptables-save -c её показывает. Наверняка есть ещё более удобные инструменты. Лично мне нравится pftop, наверняка для iptables есть подобный инструмент. В некотором смысле tor-arm, правда, даёт это и даже больше из коробки. Там, наверно, тоже как раз удобно смотреть в зависимости не от авторизации, а от номера SocksPort'а (unknown бы точнее сказал).

> Это более сильная и вероятная атака, чем смешение трафика пользователей в одной цепочке, и ваш разброс по портам от неё не защитит.

Совершенно верно, но никто и не говорил, что это единственная контрмера. Дальше будет паравиртуализация с целой деревней домов. Впереди нас ждёт много увлекательных открытий и срачей на pgpru на тему Xen и ему нужных приблуд. Strong anonymity — наше всё. Лично я голосую за беспомпромиссную безопасность.

# xl list
Name                  ID   Mem VCPUs      State   Time(s)
Domain-0               0  XXXX     Y     r-----  XXXXXX.X

Это не фотошоп. :-) Тут вопрос разноса будет, возможно, решаться из коробки без разброса по портам и авторизации, потому что разные гостевые ОС будут сидеть на разных IP, а Tor трафик с разных IP автоматически раскидывает по разным цепочкам. Для простоты мониторинга, впрочем, я всё равно разнёс бы разные гостевые ОС по разным портам.

—	*Гость* (16/02/2015 18:33) <#>

Внеся дополнительные опции в torrc его разве нельзя научить проверять имя/пароль?

Если найдёте в мане эти дополнительные опции, сообщите. Пока видел только аутентификацию для контрольного порта, а также для HTTP и SOCKS-проксей между клиентом а входной нодой.

Дальше будет паравиртуализация с целой деревней домов

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

В системе может быть с десяток заторенных приложений, если для каждого свою виртуалку создавать, то никаких ресурсов не хватит. Вы ради каждой консольной утилиты типа wget, msmtp, fetchmail, gpg и т.д. собираетесь это делать? Понимаю, когда сложное и критичное приложение, как веб-браузер, запускают в виртуалке, но для консольных утилит проще chroot организовать, идентификация системы при этом тоже сильно затрудняется.

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

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

Виртуалки создаются не на приложения, а не «профиль» (на юзера). Дальше этот юзер может запускать сам, что захочет.

> Понимаю, когда сложное и критичное приложение, как веб-браузер, запускают в виртуалке

Конечно, в первую очередь, для него.

> Вы ради каждой консольной утилиты типа wget, msmtp, fetchmail, gpg и т.д. собираетесь это делать?

Нет. Допустим, есть профиль «работа с почтой». Его можно запустить в отдельной гостевой ОС и дать возможность выполнять оттуда всё, что захочется (получение почты, отправка; при желании и надобности — другие консольные утилиты). Важно, что информация будет только почтовая, поэтому при компрометации ничего более, чем БД почты, утечь не может.

> но для консольных утилит проще chroot организовать

Использование чрута для безопасности/анонимности — распространённое заблуждение. Даже LXC заблуждение:

Стоит отметить, что проблема анонимности за счёт профилирования железа при этом не решается.

А SELinux'а для анонимности нет (скрытие информации о железе), поэтому остаются только (настоящие) виртуалки.

Мне кажется, вы не понимаете, о чём идёт речь. Тут нет никаких «из-под одного юзера через sudo/su/gksu выполняем что-то». Есть физически разные иксы, они на разных дисплеях, под разными иксами выполяняются разные задачи. Например, под одними — только работа с вебом через TorBrower (при желании можно и ситуативное консольное что-то запускать, но никакой информации к настоящим хоумам там нет). Под другим — только джабберы, почта, ssh-тунели и gpg и некоторые приложения, не требующие работы с сетью (pdf, TeX, djview). Под третьим — только мультимедиа, он вообще доступа к сети не имеет, только на lo (музыка, проигрыватели видео, gimp'ы и прочая работа с графикой). Как-то так. Но сейчас это, допустим, три разных пользователя, а могло бы быть три разных гостевых ОС в виртуалке. Деление не обязательно должно быть именно таким, это просто общий набросок идеи. Деление идёт, в первую очередь, не по программам, а по ролям доступа к информации того или иного класса.

—	unknown (16/02/2015 21:09) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Вот у меня скажем 5-8 профилей и иксы с минималистичным оконным менеджером железо потянет, но не пять или восемь виртуалок, которые на некотором старье не взлетят.
Да и обновлять все пакеты и конфиги в каждой из пяти виртуалок — то ещё развлечение. Я понимаю все преимущества виртуалок и когда-нибудь может до них дойду, но пока долго буду сидеть на компромиссе с параллельными иксами.

—	*Гость* (16/02/2015 22:09) <#>

Допустим, есть профиль «работа с почтой»

Правильней наверное создавать профили не под приложения, а под виртуальные личности. Например: пользователь госуслуг, обычный пользователь для сёрфинга, блоггер, компьютерный специалист и т.п. Если вы в одном профиле смешаете почту для разных виртуалов, это приведёт к профилированию каждого из них и подрыву анонимности тех, для кого она наиболее критична.

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

При использовании виртуальных машин разброс по портам и SOCKS-аутентификация дополняют друг друга. Для каждой вирт. машины выделяете тор-порт, а цепочки каждого приложения внутри одной машины изолируете аутентификацией. Приложения внутри одной ВМ тоже можно по портам раскидать вместо аутентификации на Tor, но особого смысла в таком усложнении уже нет – от идентификации виртуальной системы это не спасёт при компрометации её пользователей.

Разные машины, реальные или виртуальные, которые по-разному идентифицируются, наверное имеет смысл по разным Tor-портам раскидать. Но приложения внутри одной машины практичней разделить Tor-аутентификацией.

—	*Гость* (16/02/2015 22:16) <#>

разные гостевые ОС будут сидеть на разных IP, а Tor трафик с разных IP автоматически раскидывает по разным цепочкам

В таком случае ещё проще – трафик разных машин автоматически разделяется по внутренним IP-адресам, а трафик разных приложений внутри одной машины разделяется аутентификацией, и достаточно одного тор-порта. Вместо добавления новых портов для мониторинга лучше наверное arm использовать.

—	*Гость* (08/03/2015 17:53) <#>

> Правильней наверное создавать профили не под приложения, а под виртуальные личности. Например: пользователь госуслуг, обычный пользователь для сёрфинга, блоггер, компьютерный специалист и т.п. Если вы в одном профиле смешаете почту для разных виртуалов, это приведёт к профилированию каждого из них и подрыву анонимности тех, для кого она наиболее критична.

Да, это и имелось в виду, просто плохо выразился. В моём случае большинство юзеров очень специфичны, поэтому разделение по программам почти эквивалентно разделению по «виртуальным личностям», но в общем случае, это, конечно, не так.

—	pgprubot (07/06/2015 07:16, исправлен 07/06/2015 07:19) профиль/связь <#> комментариев: 511 документов: 2 редакций: 70

> env TORSOCKS_USERNAME=OX9k9QTqZ torsocks wget https://check.torproject.org -O- | grep "IP address"

Здесь есть предостережения общего характера, которые непонятны (в некоторых случаях wget может пытаться отрезолвить localhost через локальный DNS?). Ещё есть старое обсуждение в рассылке с участием Руны Сандвик, Каммерера и других лиц. Понятно, что торифицировать wget можно по-разному (через переменные среды или через LD_PROLOAD, как это делает torsocks/proxychains), и утечки DNS могут быть как зарезаны, так и нет файерволлом, в зависимости от этого будут разные выводы про «безопасность использования».

Вопрос профилирования тоже ясен, это не TBB, но всё может быть ещё хуже, если в каких-то случаях wget сообщает локальный IP-адрес машины, где он запущен. В рассылке были спекуляции на тему пассивного режима ftp, когда это якобы может происходить, но Каммерер говорит, что даже в этом случае такого не наблюдается, wget передаёт всего лишь адрес localhost'а. Впрочем, так ли это при всех типах торификаций wget (в т.ч. через torsocks) — непонятно. Может ли злонамеренный HTTP-сервер сделать редирект на ftp, принудив wget передать локальный IP-адрес хоста? Достаточно ли надёжно вариант torsocks wget от этого застрахован?

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

—	pgprubot (07/06/2015 20:16, исправлен 07/06/2015 20:17) профиль/связь <#> комментариев: 511 документов: 2 редакций: 70

> Может ли злонамеренный HTTP-сервер сделать редирект на ftp

В man wget пишут

Unless stated otherwise, it is assumed that the default behavior is the opposite of what the option accomplishes. For example, the documented existence of --follow-ftp assumes that the default is to not follow FTP links from HTML pages.

Правда, это не про редирект, но информация полезная.

—	SATtva (08/06/2015 09:55) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Проверил редирект. Увы, работает:

$ wget http://127.0.0.1:5001/test
--2015-06-08 12:54:22--  http://127.0.0.1:5001/test
Подключение к 127.0.0.1:5001... соединение установлено.
HTTP-запрос отправлен. Ожидание ответа... 302 FOUND
Адрес: ftp://foo.com [переход]
--2015-06-08 12:54:22--  ftp://foo.com/
           => «.listing»
Распознаётся foo.com (foo.com)… 23.21.179.138, 23.21.224.150
Подключение к foo.com (foo.com)|23.21.179.138|:21... ^C

—	pgprubot (09/06/2015 06:27, исправлен 09/06/2015 06:29) профиль/связь <#> комментариев: 511 документов: 2 редакций: 70

> пассивного режима ftp

Скорее, всё же активного. По умолчанию, судя по

Unless stated otherwise, it is assumed that the default behavior is the opposite of what the option accomplishes.

режим может быть только пассивным:

--no-passive-ftp

Disable the use of the passive FTP transfer mode. Passive FTP mandates that the client connect to the server to establish the data connection rather than the other way around.

If the machine is connected to the Internet directly, both passive and active FTP should work equally well. Behind most firewall and NAT configurations passive FTP has a better chance of working. However, in some rare firewall configurations, active FTP actually works when passive FTP doesn't. If you suspect this to be the case, use this option, or set "passive_ftp=off" in your init file.

> Проверил редирект. Увы, работает

Спасибо за проверку. Похоже, wget — слишком умная тулза, чтобы быть анонимной и безопасной. Умеет намного больше, чем от неё могут поначалу ожидать.

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

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