id: Гость   вход   регистрация
текущее время 06:08 21/05/2022
создать
просмотр
ссылки

TrueCrypt + Internet


Насколько безопасна данная связка? Один мой знакомый принципиально не использует TC когда компьютер подключен к интернету под виндами (боится, что из сети узнают ключи или незащищенные данные для ускоренного подбора ключа позже)
Это параноя или в какой-то степени может быть оправдано? И если последнее, то вечный вопрос: где утечка и как защититься ?


 
На страницу: 1, 2, 3 След.
Комментарии
— Гость (04/04/2012 00:47)   <#>
Кроме трояна, вариантов утечки не вижу.
— Гость (04/04/2012 08:16)   <#>
не использует TC когда компьютер подключен к интернету
Уж если на то пошло, то не надо подключать к интернету компьютер, на котором когда-либо вводилась какая-либо секретная информация (например, пароли), ибо троян-кейлоггер или иные "недокументированные функции ОС или железа" могли её запомнить что-бы передать "кому следует" при появлении сетевого подключения.
— Гость (09/04/2012 09:17)   <#>
Уж если на то пошло, то не надо подключать к интернету компьютер, на котором когда-либо вводилась какая-либо секретная информация

Если в виртуалке, то можно :)

Один мой знакомый принципиально не использует TC когда компьютер подключен к интернету под виндами (боится, что из сети узнают ключи или незащищенные данные для ускоренного подбора ключа позже) Это параноя или в какой-то степени может быть оправдано? И если последнее, то вечный вопрос: где утечка и как защититься?

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

Всё, опять же, определяется разменой безопасности на удобство. Если данные критичны, то делаешь всё так, как ваш знакомый, всё верно:
  1. Отключаем интернет.
  2. luksOpen
  3. Работаем с данными
  4. luksClose
  5. Затираем все следы от данных в /tmp, /var и проч.
  6. Подключаем интернет

Понимаете, дело же ещё вот в чём может быть: если у вас стоит минималистичный UNIX, в котором вы знаете дословно все запущенные процессы, хорошо понимаете как что работает, всё под контролем pf/iptables — это одно (достаточно закрыть доступ в сеть только для одного конкретного юзера и не пользоваться программами, которые пишут в /tmp и /var). Если же у вас очередной монстр типа винды, убунты или ещё чего, то крайне маловероятно, что вы знаете все детали того, как оно работает. Может быть, оно захочет под секретным юзером что-то профилактически обновить, синхронизироваться с чем-то или ещё что в голову прийдёт — гарантий никаких при работе под таким юзером. Часто проще не думать обо всём вышенаписанном, а просто выдёргивать провод, когда надо.

Скажу честно, что, например, под моей убунтой я сделал себе монитор всех залогиненных юзеров, чтобы видеть, кто в текущий момент в системе помимо меня. Периодически (не так-то редко) я вижу, что результат команды (это из конфига ~/.screenrc)
backtick 1 10 10 sh -c "users |sed 's/МОЙ_ЮЗЕР //g;s/МОЙ_ЮЗЕР//'"
выдаёт мне, что появляется на несколько секунд залогиненным тот юзер, в которого я вообще не залогинен никаким боком. Что это — для меня загадка до сих пор. Появляется на секунды 3 где-то, потом исчезает. Надеюсь, что меня не протупит очередной раз, и я-таки успею запустить ps auxww в нужный момент. Вот зачем убунте надо периодически что-то выполнять из-под некоторого юзера, если он даже не залогинен? Просто мистика какая-то. Так что не трогайте вашего знакомого: он защищается, как умеет.
— Гость (09/04/2012 22:05)   <#>
Если в виртуалке, то можно :)
Вы не "вкурили". Троян-кейлоггер может записывать нажатия клавиш при вводе пароля и сохранять их вне виртуальной машины, а при последующем подключении к интернету сливать записанное ранее. Также он может записывать снимки экрана и оперативной памяти. А при получении пароля и расшифровывать содержимое диска напрямую.
— Гость (10/04/2012 02:20)   <#>
Если мы считаем, что уязвимости в самой виртуалке (типа Xen) нет, то виртуальная машина в принципе не может ничего сохранять вне себя и той части диска, которая ей доступна (разве что в интернете). Всё, что может утечь злоумышленнику в таком случае — информация, которая проходила когда-либо через виртуалку, либо была ей доступна. Прямого доступа к железу у виртуалки нет. И виртуалка имеет доступ только к тому куску оперативной памяти, который ей был выделен хост-осью.
— Гость (10/04/2012 14:45)   <#>
виртуальная машина в принципе не может ничего сохранять вне себя и той части диска, которая ей доступна
Откуда виртуальная машина по вашему берёт нажатия клавиш с реальной клавиатуры? Между ними стоит драйвер реальной системы, и вот за этот драйвер и можно цеплять троян, работающий в реальной системе.
— Гость (10/04/2012 15:23)   <#>
Откуда виртуальная машина по вашему берёт нажатия клавиш с реальной клавиатуры?
Гипервизор виртуальных машин ей передает, а он берет от внешней (dom0) системы стандартным способом. Сейчас речь идёт про троян в виртуалке (гостевой ОС, domU), а не в host OS (dom0); и если уязвимости в самом гипервизоре нет, а dom0 не скомпрометирован, то троян в domU вам ничего не даст.
— Гость (10/04/2012 15:47)   <#>
Сейчас речь идёт про троян в виртуалке
Я вёл речь о трояне снаружи.
если уязвимости в самом гипервизоре нет, а dom0 не скомпрометирован, то троян в domU вам ничего не даст
Вот уже два условия, и чтобы надёжно обеспечить второе не надо ходить в интернет из реальной системы никогда. Много вы таких пользователей Windows видели?

