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


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



Комментарии
— unknown (10/06/2011 17:25, исправлен 10/06/2011 17:34)   

Можно практически всё под данным torifyWiki[link1] из вышеперечисленного и много чего ещё.
Тема непроработана и пользователям давались неоднократные предупреждения в рассылке по поводу того, как легко на этом всём проколоться, пока не разработано единое для всех унифицированное решение по аналогии с Torbutton (только для почты). И пока (и уже много лет и ещё будет наверное столько же) анонимность почты на отправку в стадии "Experimental". Вот из недавнего[link2].

— Гость (10/06/2011 19:40)   
unknow, я понимаю,что почтовые клиенты "срут" лишней инфой, но иногда скорость важнее, чем сокрытие клиента, а главное – это сокрытие места нахождения. (Есть случаи, когда действуешь вообще под своим реальным именем, но ненужно, чтобы всякие скоты знали, где ты физически локализуешься).
Вот по поводу этих моментов есть вопросы:
1. client time zone
2. client machine clock time
3. client machine time since last boot

TZ же можно задать UTS через переменную? По крайней мере с громоптицей это работает. А вот чем будет "срать" exim в случае отправки с mutt, не совсем ясно. Наверное, он будет свои какашки дополнять к какашкам mutt?
По поводу "mutt на своем почтовом сервере", который юзается через ssh over Tor.
Чем это решение хуже использования там же веб-морды, того же Squirell Mail? Имхо, разницы большой нет. Кроме того, что mutt по ssh over Tor будет существенно быстрее, чем веб-морда over Tor. нет?
P.S. А если при отправки с локалхоста пользователю, под которым запущен exim, сделать прозрачную торификацию, будет это работать? (При том, что этот exim занимается: а) доставкой локальной почты; б) связью с публичным почтовым сервером, для отправки почты с помощью mutt, и больше не для чего не используется).
— Гость (10/06/2011 19:41)   
Да, чуть не забыл, а что, почтовые клиенты умеют "срать" в заголовки и аптайм машины?
— Гость (10/06/2011 20:42)   
Прозрачная торификация — самое простое, чтобы не играть в опасные игры с проксями и не мучиться. Заголовки решаются железно методом испльзования специальной guest OS в виртуалке, в которой будет своё время и свой часовой пояс (наверное, так можно сделать).

Я не в курсе exim, но, насколько я знаю, mutt'у указывается дополнительные 2 команды в конфиге: для чтения почты и для отправки почты. Первое умеет fetchmail/getmail, второе — msmtp. Эти тулзы с проксями не дружат, так что можно их попытаться использовать с proxychains. Это на случай, если без прозрачной торификации.

mutt по ssh over Tor будет существенно быстрее, чем веб-морда over Tor. нет?

Нет. ssh — вообще требовательный к скорости протокол, работать с ним под Tor'ом не очень приятно, особенно, если мало опыта набора команд вслепую. Тормозить будет адски. Так что годится это только для минимальный действий типа "переслать письмо через sftp" и "отправить его мейлером с сервера", а набирать всё равно у себя на localhost'е будете.
— Гость (10/06/2011 21:05)   
если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!

Обязано.

А если при отправкие с локалхоста пользователю, под которым запущен exim, сделать прозрачную торификацию, будет это работать?

Какой-то бред. Если что-то прозрачно торифицировано, оно ушло в инет и вернуться не может, если нет реального IP. Для программ прозрачная торификация прозрачна, а потому работать должно всё, если им просто надо отсылать данные в сеть и получать их (но не быть интернет-сервером).

легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?

Читайте, есть ли там такие опции в документации.

Пара рекомендаций общего характера:
  1. Мало какие консольные тулзы и курсес-проги умеют proxy. Большая часть консольных тулзов прекрасно проксифицируются средствами proxychains. Даже если тулзы умеют прокси сами, с proxychains они часто работают стабильней. Это закрывает вопрос с торификацеий.
  2. Никогда не полагайтесь на торификацию as is. Всегда контролируйте ей файерволлом (либо прозрачную торификацию делайте, либо закрывайте весь трафик от торифицируемого юзера, идущий не по адресам localhost:9050 и localhost:8118).
  3. Используйте самые простые консольные тулзы из тех, что решают вашу задачу. Воздерживайтесь от комбайнов, особенно если тонкости работы их не знаете. Минимальные тулзы меньше срут заголовками, проще в управлении и настройке, более управляемы. Такой тул для получения почты — getmail, для её отсылки — msmtmp, для фильтрации (если хотите, конечно) — procmail. У каждой из этих тулзов простой конфиг, и при желании вообще всё, что надо, можно указать опциями командной строки.

Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.

Можно, но если сервер свой и хочется полагаться на его анонимность, то и регистрировать его надо анонимно, и оплачивать хостинг анонимно, что как бы не так просто.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?

TZ же можно задать UTS через переменную?

Даже если можно, это всё опасные игры. Соломоново решение — под такие задачи делать свою guest ОС в виртуалке.

вот чем будет "срать" exim в случае отправки с mutt, не совсем ясно

Ну, например, локлальный IP машины может (скорее, точно будет) писать.

Чем это решение хуже использования там же веб-морды, того же Squirell Mail?

Особой разницы нет, вопрос удобства. Просто гемориться с настраиванием почты через Tor стоит, имхо, только если почты очень много и работа с ней через Tor — основное занятие в Tor. Проще не заморачиваться и пользоваться веб-мордами, благо что torbutton для браузера есть, а для мейлеров — нет.

почтовые клиенты умеют "срать" в заголовки и аптайм машины?

На 100% ничего не исключено :)
Но потенциальный аптайм в самих tcp-sequences нейтрализуется за счёт Tor.
— Гость (10/06/2011 22:11)   

Рекомендую связку mutt+fdm+msmtp.fdm заменяет fetchmail+procmail,два в одном так сказать,и нативно поддерживает socks (set proxy "socks://127.0.0.1:9050" – директивой в своем конфиге).msmtp – сама простота,воистину unix-way,торифицируется через torify.Утечек не замечал,но не помешает:

