РегистрацияТорификация mutt
Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.
Достаточно, это несложно проверить. Авторизация в Tor отличается от стандартной username, и у меня информация только из экспериментов. Не уверен, что все детали где-то описаны, кроме программного кода. Многие вещи проще самому проверить, чем искать в документации.
А как проверяли? Читали код? Или анализировали строящиеся цепочки на низком уровне через какой-нибудь tor-arm?
Конкретно эта фича вроде как заявлена, так что должно работать, но трудность её верифицируемости (как и многих других фич) меня смущает. Трудно жить, когда ни к чему нет стопроцентного доверия. В документации они могут написать одно, а на деле будет происходить другое; они могут знать об этом, но ничего не делать.
Заявлено, что TBB ничего не пишет вне своей директории, а это не так. Разработчики об этом знают, но не исправляют. Уже три года как не исправляют. Ими признанный всесторонний анализ утечек ещё более удручающ, но они не чешутся. А на бумаге и в документации всё гладко, да. Исправили ли они утечку версии ОС (и ещё много чего) при включённом JS? Непонятно. Также непонятна ситуация с вытягиванием списка шрифтов из системы (даже без JS). Внимательно следящие за багтрекером наверняка скажут, что в любой момент времени известны десятки критических уязвимостей, которые могут не исправляться годами. Судя по всему, к разработке самого Tor'а они примерно так же относятся.* Это всё снова возвращает к тому же вопросу: во что мы верим и чему доверяем.
Да, но есть риск завязаться на некоторое свойство, которое не заявлено в документации, и которое в следующих релизах может поменяться, а вы не заметите — это даже при условии, что в одного можно проанализировать код Tor'а. В индустрии оупенсорца такое часто бывало: огромное количество софта решило завязаться на недокументированные особенности интерфейсов, а когда разработчики выпустили новую версию и «всё сломалось», начинается вой и поиск виноватых.
Разделение по портам для изоляции цепочек явно оговорено в документации и имеет то преимущество, что можно разнести юзеров файерволлом. Когда нужно железно исключить вмешательство одних программ (из-под одного юзера) в работу других (из-под другого юзера), изоляция по портам — самое то. В этом случае зловред при всём желании не сможет залезть в чужую цепочку (если только в самом Tor'е на эту тему баги не будет).
* У unknown'а был комментарий (всё перерыл, не могу найти) на тему того, что какую-то редкую опцию в Tor-клиенте (то ли поддержка приватных скрытых сервисов, то ли ещё что) они несколько раз ломали, из-за чего чуть ли ни месяцами все такие сервисы были де факто нерабочими. При всём этом в рассылке и багтрекере никто не пожаловался ни разу.
комментариев: 9796 документов: 488 редакций: 5664
А я в том коментарии хотел найти то ли соответствующий комент в рассылке, то ли в торблоге, то ли в тикетах, всё перерыл, так и не нашёл. Но проблема такая точно есть.
В первом и третьем случаях адрес будет одинаковым, отличным от второго.
То же можно сказать про всё остальное, в том числе разделение цепочек по портам.
Разделение цепочек по пользователям официально заявлено и применяется по умолчанию. Использование разных имён пользователей должно давать разные цепочки, является логичным и скорей всего такое поведение сохранится в дальнейшем. Конкретно ваш вопрос по смене цепочек для разных паролей в документации не отражён, но проверяется легко если возник такой интерес, но полагаться на такое поведение в будущем не стоит.
Разделение по пользователям тоже явно оговорено, разнести их ещё легче – запускать программы с правами разных системных пользователей (что само по себе повышает безопасность), у которых конфигурационные файлы, содержащие user/pass, недоступны для чтения всем. Например, файлы /.torsocks.conf или /.proxychains/proxychains.conf будут одинаковы для всех пользователей, отличаясь только двумя строками – для user и password. Разные системные пользователи не будут знать эти данные друг у друга. Если один из них скопрометирован, он не сможет получить доступ к цепочках других пользователей, т.к. не знает их имён и паролей на Tor. В итоге получается проще – не нужно создавать для каждого пользователя SOCKS-порт, защищать его файрволом и помнить соответствие между именем пользователя и номером порта.
Если не используется прозрачная торификация, то проксифицировать программы в любом случае нужно, независимо от того, разделяются ли цепочки по портам или именам пользователей. Но в первом случае необходимо ещё править torrc и правила iptables, а во-втором достаточно лишь добавить строку в torsocks.conf или proxychains.conf. Т.е. в первом случае нужно править три файла и помнить связи между ними, а во втором только один файл и помнить ничего не нужно, т.к. SOCKS-порт один на всех.
В целом согласен, но, с другой стороны, появляется единая точка отказа: если где-то по ошибке забыли поставить уникальный пароль (при копировании конфигов между пользователями) или вообще забыли указать какой-либо пароль, то цепочки смешаются, а при разделении по портам, если где-то будет ошибка в конфигурировании, то, скорей всего, она будет выявлена намного быстрее, потому что просто не заработает.
Потом есть впрос диагностики. Я иногда смотрю на монитор типа netstat, там есть статистика. Есть статистика пакетов и в правилах iptables-save -c. Она показывает, через какой порт сколько пакетов прошло, кто через какой порт работает и т.д. Это даёт дополнительную степень свободы для контроля.
Ещё мне интуитивно кажется, что когда на один и тот же порт суются программы от разных юзеров, которые не должны взаимодействовать между собой (в идеале) вообще никак, шансы на утечки информации между ними повышаются. Возможно, это мои необоснованные иррациональные страхи из-за недостатка знаний.
Unknown, перестаньте издеваться, дайте ссылку на тот свой комментарий! ☺ Или вы его теперь тоже не можете найти? На форуме под 100k комментариев, и хотя память у меня не совсем дырявая, я уже приближаюсь к своему
квантовомуфизическому пределу на то, чтобы помнить всё, где, что и по какому случаю было сказано. Сейчас за несколько месяцев здесь появляется больше новых и содержательных комментариев, чем раньше появлялось за несколько лет, тема ИБ разрастается и в ширь и в глубь...комментариев: 9796 документов: 488 редакций: 5664
Нашёл не свой:
И это ноябрь 2014 года, а оно всё ещё не работает гарантированно.
Одну точку отказа легче контролировать, чем несколько. Всё зависит от того, как организовать. Можно например держать где-нибудь (/somedir) конфигурационные файлы, на которые при очередной установке делается символическая ссылка из нужного места
Или создать скрипт для запуска torsocks/proxychains, который берёт имя пользователя из /dev/urandom. Тогда даже приложения с одинаковыми системными правами не будут знать друг у друга аутентификационные данные на Tor.
По отношению уровня безопасности к затратами на его поддержание, способ с аутентификацией представляется более выгодным и не таким костыльным, как с разделением по портам.
Мне так не кажется, порт это лишь способ передачи данных между процессами, а построение цепочек определяется ядром Tor-клиента. Ему без разницы, как получены данные – через один порт или несколько, номер порта это просто различитель, помечающий разные приложения, также как имя/пароль.
Аналогичное можно сказать про «для разных пользователей забыли указать разную авторизацию, или она у обоих слетела».
Если искать баланс между безопасностью и анонимностью, то, как уже в некоторых местах говорилось (и unknown соглашался, но точную цитату будет трудно найти), в критических случаях лучше одновременно не работать под разными несмешиваемыми профилями одновременно (даже через разные цепочки). Это даст некоторую вредную корреляцию, но прирост подстраховки в плане безопасности будет, наверно, её перекрывать.
Тоже про это подумал.
Да, технически его поддерживать проще (но с безопасностью я поспорил бы).
При разделении по портам нескольких точек отказа не возникает. Если вы напартачите в каких-то настройках, с вероятностью почти 100% трафик не сможет выйти в сеть. В случае с авторизацией если вы сделаете что-то не так, оно продолжит работать, как и раньше, внешне ничего не будет заметно.
Мне нравится идея финального контроля над трафиком со стороны рута. В случае разуливания файерволлом это так. Т.е. как бы юзеры ни извращались, и что бы и как бы там у них ни слетало (даже если они сговорятся вместе и согласовнно обнулят авторизацию), к чужим портам, а потому и цепочкам, они подцепиться не смогут. Считате, что под разными юзерами запущены трояны, и они должны понять, на одной машине они работают или на разных. Только если у них не получается это выяснить, система безопасна.
Кстати, по поводу разделения цепочек: Tor мог бы делать их разными по умолчанию, если трафик идёт от разных системных юзеров. Делает ли он так? Или у него юзеры только в смысле явных имён в SOCKS-авторизации?
Трояны укажут переменной свой конфиг для proxychains/torsocks, где не будет никакой авторизации. Так два разных юзера пойдут по одним цепочкам. В случае разруливания файерволлом эта дырка закрывается, а в вашем нет.
Как и для gpg.
комментариев: 9796 документов: 488 редакций: 5664
Торовский демон не резолвит имена системных юзеров. Для того, чтобы парсить имена юзеров в локальном трафике нужно иметь права рута, без которых тор, к счастью, обходится.
При прозрачной торификации ему уже дают права, сравнимые с правами рута для чтения всего трафика, без них прозрачка не заработает. Например, в случае BSD это право на чтение /dev/pf.