Торификация mutt
Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.
Можно указать в настройках пользователя и iptables не тот порт, тогда для разных пользователей будет одна цепочка. Но в целом да, вероятность выйти в сеть с неправильными настройками меньше.
Уже упоминал в этой теме, что для torsocks это так. Достаточно определить опции server_port и default_pass в глобальном конфигурационном файле, тогда для разделения цепочек можно обойтить без файлов для каждого пользователя (/home/wget/.torsocks.conf и т.д.). Можно ли полагаться на это в будущих версиях – не знаю, но как дополниительная подстраховка сойдёт.
Во-первых, у каждого системного пользователя свои переменные окружения, которые друг с другом не пересекаются. Во-вторых, указывать пользователей и пароли в переменных окружения вообще не рекомендуется, т.к. их можно увидеть в списке процессов. Лучше указывать только путь к конфигурационному файлу, права на чтение которого имеет только правильный пользователь.
Это делает не Tor, а torsocks если в его настройках указана версия SOCKS 5 и дефолтный пароль. Тогда он видимо подставляет при аутентификации на Tor имя или идентификатор системного пользователя в случае когда он не указан опцией или переменной окружения. В proxychains такой особенности не наблюдается.
Да, мне нужно будет ошибиться в двух местах сразу: как в конфигах целевого пользователя, так и в конфиге для iptables. Если ошибка будет только в одном месте, программы просто не соединятся с сетью. Более того, пока я настраивал разруливание трафика и его фильтрацию, неоднократно отлавливал разные баги в конфигурации именно этим методом: вдруг не работало что-то, что должно было работать.
Не понимаю, что мешает трояну создать свой файл torsocks.conf, а потом выполнить команду
В моём примере всё так и есть. Под двумя разными системными юзерами работают трояны. Они согласованно через TORSOCKS_CONF_FILE выставляют себе одинаковые конфиги torsocks.conf и начинают работать через одинаковые цепочки.
Такое возможно, т.к. Tor не проверяет имя и пароль. При нормальной username-аутентификации подобная возможность была бы исключена. Эту проблему можно решить добавлением между приложениями и Тором SOCKS-сервера со стандартной аутентификацией, но такое решение вряд ли подходит для всех, несмотря более высокую защиту и возможность подробной статистики (по пользователям, портам, IP-адресам, объёму трафика).
Если ваши трояны могут выполнять произвольные команды в системе (как torsocks/proxychains), значит они могут посылать на заданный внешний адрес идентификационные данные системы, например вывод dmesg. Это более сильная и вероятная атака, чем смешение трафика пользователей в одной цепочке, и ваш разброс по портам от неё не защитит. Так что вопрос целесообразности усложнения от разброса пользователей по SOCKS-портам остаётся.
Внеся дополнительные опции в torrc его разве нельзя научить проверять имя/пароль?
Верно. По-хорошему, можно хоть своё DPI замутить (не вы ли его предлагали?), но есть решение для бедных: разнести по разным портам и ловить статистику на них, iptables-save -c её показывает. Наверняка есть ещё более удобные инструменты. Лично мне нравится pftop, наверняка для iptables есть подобный инструмент. В некотором смысле tor-arm, правда, даёт это и даже больше из коробки. Там, наверно, тоже как раз удобно смотреть в зависимости не от авторизации, а от номера SocksPort'а (unknown бы точнее сказал).
Совершенно верно, но никто и не говорил, что это единственная контрмера. Дальше будет паравиртуализация с целой деревней домов. Впереди нас ждёт много увлекательных открытий и срачей на pgpru на тему Xen и ему нужных приблуд. Strong anonymity — наше всё. Лично я голосую за беспомпромиссную безопасность.
Если найдёте в мане эти дополнительные опции, сообщите. Пока видел только аутентификацию для контрольного порта, а также для HTTP и SOCKS-проксей между клиентом а входной нодой.
Если дальше накручивать, то возможно дополнительные тор-порты усилят безопасность. Но в контекте рядового использования особого преимущества в них не нахожу.
В системе может быть с десяток заторенных приложений, если для каждого свою виртуалку создавать, то никаких ресурсов не хватит. Вы ради каждой консольной утилиты типа wget, msmtp, fetchmail, gpg и т.д. собираетесь это делать? Понимаю, когда сложное и критичное приложение, как веб-браузер, запускают в виртуалке, но для консольных утилит проще chroot организовать, идентификация системы при этом тоже сильно затрудняется.
Виртуалки создаются не на приложения, а не «профиль» (на юзера). Дальше этот юзер может запускать сам, что захочет.
Конечно, в первую очередь, для него.
Нет. Допустим, есть профиль «работа с почтой». Его можно запустить в отдельной гостевой ОС и дать возможность выполнять оттуда всё, что захочется (получение почты, отправка; при желании и надобности — другие консольные утилиты). Важно, что информация будет только почтовая, поэтому при компрометации ничего более, чем БД почты, утечь не может.
Использование чрута для безопасности/анонимности — распространённое заблуждение. Даже LXC заблуждение:
А SELinux'а для анонимности нет (скрытие информации о железе), поэтому остаются только (настоящие) виртуалки.
Мне кажется, вы не понимаете, о чём идёт речь. Тут нет никаких «из-под одного юзера через sudo/su/gksu выполняем что-то». Есть физически разные иксы, они на разных дисплеях, под разными иксами выполяняются разные задачи. Например, под одними — только работа с вебом через TorBrower (при желании можно и ситуативное консольное что-то запускать, но никакой информации к настоящим хоумам там нет). Под другим — только джабберы, почта, ssh-тунели и gpg и некоторые приложения, не требующие работы с сетью (pdf, TeX, djview). Под третьим — только мультимедиа, он вообще доступа к сети не имеет, только на lo (музыка, проигрыватели видео, gimp'ы и прочая работа с графикой). Как-то так. Но сейчас это, допустим, три разных пользователя, а могло бы быть три разных гостевых ОС в виртуалке. Деление не обязательно должно быть именно таким, это просто общий набросок идеи. Деление идёт, в первую очередь, не по программам, а по ролям доступа к информации того или иного класса.
комментариев: 9796 документов: 488 редакций: 5664
Да и обновлять все пакеты и конфиги в каждой из пяти виртуалок — то ещё развлечение. Я понимаю все преимущества виртуалок и когда-нибудь может до них дойду, но пока долго буду сидеть на компромиссе с параллельными иксами.
Правильней наверное создавать профили не под приложения, а под виртуальные личности. Например: пользователь госуслуг, обычный пользователь для сёрфинга, блоггер, компьютерный специалист и т.п. Если вы в одном профиле смешаете почту для разных виртуалов, это приведёт к профилированию каждого из них и подрыву анонимности тех, для кого она наиболее критична.
Внутри одного профиля, создаваемого виртуальной машиной, разделение цепочек для разных приложений тоже необходимо. Трафик веб-сёрфинга лучше не смешивать с почтой и мессенджерами, иначе профилирование псевдонима накапливается и способствует раскрытию его реальных данных.
При использовании виртуальных машин разброс по портам и SOCKS-аутентификация дополняют друг друга. Для каждой вирт. машины выделяете тор-порт, а цепочки каждого приложения внутри одной машины изолируете аутентификацией. Приложения внутри одной ВМ тоже можно по портам раскидать вместо аутентификации на Tor, но особого смысла в таком усложнении уже нет – от идентификации виртуальной системы это не спасёт при компрометации её пользователей.
Разные машины, реальные или виртуальные, которые по-разному идентифицируются, наверное имеет смысл по разным Tor-портам раскидать. Но приложения внутри одной машины практичней разделить Tor-аутентификацией.
В таком случае ещё проще – трафик разных машин автоматически разделяется по внутренним IP-адресам, а трафик разных приложений внутри одной машины разделяется аутентификацией, и достаточно одного тор-порта. Вместо добавления новых портов для мониторинга лучше наверное arm использовать.
Да, это и имелось в виду, просто плохо выразился. В моём случае большинство юзеров очень специфичны, поэтому разделение по программам почти эквивалентно разделению по «виртуальным личностям», но в общем случае, это, конечно, не так.
комментариев: 511 документов: 2 редакций: 70
Здесь есть предостережения общего характера, которые непонятны (в некоторых случаях wget может пытаться отрезолвить localhost через локальный DNS?). Ещё есть старое обсуждение в рассылке с участием Руны Сандвик, Каммерера и других лиц. Понятно, что торифицировать wget можно по-разному (через переменные среды или через LD_PROLOAD, как это делает torsocks/proxychains), и утечки DNS могут быть как зарезаны, так и нет файерволлом, в зависимости от этого будут разные выводы про «безопасность использования».
Вопрос профилирования тоже ясен, это не TBB, но всё может быть ещё хуже, если в каких-то случаях wget сообщает локальный IP-адрес машины, где он запущен. В рассылке были спекуляции на тему пассивного режима ftp, когда это якобы может происходить, но Каммерер говорит, что даже в этом случае такого не наблюдается, wget передаёт всего лишь адрес localhost'а. Впрочем, так ли это при всех типах торификаций wget (в т.ч. через torsocks) — непонятно. Может ли злонамеренный HTTP-сервер сделать редирект на ftp, принудив wget передать локальный IP-адрес хоста? Достаточно ли надёжно вариант torsocks wget от этого застрахован?
Проще, конечно, не надеяться на костыли, а по возможности запускать всё в виртуалках. Впрочем, если системные апдейты качаются через torsocks wget, эта проблема возникнет и на хостовой системе.
комментариев: 511 документов: 2 редакций: 70
В man wget пишут
Правда, это не про редирект, но информация полезная.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 511 документов: 2 редакций: 70
Скорее, всё же активного. По умолчанию, судя по
режим может быть только пассивным:
Спасибо за проверку. Похоже, wget — слишком умная тулза, чтобы быть анонимной и безопасной. Умеет намного больше, чем от неё могут поначалу ожидать.