Можно поспорить,хотя все относительно.С какими не заладилоь?
— Гость (10/06/2011 22:31)   
заменяет fetchmail+procmail

Если фильтрация не нужна, getmail лучше fetchmail (последний не может работать без procmail).

Можно поспорить,хотя все относительно.С какими не заладилоь?

Как заставить Tor работать через корпоративную socks-прокси? А ssh? Я имею в виду напрямую, без промежуточной http-прокси типа privoxy. mcabber тоже сокс не умеет. msmtp, как вы сами пишете, требует внешней тулзы torify. ssh при настройке для работы через http-прокси требует внешней тулзы corkscrew. Сокс вообще мало кто умеет. links тоже сокс не умел (наверное, и сейчас так же). Те тулзы, которые умеют http-прокси, не умеют https-прокси. Как заставить работать wget через socks-прокси или https-прокси? Это не в конексте Tor'а, а вообще. Понятно, что под каждую тулзу можно соорудить свой костыль из стороних методов, туннелированрия через промежуточные прокси, прозрачной проксификации и универсальных проксификаторов а-ля proxychains.

P.S.: пробелы ставьте между словами, ОК?
— Гость (11/06/2011 11:23)   

Такая возможность реализована в tor-devel:
из man-а

wget через socks старая – непостижимая история,возможность задекларировали,а как реализовать утаили :)

proxychains,privoxy,torsocks,etc – не такие уж и костыли,свои задачи они выполняют хорошо.Может быть это unixway )
— Гость (11/06/2011 11:43)   
Да, про wget и https-прокси ступил. С http-прокси сам её так юзал, через задание переменной.

proxychains,privoxy,torsocks,etc – не такие уж и костыли,свои задачи они выполняют хорошо

Не надо мешать всё в одну кучу. privoxy/tor — это прокси, proxychains — проксификатор. По факту не всё и не всегда проксифицируется. proxychains подменяет библиотечные вызовы, но прога это может и игнорировать. Особенно это начинает проявляться при запуске сложных прог типа браузеров через proxychains (хотя некоторые гуйные могут так работать). Вот, например, почему Tor не работает[link3] с proxychains, в котором сидит ssh'ный socks?
— Гость (11/06/2011 13:39)   
Возможно с proxychains погорячился ),мне не довелось его использовать,ибо под свои задачи хватало privoxy и torsocks.Поэтому ответ на вопрос:
мне не известен.Но,если еще актуально,то Tor(девелоперская его версия) может работать через "ssh'ный socks" самостоятельно(см.выше).
— Гость (11/06/2011 23:12)   
Спасибо за информацию.
— Гость (12/06/2011 13:50)   
Если фильтрация не нужна, getmail лучше fetchmail (последний не может работать без procmail).

и давно ли занемог?
— Гость (12/06/2011 14:12)   
Раньше не мог. Для складирования почты в хранилище mutt приходилось пользоваться procmail. Возможно, это было народным поверьем. Я в те времена настраивал вслепую.
— Гость (14/06/2011 07:41)   
Рекомендую связку mutt+fdm+msmtp.fdm заменяет fetchmail+procmail,два в одном так сказать,и нативно поддерживает socks (set proxy "socks://127.0.0.1:9050" – директивой в своем конфиге).msmtp – сама простота,воистину unix-way,торифицируется через torify.


Мне интересна прозрачная торификация (хотя я обычно по-возможности торифицирую и сами программы, запускаемые в режиме прозрачнойторификации, на случай если "упадут" правила iptables, а я этого не замечу, и т.п.).
Как я понимаю, сам mutt с внешней сетью не общается, поэтому от того, торифицирован ли прозрачно юзер, под которым он запускается, не зависит, уходят ли пакеты через Tor, или напрямую. Или я не прав?
fdm, как я вижу, работает через отдельного юзера. Т.е. прозрачно торифицировать надо этого юзера?
А что касается msmtp, от какого юзера она работает?
— Гость (14/06/2011 07:49)   
Или они от юзера запускаются, от которого же mutt? Что-то я не совсем пойму...
— Гость (14/06/2011 15:37)   
все будут работать от юзера запустившего их и читать настройки в конфигах находящихся в $HOME этого юзера.конфиги придется создать\отредактировать под потребности.
Если надо,то будет.
— Гость (14/06/2011 23:34)   
я обычно по-возможности торифицирую и сами программы, запускаемые в режиме прозрачнойторификации, на случай если "упадут" правила iptables
Упадут правила iptables? Это как? Само ядро ОС упадёт что ли? С виндой не путаете?
— Гость (08/07/2011 07:23)   
Упадут правила iptables? Это как? Само ядро ОС упадёт что ли? С виндой не путаете?


Руками уроню,например. Перепишу правила, обнулю существующие, а в период до загрузки новых – отвлекусь, и пойду куда-нибудь, забыв, и пропалюсь.
Как сказал герой одного знаменитого кинофильма, "Никому нельзя доверять, даже себе".
— Гость (24/07/2011 21:03)   
Руками уроню,например. Перепишу правила, обнулю существующие
Речь шла о защите от программных ошибок, а не о раздолбайстве. Консоль рута — это вещь, которую на критических работающих системах трогают только при большой надобности, очень внимательно и на трезвую голову.
— Гость (10/08/2011 16:37)   
Гость (10/06/2011 22:11)

Замечательно настроил отправку почты через mutt + msmtp, а вот с конфигурированием fdm затруднился.
В дистре есть несколько примеров конфигов, и все они какие-то очень сложные.
Не могли бы Вы поделиться своим конфигом? (Ессно, без конфиденциальных данных)
— Гость (10/08/2011 20:57)   

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.
— Гость (11/08/2011 20:54)   
Гость (10/08/2011 20:57)