И вообще, если у нас нигде нет уязвимостей, то и утечки информации не будет, и говорить не о чем :)
— Гость (10/04/2012 16:03)   <#>
чтобы надёжно обеспечить второе не надо ходить в интернет из реальной системы никогда
Имелось в виду несколько не это. В реальной системе может быть минимум софта, и софт этот может быть очень надёжным: никаких там браузеров, проигрывателей и прочего — только файерволл (например, только тот софт, который входит в базовую систему *BSD). В виртуалке же может быть всё, что угодно. Тогда залоумышленник, даже получивший права root'а в виртуалке, так и не узнает, на каком железе она запущена. Даже если злоумышленник знает, например, MAC-адрес вашей сетевой (железо когда-то было скомпрометировано полностью, а вся инфа слита вовне) и захочет проверить эту гипотезу из виртуалки, ему это не удастся. Я, собственно, только это и хотел сказать. Всё, что известно domU — только точная версия процессора, и всё.
— Гость (02/06/2012 18:43)   <#>
Периодически (не так-то редко) я вижу, что результат команды ... выдаёт мне, что появляется на несколько секунд залогиненным тот юзер, в которого я вообще не залогинен никаким боком. Что это — для меня загадка до сих пор.

Предположительное объяснение таково: когда заканчиваю работу под специальным юзером, проверяю, не остались ли от него какие-то процессы1. Для гарантии используется pkill -9 -U спецюзер. Эта команда убивает нужные процессы, но запись об этих процессах в файле /var/run/utmp, который как раз и читают команды who, w и users, остаётся2. Спустя какое-то время появляется новый процесс из-под основного пользователя, имеющий тот же pid, что и ранее умерший от специального пользователя3. В этом случае команды w, who и users начинают писать, что запущена такая-то программа от имени специального юзера, да ещё и указывая тот tty, который был у давно умершего процесса.

Видимо, ранее наблюдавшееся означает то, что появлялись короткоживущие процессы и потому их не удавалось засечь. Кроме того, я полагал, что они обозначат себя и в ps aux, но это не так: согласно ps владельцем процесса будет числиться именно основной пользователь, от которого этот процесс на самом деле и запущен. В конце концов, случился час X, приведший к появлению долгоживущего процесса, что и позволило изучить ситуацию более подробно.

Что касается выводов, есть суп из рекомендаций:
  • Сначала убивать процессы мягко (pkill -2), давая им завершиться корректно и самим затереть о себе информацию в utmp.
  • Обнулять файл utmp руками.
  • Написать скрипт, который оттуда будет вырезать оттуда этих своего рода «зомбяков» после выполнения команды pkill -9.

P.S.: Параноя до добра не доводит :)


1Обычно они остаются, даже если разлогиниться через интерфейс и закрыть все шеллы — всякие там gnome-session, что-то связанное со screen и т.д.
2Файл /var/run/utmp также содержит pid процесса, но дёшево его не узнать — только разбираться с бинарным форматом руками.
3Это ничему не противоречит, т.к. с точки зрения ОС pid уже свободен и никем не используется.
— Гость (24/08/2014 02:44)   <#>

А в Debian ничего такого нет при тех же условиях, так что объяснение не работает, вопрос остаётся открытым.
— Гость (09/02/2015 07:59)   <#>

Напомнило:

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

Я лично, опираясь на всю ту информацию, которая здесь когда-либо публиковалась, с предубеждением отношусь к аппаратным шифровальным ключам, но, может, чего-то важного просто не знаю. Может быть, SATtva теперь тоже считает, что gpg-remote на удалённой машине или в виртуалке даёт в совокупности не меньшую степень защиты.

Фраза «не хранится на подключённой к сети системе» тоже осмысленна лишь в том случае, если для работы с ключами используется физически отдельный «air gappped» компьютер, информация на который передаётся только через sneakernet.* А если просто время от времени к компьютеру подключается носитель с определённой информацией, это концептуально уже не отличается от того случая, когда информация просто хранится локально.** Просто в случае gpg-remote нужно будет ломать сам сервис, ОС (удалённо) или гипервизор, а в случае аппаратной смарткарты — программный интерфейс к ней. Второй случай считается надёжней первого?


* Т.е., формально это всё равно компьютер, подключённый к сети ☺ — опыт stuxnet подтверждает.
** Грамотный руткит/троян сворует её в момент подключения внешнего носителя, а потом сольёт, когда будет доступ в сеть.
— Гость (09/02/2015 11:19)   <#>

Речь идет о токенах? шифрование Здесь нет такого определения.

Как быть с интернет-банкингом? Возить платежки нарочным?
— unknown (09/02/2015 11:36, исправлен 09/02/2015 11:42)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Некоторые вопросы, требующие серьёзных компромиссов с неидеальной суровой реальностью, к сожалению, никак по серьёзному не решаются. Т.е. ответ будет или такой же несерьёзный как и вопрос, в виде очередного упражнения в остроумии на уровне «хихи-хаха»; или какой-то жалкий компромисс; или предложение отказаться от безопасности в этом вопросе; или да — нечто неудобное: возить на бумажке, не пользоваться мобильным и т.д.

— Гость (09/02/2015 11:54)   <#>

Ну вопрос риторический и не требует ответа. Очевидно, что в некоторых вопросах требуется компромисс.
Любое средство передвижение несет в себе риск потери здоровья вплоть до летального, но мы же ими пользуемся. Жить вообще опасно.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3