Премного благодарен.
А можно ли заставить msmtp работать через soks-прокси? Скажем, заюзать proxychains или tsocks?
— Гость (11/08/2011 22:46)   
proxychains – не юзал, не знаю.
tsocks – да .
torsocks[link4] is new generation of tsocks – рекомендую.
— Гость (11/08/2011 23:58)   
А если я хочу юзать проксю после Tor ?
Я вот попробовал заюзать proxychains, указав в ней socks4 и socks5 прокси (много), но почему то соединение по 25 порту отвергается.
Видимо, операторы прокси зафаерволили этот порт, негодяи
— Гость (12/08/2011 19:59)   
Кстати, в результате тестинга mutt выявилось, что он срет в заголовках:
а) Своим названием и версией, как и все почтовые клиенты;
б) Он способен срать именем и доменом хоста. Типа vasya@pupkin.
Но почему-то этот "сер" в заголовках не всех входящих писем – когда я отправляю с одного email-провайдера этот сер есть, когда с другого – нет.
Но, по-видимому, это зависит от почтового сервера провайдера – что он в итоге вставляет в заголовки, что нет. Поэтому, не исключено, что есть еще какой-то сер, который может видеть почтовый сервер, который обычно (даже если он на твоем дедике) контролируется враждебной стороной.
Кстати сказать, данный сер лечиться просто – запуском mutt с предварительной инициализацией фейковых переменных $HOSTNAME и $DNSDOMAIN.
Но вот как выявить возможный иной сер?! Чем он еще может серить?!
— Гость (12/08/2011 22:34)   
это зависит от почтового сервера провайдера – что он в итоге вставляет в заголовки, что нет
Да. Например, gmail не проставляет originating IP (ваш) при отправке писем, а mail.ru — проставляет.
есть еще какой-то сер, который может видеть почтовый сервер
Ничего более, чем то, что расскажет мейлер + IP адрес ваш. Как сайдэффект протокола ещё может засветиться точное время на машине и ещё какие-нибудь параметры TCP, тот же TTL... (последние два — если не через Tor).
если я хочу юзать проксю после Tor
Как ещё одна возможность — сделать прозрачную торификацию, после чего штатно указать сокс-сервер в настройках мейлера или какого-нибудь проксификатора (уже не обязательно такого, который умеет работать с цепочками прокси).
— Гость (12/08/2011 22:49)   

Это нормально для настроек по умолчанию. Предпочтения и пожелания сами что ли в конфиг материализуются? Читайте доки и маны, настраивайте как считаете нужным .

отправить мэйл самому себе, открыть его в mutt и нажать h

хотя б встроенную в mutt справку посмотрите )
hint : ?
— Гость (14/08/2011 09:25)   
— Гость (12/08/2011 22:49), спс большое, я сдуру только man смотрел и образец конфига, первый очень лапидарен, во втором не все сразу понятно, да и многих опциев нету :)

— Гость (12/08/2011 22:34)
Как ещё одна возможность — сделать прозрачную торификацию, после чего штатно указать сокс-сервер в настройках мейлера или какого-нибудь проксификатора (уже не обязательно такого, который умеет работать с цепочками прокси)

Ну вот я так и пытаюсь решать, а что касается проксификатора – что-то сразу на ум пришел proxychains, и я стал пытаться заюзать его.
Но не знаю, правильно получается или нет.
Создал такой пользовательский конфиг:


Указал лист из множества прокси, пробовал random_chain – не отправляется (с единственным звеном), пробывал динамичную – не отправляется.
Правильно ли я задал этот конфиг?
Mutt выводит такой лай:

Ну или на 25 порт лается.
Как понять, правильно ли у меня сконфигурирован .proxychains, отвергает ли прокси исходящие соединения по данному порту или же это соединение отвергает почтовый сервер?
Да, и правильно ли я задал команду в конфиге Mutt?
— Гость (14/08/2011 10:27)   
Сейчас пробую tsocks вместо proxychains, нашел неск. рабочих внешних socks-4 проки.
В man tsocks и man tsocks.conf не указано, как должен быть сохранен конфиг tsocks (равно как не указано опции tsocks для юзанья альтернативного конфига).
Правильно ли я делаю, сохраняя его как $HOME/.tsocks, по аналогии с другими конфигами? Или он должен быть $HOME/tsocks?
Конфиг записал таким образом:

Чекаю его, получаю такое:


Ч.я.н.т.д?
— Гость (14/08/2011 11:38)   
Странное дело, у проксика порты 25 и 587 открыты, nmap кажет, траю :

tcpdump -n host ip_addr_of_proxy_server не показывает ни исходящих соединений с ним, ни входящих от него.
Юзается указанный конфиг proxychains (с указанием единственного сервера), запускаюсь под прозрачно заторенным юзером.
Что за беда такая?!
— Гость (14/08/2011 14:37)   

в отличие от muttrc(5)
Конфиг записал таким образом:

$ cat .tsocks.conf
server = 212.11.28.25
port = 1080

port 1080 у 212.11.28.25 открыт ?
можно попробовать через Tor :
Правильно ли я делаю, сохраняя его как $HOME/.tsocks, по аналогии с другими конфигами? Или он должен быть $HOME/tsocks?

это может зависеть от системы/дистрибутива. Хозяину видней где что располагается в его_OS. У кого-то конфиг может быть, например, в /etc
— Гость (14/08/2011 14:46)   
P.S
Invalid pair type (port) specified on line 2 in configuration file, "port = 1080"

server_port = 1080
— Гость (14/08/2011 16:10)   
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 – вышеописанная беда.
— Гость (14/08/2011 17:16)   

это конечно не порок, но, вы пишите IP, а используете hostname, вот так запутывать не надо. Пробуйте :
Последнее китайское предупреждение – курите man'ы )
— Гость (14/08/2011 18:47)   
I keep getting an error like "SOCKS server is not on a local subnet!", what's going on?[link5]
— Гость (14/08/2011 20:25)   
— Гость (14/08/2011 17:16)

Насчет dns, так я запускаю tsocks под прозрачно торифицированным юзером, там dns заворачивается в tcp и резолвится через tor. Как я понимаю, на выходе из tor он остается tcp? (dns ведь умеет и tcp). Тогда не должно быть проблем с резолвингом dns через socks-проксю после tor'а. Или exit-нода tor'а резолвит dns через udp запросы, хотя и получает их в виде tcp? Что-то я не совсем тогда понимаю как и зачем.

— Гость (14/08/2011 18:47) <#>
wwwI keep getting an error like "SOCKS server is not on a local subnet!", what's going on?


Спс, но ничерта не понимаю, как это сделать.
Согласно man tsocks.conf, как я понял, есть две интересные директивы:

Если я прописываю что-то типа local = 212.11.28.00/24, выходит такой лай об ошибках:

Если что-то типа reaches = 212.11.0.0/16:80 – 1080:212.12.0.0./16, то такой:
— Гость (14/08/2011 22:59)   
так я запускаю tsocks под прозрачно торифицированным юзером

Э...,тогда все зря. Что может tsocks? перехватить запрос от msmtp и отправить его socks-proxy, которым может быть в частности и Tor тоже. под прозрачно торифицированным юзером все исходящие в обход Tor блокируются файрволом, поэтому
1) Через Tor – работает.

а через 212.11.28.25 и др. нет.
— Гость (15/08/2011 01:32)   
— Гость (14/08/2011 22:59) <#>

Я почему-то думал,что tsocks пошлет пакеты через Tor (куда его завернет фаервол) на прокси-сервер, а тот уже – вовне.
Так как, например, если в браузере, запускаемом под прозрачно торифицированным юзером, указать настройки прокси, то прозрачная торификация заворачивает все в тор, из экзита оно идет на прокси, а уже из прокси – по назначению.
С tsocks так не работает?
— Гость (15/08/2011 09:52)   
Кстати, из-под незаторенного юзера проблема сохраняется. Так что, имхо, дело не в tor, а в неправильной конфигурации tsocks.
Может быть, кто-нибудь бы выложил образец своего работающего конфига?! Ессно, без чувствительных данных.
— Гость (15/08/2011 14:52)   
если в браузере, запускаемом под прозрачно торифицированным юзером, указать настройки прокси, то прозрачная торификация заворачивает все в тор
Я сомневаюсь, что вы понимаете, что такое прозрачная торификация и как она работает. Но, допустим, всё именно так как вы говорите и это работает. Тогда это означает, что трафик дважды идёт через Tor, т.е. цепочки длиной 6, а не 3.
— Гость (15/08/2011 19:25)   
Я сомневаюсь, что вы понимаете, что такое прозрачная торификация и как она работает. Но, допустим, всё именно так как вы говорите и это работает. Тогда это означает, что трафик дважды идёт через Tor, т.е. цепочки длиной 6, а не 3.

Имеется ввиду внешний прокси, не Tor. Если tcpdump'ить, все идет через Tor, если смотреть ip на выходе (на тех же tor-детекторах или всяких чекалках ip) – ip внешнего проксика (я как то так делал, чтобы tor-ноды не абузить, их и так мало).
Что же касается указания в браузере под прозрачно торифицированным юзером, думаю, здесь Вы не правы – те же три цепочки, просто уходит на привокси или на полипу и идет обычным порядком, я тестил.
iptables -L -v -t nat не показывает, что пакеты заворачиваются в Tor фаерволом, если нет утечки, конечно. (Например, FF с торбаттоном утечки не давал, а джаббер-клиенты зачастую пытаются выпустить пакеты напрямую, тогда они режутся).
Но это оффтоп, а вот пример рабочего конфига tsocks или proxychains никто не привел, и не гуглится ни фига.
Кстати, а ssmtp умеет прокси без всяких tsocks, сам по себе?
— Гость (17/08/2011 00:01)   
думаю, здесь Вы не правы – те же три цепочки, просто уходит на привокси или на полипу и идет обычным порядком, я тестил.
Да, ошибся. Почему-то подумалось о случае Tor-рутера, т.е. когда первый Tor-клиент находится на другой машине вообще, и там это было бы так (если Tor-рутер + свой Tor-клиент на машине за Tor-рутером).

пример рабочего конфига tsocks или proxychains никто не привел, и не гуглится ни фига
Гуглите как proxychains site:pgpru.com в гугле. Уже задолбался его конфиг сюда писать. Всё работает. Что не работает — тоже освещалось в топиках. Грубо говоря, не все прокси-серверы имплеменчены одинаковы, не все прокси-клиенты имплеменчены одинаково, так что сыпать все шишки на proxychains — нехорошо. Он проксифицирует как умеет. С цепочками прокси я его не использовал, но в качестве проксификатора через одну socks- или http-прокси — многократно. С tsocks не работал, потому ничего не подскажу.

Кстати, а ssmtp умеет прокси без всяких tsocks, сам по себе?
Ну что Вы как маленький, право дело! Откройте man, посмотрите поиск по слову proxy (после открытия man введите: -i/proxynnnnnn) — если ничего не найдено, то значит нет.
— Гость (06/01/2015 13:59)   

В тему сабжа:

Схема «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 (смотрим в сорс) если имя хоста не соответствует паттерну (тут не важно, с отрицанием или без), то данный элемент списка паттернов игнорируется.
Предположим, что в секции Host конфига ~/.ssh/config задан только один паттерн, тогда:

  1. ssh 99.1.2.3, Host 99.*.*.* ⇒ секция в конфиге применяется, пишется дебаг-сообщение Applying...
  2. ssh 99.1.2.3, Host !99.*.*.* ⇒ секция не применяется, пишется дебаг-сообщение Skipping ...
  3. ssh 88.1.2.3, Host 99.*.*.* ⇒ секция игнорируется, сообщения нет.
  4. ssh 88.1.2.3, Host !99.*.*.* ⇒ паттерн игнорируется, секция игнорируется, сообщений нет.

Вариант 4 — это явная болезнь логики. Что курили (имели в виду) авторы? Если в строке Host указывать один отрицательный паттерн, из вышеизложенного следует, что эта секция не выполняется никогда. Вот что пишут на этот счёт в мане:

If a negated entry is matched, then the Host entry is ignored, regardless of whether any other patterns on the line match.

Т.е., надо писать «Host !127.0.0.1 *», тогда в случае типа 4 будет вот что:
  • ssh 99.1.2.3 ⇒ первый паттерн (отрицание) не срабатывает, и секция матчится по второму элементу в списке — *.
  • ssh 127.0.0.1 ⇒ первый паттерн (отрицание) срабатывает, и секция игнорируется.

Есть и другой вариант, как в Tails:
Host 127.0.0.1
ProxyCommand none
 
Host *
ProxyCommand ....
Срабатывает это потому, что OpenSSH использует только первую по ходу конфига активную секцию Host, т.е. удовлетворяющую паттернам (берёт её значение для ProxyCommand, а упоминание ProxyCommand в последующих секциях игнорирует). Т.е., секция «Host *» должна идти в конце. В общем, имеем очередной пример торжества программистской нечеловеческой логики и «Worse Is Better» подхода.

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

  • Первый:
    Host X.X.X.X
    IdentityFile ~/.ssh/X.X.X.X-keyfile.ssh
 
Host 127.0.0.1
    IdentityFile ~/.ssh/127.0.0.1-keyfile.ssh
 
Host !127.0.0.1 *
    ProxyCommand corkscrew 127.0.0.1 8118 %h %p
 
Host *
    Compression yes
    CompressionLevel 9
  • Второй:
    Host 127.0.0.1
    IdentityFile ~/.ssh/127.0.0.1-keyfile.ssh
    ProxyCommand none
 
Host X.X.X.X
    IdentityFile ~/.ssh/X.X.X.X-keyfile.ssh
 
Host *
    Compression yes
    CompressionLevel 9
    ProxyCommand corkscrew 127.0.0.1 8118 %h %p
*Работает как связка msmtp+fetchmail+procmail.
— Гость (07/01/2015 20:05)   
Вместо 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.
— Гость (07/01/2015 23:02)   

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].
— unknown (07/01/2015 23:27, исправлен 07/01/2015 23:29)   

Может удалённо почтовый сервер поставить? На том же серваке, где крутится 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)   

Всё это можно, но гемор. Я вообще не люблю почтовый протокол, так уж сложилось. Так не хочется с этим всем глубоко разбираться... хотя можно было бы много чего сделать. Например, я без понятия, откуда 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. К счастью, с течением времени таких ресурсов становится всё больше.
— Гость (08/01/2015 13:43)   

Тут логика, видимо, была такой: сначала парсятся юзерские конфиги, а потом системные, поэтому, чтобы первые имели приоритет перед вторыми, срабатывает именно первое упоминание 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, кажется, тоже не учитывают порт. :(
— Гость (08/01/2015 14:29)   
SSH-сервер крутится в организации, к которой я имею вполне конкретное отношение

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



Потом ходить через него почтовыми клиентами, тоже с 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[link12]

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

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

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

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

В теме про gmail приводился список бесплатных сервисов, ориентированных на приватность и лояльных к тору. Возможно, не так активно пользуюсь электонной почтой, но с блокировками доступа через Tor пока не сталкивался.
— Гость (09/01/2015 01:50)   

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


Наверно. :)

#[link13] 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?


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


Из популярных почтовиков:
  1. Гмыло не дружит (вроде был какой-то трюк зарегаться и залогиниться без Tor, потом не тереть куки и дальше можно продолжать использовать ящик через Tor; позже, кажется, было разъяснение от гугла, что они целево блочат Tor — ссылки на оба факта тут на форуме приводились).
  2. mail.ru вроде дружит, но не хочется хранить всю инфу на серверах ФСБ.
  3. ukr.net позволяет регистрироваться только с украинских IP.
— Гость (09/01/2015 06:57)   
Опция tls-fingerprint удобна когда сертификат сервера подписан УЦ, которого нет в стандартного связке или сама связка по какой-то причине отсутствует. Можно опцию всегда использовать, так даже безопасней, т.к. указывается хеш сертификата напрямую, а не полагается на доверие к УЦ. Но в таком случае нужно периодически менять хеш вручную в mpoprc/msmtprc при смене сертификата. Насчёт аналогичных опций в других клиентах не знаю.

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

Номера портов нужно менять после копирования настроек из msmtprc в mpoprc.
— Гость (09/01/2015 11:46)   

msmtp-таки тоже поддерживает pinning, значит?
— Гость (10/01/2015 06:13)   
Да, поддерживает. Как уже писал, опции msmtp и mpop идентичны и отличаются только по части протоколов (SMTP и POP3).
— Гость (11/02/2015 17:42)   

Перевёл 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-адрес. Тут[link15] упоминали, что msmtp надо напрямую кормить IP-адресом. Здесь, видимо, та же проблема. А с proxychains всё работает и по DNS-именам.


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


Сделал:
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?[link17] Неясно, о чём это.
— Гость (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)   

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


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


ОК, убрал опции
set hostname=""
set hidden_host=yes
из конфига. В msmtprc, конечно, host прописан. Главное — чтоб локальный hostname не утекал.


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


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

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

В ssh ещё ладно (я вписал IP-адреса вместо DNS-имён), но в mcabber написано именно DNS-имя для jabber-сервера, и это работает. Т.е. torsocks в каких-то случаях DNS-резолвинг всё-таки делает.
— Гость (12/02/2015 23:13)   
В proxychains4 с разрешением имён проблем нет, по умолчанию включена опция proxy_dns (она вроде и в версии 3.1 была). В torsocks аналогичная опция tordns_enable, по умолчанию тоже включена. С ними никаких DNS-утечек быть не должно.

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

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


Да, но дело не в DNS-утечках, а в том, через что[link21] они резволят и как.
$ 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 по-прежнему[link18] зашито статикой. ☹ В четвёртой также? В отличие от 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 address ‘zqktlwi4fecvo6ri.onion’
Всё так.


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


Я для себя решил авторизацией не заморачиваться, а вместо этого всё разрулить по разным 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-туннели при запуске через костыль corkscrew → privoxy → tor сдыхают крайне быстро. Возможно, дело в каких-то таймаутах privoxy. А при торификации через torsocks туннели живут долго.
— Гость (13/02/2015 08:54)   

В стандартном pkgsrc его нет, но он есть[link23] в wip'е. В принципе, можно рискнуть поставить[link24]...
— Гость (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.
— koshkin (13/02/2015 14:40)   
сорри, не отвечайте здесь. Создал новую тему[link25].
— Гость (13/02/2015 14:46)   
Если это часть заголовков почты, то просмотром заголовков прочитать можно. Большинство web-интерфейсов имеют эту опцию (show original).
— Гость (14/02/2015 00:09)   
Если юзер один, а пароли разные, этого тоже будет достаточно для разделения?

Достаточно, это несложно проверить. Авторизация в Tor отличается от стандартной username, и у меня информация только из экспериментов. Не уверен, что все детали где-то описаны, кроме программного кода. Многие вещи проще самому проверить, чем искать в документации.
— Гость (15/02/2015 10:07)   

А как проверяли? Читали код? Или анализировали строящиеся цепочки на низком уровне через какой-нибудь tor-arm?


Конкретно эта фича вроде как заявлена, так что должно работать, но трудность её верифицируемости (как и многих других фич) меня смущает. Трудно жить, когда ни к чему нет стопроцентного доверия. В документации они могут написать одно, а на деле будет происходить другое; они могут знать об этом, но ничего не делать.

Заявлено, что TBB ничего не пишет вне своей директории, а это не так[link26]. Разработчики об этом знают, но не исправляют. Уже три года как не исправляют. Ими признанный всесторонний анализ утечек[link27] ещё более удручающ, но они не чешутся. А на бумаге и в документации всё гладко, да. Исправили ли они утечку[link28] версии ОС (и ещё много чего) при включённом JS? Непонятно. Также непонятна ситуация с вытягиванием списка шрифтов[link29] из системы (даже без JS). Внимательно следящие за багтрекером наверняка скажут, что в любой момент времени известны десятки критических уязвимостей, которые могут не исправляться годами. Судя по всему, к разработке самого Tor'а они примерно так же[link30] относятся.* Это всё снова возвращает к тому же вопросу: во что мы верим и чему доверяем.


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

Разделение по портам для изоляции цепочек явно оговорено в документации и имеет то преимущество, что можно разнести юзеров файерволлом. Когда нужно железно исключить вмешательство одних программ (из-под одного юзера) в работу других (из-под другого юзера), изоляция по портам — самое то. В этом случае зловред при всём желании не сможет залезть в чужую цепочку (если только в самом Tor'е на эту тему баги не будет).

* У unknown'а был комментарий (всё перерыл, не могу найти) на тему того, что какую-то редкую опцию в Tor-клиенте (то ли поддержка приватных скрытых сервисов, то ли ещё что) они несколько раз ломали, из-за чего чуть ли ни месяцами все такие сервисы были де факто нерабочими. При всём этом в рассылке и багтрекере никто не пожаловался ни разу.
— unknown (15/02/2015 17:03)   

А я в том коментарии хотел найти то ли соответствующий комент в рассылке, то ли в торблоге, то ли в тикетах, всё перерыл, так и не нашёл. Но проблема такая точно есть.
— Гость (15/02/2015 18:15)   
Для проверки можно просто запрашивать страницу, меняя имя пользователя



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

В документации они могут написать одно, а на деле будет происходить другое

То же можно сказать про всё остальное, в том числе разделение цепочек по портам.

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

Разделение по портам для изоляции цепочек явно оговорено в документации и имеет то преимущество, что можно разнести юзеров файерволлом.

Разделение по пользователям тоже явно оговорено, разнести их ещё легче – запускать программы с правами разных системных пользователей (что само по себе повышает безопасность), у которых конфигурационные файлы, содержащие user/pass, недоступны для чтения всем. Например, файлы /.torsocks.conf или /.proxychains/proxychains.conf будут одинаковы для всех пользователей, отличаясь только двумя строками – для user и password. Разные системные пользователи не будут знать эти данные друг у друга. Если один из них скопрометирован, он не сможет получить доступ к цепочках других пользователей, т.к. не знает их имён и паролей на Tor. В итоге получается проще – не нужно создавать для каждого пользователя SOCKS-порт, защищать его файрволом и помнить соответствие между именем пользователя и номером порта.

Если не используется прозрачная торификация, то проксифицировать программы в любом случае нужно, независимо от того, разделяются ли цепочки по портам или именам пользователей. Но в первом случае необходимо ещё править torrc и правила iptables, а во-втором достаточно лишь добавить строку в torsocks.conf или proxychains.conf. Т.е. в первом случае нужно править три файла и помнить связи между ними, а во втором только один файл и помнить ничего не нужно, т.к. SOCKS-порт один на всех.
— Гость (16/02/2015 07:48)   

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

Потом есть впрос диагностики. Я иногда смотрю на монитор типа netstat, там есть статистика. Есть статистика пакетов и в правилах iptables-save -c. Она показывает, через какой порт сколько пакетов прошло, кто через какой порт работает и т.д. Это даёт дополнительную степень свободы для контроля.

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


Unknown, перестаньте издеваться, дайте ссылку на тот свой комментарий! ☺ Или вы его теперь тоже не можете найти? На форуме под 100k комментариев, и хотя память у меня не совсем дырявая, я уже приближаюсь к своему квантовому физическому пределу на то, чтобы помнить всё, где, что и по какому случаю было сказано. Сейчас за несколько месяцев здесь появляется больше новых и содержательных комментариев, чем раньше появлялось за несколько лет, тема ИБ разрастается и в ширь и в глубь...
— unknown (16/02/2015 09:40, исправлен 16/02/2015 09:40)   

Нашёл не свой[link31]:


Yes, HS authoritzation is rare. It's rare enough that it was broken for a whole series of releases and no one noticed or complained. That sucks and it should be used more because it probably does help resist attacks for a large category of use cases.

И это ноябрь 2014 года, а оно всё ещё не работает гарантированно.

— Гость (16/02/2015 10:00)   
Спасибо! Буду ссылаться теперь на вас при надобности.
— Гость (16/02/2015 10:42)   
появляется единая точка отказа: если где-то по ошибке забыли поставить уникальный пароль (при копировании конфигов между пользователями) или вообще забыли указать какой-либо пароль

Одну точку отказа легче контролировать, чем несколько. Всё зависит от того, как организовать. Можно например держать где-нибудь (/somedir) конфигурационные файлы, на которые при очередной установке делается символическая ссылка из нужного места



Или создать скрипт для запуска torsocks/proxychains, который берёт имя пользователя из /dev/urandom. Тогда даже приложения с одинаковыми системными правами не будут знать друг у друга аутентификационные данные на Tor.

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

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

Мне так не кажется, порт это лишь способ передачи данных между процессами, а построение цепочек определяется ядром Tor-клиента. Ему без разницы, как получены данные – через один порт или несколько, номер порта это просто различитель, помечающий разные приложения, также как имя/пароль.
— Гость (16/02/2015 10:42)   
Ещё из старых обсуждений:

И[link32] с тех пор, как в торкнопке глючила настройка разных торбраузеров на разные торпорты (выставляете один порт, а работает через другой), то на это выработалась стойкая аллергия. Представьте, что вы выставляете разные порты внутри программ (главное самому ещё при этом не ошибиться), а они слетают в дефолтное состояние и разные программы начинают работать на одном порту. Проще завести кучу пользователей и твёрдо их снаружи разруливать файрволлом. Так надёжнее, логичнее и нагляднее — все настройки в одном месте, доступном только руту.

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

И[link33]ногда tor глючит, из-за чего в статистике может появиться что-то не то — в таких случаях проблема скажется на обоих "портах" сразу, ибо статистика общая. Опция свежая, не факт, что хорошо оттестированная, не известно, есть ли у неё сайд-эффекты. Как по мне, так пока лучше по старинке пользоваться: разные профили — разные tor'ы, причём запретить fw'ом слать пакеты торифицированному юзеру в чужой тор вообще. Ну, это всё, как всегда, на случай, когда смешивание профилей действительно смертельно опасно.

М[link34]ожет допилят тему с подключением по разным портам, чтобы было несколько разных управляющих портов, так чтобы это всё работало из коробки.
Да, было бы не плохо. Раз в альфе есть, то имеется надежда, что допилят. С другой стороны, я бы на такой механизм в серьёзных случаях полагаться б не советовал. Даже из общих соображений понятно, что если надо разделить нечто на две нескоррелированных части (и так сделать можно), то всё должно быть разное — это будет надёжней.

Если искать баланс между безопасностью и анонимностью, то, как уже в некоторых местах говорилось (и unknown соглашался, но точную цитату будет трудно найти), в критических случаях лучше одновременно не работать под разными несмешиваемыми профилями одновременно (даже через разные цепочки). Это даст некоторую вредную корреляцию, но прирост подстраховки в плане безопасности будет, наверно, её перекрывать.
— Гость (16/02/2015 10:52)   

Тоже про это подумал.


Да, технически его поддерживать проще (но с безопасностью я поспорил бы).


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

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

Кстати, по поводу разделения цепочек: Tor мог бы делать их разными по умолчанию, если трафик идёт от разных системных юзеров. Делает ли он так? Или у него юзеры только в смысле явных имён в SOCKS-авторизации?
— Гость (16/02/2015 10:58)   

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


Как и для gpg[link36].
— unknown (16/02/2015 11:04)   

Торовский демон не резолвит имена системных юзеров. Для того, чтобы парсить имена юзеров в локальном трафике нужно иметь права рута, без которых тор, к счастью, обходится.
— Гость (16/02/2015 11:14)   

При прозрачной торификации ему уже дают[link37] права, сравнимые с правами рута для чтения всего трафика, без них прозрачка не заработает. Например, в случае BSD это право на чтение[link38] /dev/pf.
— Гость (16/02/2015 11:15)   
Т.е. конкретно в случае прозрачной торификации от добавления ещё и разруливания трафика по разным системным пользователям Tor мало бы что потерял.
— Гость (16/02/2015 11:19)   
При разделении по портам нескольких точек отказа не возникает.

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

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

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

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

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

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

Это делает не Tor, а torsocks если в его настройках указана версия SOCKS 5 и дефолтный пароль. Тогда он видимо подставляет при аутентификации на Tor имя или идентификатор системного пользователя в случае когда он не указан опцией или переменной окружения. В proxychains такой особенности не наблюдается.
— Гость (16/02/2015 11:52)   

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


Не понимаю, что мешает трояну создать свой файл torsocks.conf, а потом выполнить команду[link40]
$ 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)   

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


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


Совершенно верно, но никто и не говорил, что это единственная контрмера. Дальше будет паравиртуализация[link42] с целой деревней домов[link43]. Впереди нас ждёт много увлекательных открытий и срачей на pgpru на тему Xen и ему нужных приблуд. Strong anonymity — наше всё[link44]. Лично я голосую за беспомпромиссную безопасность[link45].
# 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)   

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


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


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


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

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

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

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

Здесь[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, эта проблема возникнет и на хостовой системе.

— pgprubot (07/06/2015 20:16, исправлен 07/06/2015 20:17)   

В 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)   
Проверил редирект. Увы, работает:

— pgprubot (09/06/2015 06:27, исправлен 09/06/2015 06:29)   

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


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 — слишком умная тулза, чтобы быть анонимной и безопасной. Умеет намного больше, чем от неё могут поначалу ожидать.

— pgprubot (09/06/2015 19:54, исправлен 09/06/2015 19:56)   

Мне тоже кажется, что будет отдавать IP=127.0.0.1. Обычно FTP-клиент определяет локальный IP так: он делает getsockname для основного FTP-соединения (исходящего) и отдает полученный IP. Основное соединение будет с 127.0.0.1. Вот если там прозрачная торификация, то не знаю, может быть засада.

— pgprubot (14/06/2015 16:18, исправлен 14/06/2015 16:39)   

<...> s[link53]hould upgrade, as should any clients who rely on port-based circuit isolation <...> Tor 0.2.6.9 fixes a regression in the circuit isolation code <...> Clients using circuit isolation should upgrade

Properly separate out each SOCKSPort when applying stream isolation. The error occurred because each port's session group was being overwritten by a default value when the listener connection was initialized.

Похоже, что изоляция цепочек по портам вообще не работала. Фатальный баг.

— cypherpunks (14/08/2015 19:09, исправлен 14/08/2015 19:09)   
*BUT* if the server reject the PASV command, Wget automatically falls back to
PORT. This is a security thread to people who try to stay anonymous, the real
client's IP will be shown to the FTP server.
I guess this is the what you are talking about !?

Anyways, this behavior has to be changed.


Thanks for throwing this up.


Well somesite.com could redirect you to an FTP site.
If the FTP site rejects the PASV command, Wget will send a PORT command
including the client's IP address. This is fixed now.


But to be 100% sure, you should add --passive-ftp to your command line.
If you don't do that, your /etc/wgetrc or ~/.wgetrc could include --no-passive-ftp (or passiveftp = off). That switches passive FTP off and makes
Wget sending a PORT command (+ IP address) to the FTP server (sometimes you
need this, if the server does not support passive FTP).

Баг[link54] исправлен[link55].

— Гость_ (14/08/2015 21:28)   
Даа, ничему нельзя доверять, подставы на каждом шагу:(
Спасибо за ссылки.
— pgprubot (15/08/2015 14:29)   

Консольные утилиты при прочих равных считаются безопаснее комбайнеров, но не стоит забывать про пределы применимости этого мнения:

В[link56]се параноики опять обломались. А то всё файрфокс, файрфокс...

P. S. Когда за lynx взялась комманда профессора Бернштейна, то и в этом простом браузере находили уязвимости, дающие выполнить произвольный код.

При том, что он не только javascript не поддерживает, а практически вообще ничего.

О[link57]ни безопасны за счёт минималистичности. Но к сожалению их авторы не были параноиками, помешанными ну если не на анонимности, то хотя бы на безопасности. Было какое-то показательное исследование (от DJB?) по нахождению дырок в Lynx и прочих аналогичных программах. После этого, там много чего пофиксили. Новых показательных исследований не проводилось. В суперминималистичных и написанных по параноидально-безопасным принципам прогах самого DJB также нашли уязвимости. В мире нет ничего идеального.

Ссылки
[link1] https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorifyHOWTO/EMail

[link2] https://lists.torproject.org/pipermail/tor-talk/2011-June/020535.html

[link3] http://www.pgpru.com/comment42306

[link4] https://code.google.com/p/torsocks/

[link5] http://tsocks.sourceforge.net/faq.php#local

[link6] http://www.pgpru.com/comment47030

[link7] http://www.pgpru.com/comment70462

[link8] https://github.com/rofl0r/proxychains-ng

[link9] http://www.pgpru.com/comment85858

[link10] http://www.pgpru.com/comment70392

[link11] http://www.pgpru.com/comment81962

[link12] http://mpop.sourceforge.net/comparison.html

[link13] http://mpop.sourceforge.net/doc/mpoprc.txt

[link14] http://www.pgpru.com/comment85905

[link15] http://www.pgpru.com/comment47679

[link16] http://www.pgpru.com/comment47662

[link17] http://tsocks.sourceforge.net/faq.php#ssh

[link18] http://www.pgpru.com/comment35644

[link19] http://www.pgpru.com/comment88091

[link20] http://www.pgpru.com/comment88108

[link21] http://www.pgpru.com/comment86348

[link22] http://www.pgpru.com/comment86347

[link23] http://pkgsrc.se/wip/proxychains

[link24] http://www.pgpru.com/comment87151

[link25] https://www.pgpru.com/forum/unixlike/voprospohederammutt

[link26] http://www.pgpru.com/comment57673

[link27] http://www.pgpru.com/comment63746

[link28] http://www.pgpru.com/forum/anonimnostjvinternet/staryebagioglavnom

[link29] http://www.pgpru.com/novosti/2013/fpdetectivevyjavljaetpopytkiopredelenijaprofiljasistemyizpodbrauzera

[link30] http://www.pgpru.com/comment87359

[link31] https://lists.torproject.org/pipermail/tor-dev/2014-November/007738.html

[link32] http://www.pgpru.com/comment75114

[link33] http://www.pgpru.com/comment58822

[link34] http://www.pgpru.com/comment52147

[link35] http://www.pgpru.com/comment88111

[link36] http://www.pgpru.com/comment88308

[link37] http://www.pgpru.com/comment58312

[link38] http://www.pgpru.com/biblioteka/rukovodstva/setevajaanonimnostj/prodvinutoeispoljzovanietorvunix/nastrojjkatorruterapodbsdtransparenttorproxykakanonymizingmiddlebox

[link39] https://www.pgpru.com/comment88148

[link40] http://www.pgpru.com/novosti/2013/fbroficialjnopriznalasjvkontrolenadanonimnojjsetjjutor

[link41] http://www.pgpru.com/comment57667

[link42] http://www.pgpru.com/comment68237

[link43] http://www.pgpru.com/forum/unixlike/xeniprofilianonimnostiprivatnosti

[link44] http://www.pgpru.com/comment54190

[link45] http://www.pgpru.com/comment73398

[link46] http://www.pgpru.com/comment34713

[link47] http://www.pgpru.com/comment67944

[link48] http://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] http://www.pgpru.com/comment93136

[link52] http://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] http://www.pgpru.com/comment11759

[link57] http://www.pgpru.com/comment55516