id: Гость   вход   регистрация
текущее время 17:25 28/03/2024
Автор темы: Вий, тема открыта 25/09/2011 06:56 Печать
Категории: инфобезопасность, защита дисков
https://www.pgpru.com/Форум/ПрактическаяБезопасность/БезопасностьСпящегоРежимаКомпьютера
создать
просмотр
ссылки

Безопасность спящего режима компьютера


При отправке компьютера в спящий режим сеанс сохраняется на жестком диске. При включении компьютера, после загрузки базовых компонентов системы, достаточно лишь ввести пароль пользователя, после чего на мониторе появляется (достаточно быстро) рабочий стол с открытыми теми программами, которые были в работе на момент завершения работы компьютера. Однако заставляет задуматься следующий факт, учитывая, что в системе используется шифрование учетной записи, хотя и стандартным способом системы, который предлагается при создании учетной записи (система Ubuntu 10/04).
А именно: учитывая очень быстрое открытие программ можно предположить, что при включении машины данные либо расшифровываются БЕЗ РУЧНОГО ввода пароля, а ввод пароля лишь разблокирует доступ к монитору, либо сохраняются в контейнер спящего режима без зашифровки. Выходит, что к пользователським данным можно получить доступ либо взяв их с винчестера, если они сохраняются в нешифрованном виде, либо включив компьютер постараться обойти блокировку монитора. Есть ли в моих рассуждениях доля истины?



 
На страницу: 1, 2 След.
Комментарии
— Гость (26/12/2012 14:45)   <#>
или только дополнением TCTEMP к ТС? посиком нашел здесь
— unknown (26/12/2012 15:03)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Ну вот в Linux в Tuxonice сначало вроде было встроенное шифрование, а затем его выкинули, потому что безопаснее нестроить программу на настройку с системным шифрованием, а не встраивать в неё своё.
— Гость (26/12/2012 15:14)   <#>
тогда как обеспечить шифрование swap? шифровать как файл паролем?
— unknown (26/12/2012 16:01)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В Windows? Без понятия.


Ну так ещё хуже.
— Гость (26/12/2012 20:03)   <#>
Вот нашел для Windows:
Файлы подкачки, предотвращение утечек там же и Предотвращение утечек в файле hiberfil.sys, Отключение Восстановления Системы (System Restore) и другое.
— Гость (26/12/2012 20:08)   <#>
fsutil behavior set EncryptPagingFile 1
Вроде бы своп шифруется и в открытую не читается. Как это сделано – черт его знает.
— Гость (26/12/2012 20:28)   <#>
вот еще нашел. цитата:
Поскольку компания Microsoft выпустила API (Application Programming Interface – интерфейс прикладного программирования) для Windows Vista и Windows 7, то программа может также шифровать файлы режима "сна" и аварийного дампа
только где оно?
fsutil behavior set EncryptPagingFile 1
а это что?
— Гость (26/12/2012 20:29)   <#>
зы: первая цитата была о ТС.
— Гость (28/12/2012 02:52)   <#>
На отвлечение на телефонный звонок или уход пообедать будете скринсейвером пользоваться? Или суспендом?
Ну, отмонтировать лишние тома точно не помешает :)

А какой программой можно шифровать своп в Винде? платную знаю, а вот opensource нет.
Есть как часть функций DiskCryptor, насколько я помню. Проверяйте. Оно opensource.
— Гость (28/12/2012 11:44)   <#>
вот еще вопрос в разрезе шифрования. зашифрован раздел. при загрузке предлагается ввести пароль и открыть доступ к нему – делаем. далее работаем с разделом. по окончании работы с таким разделом, логично закрыть доступ к нему и продолжать работать, НО PGP например этого делать не может. единственный выход – перезагружать комп. а тот же DiskCryptor например, такое может? речь идет о Виндах.
— unknown (28/12/2012 12:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Есть ли какие-то средства посмотреть, какие процессы удерживают этот раздел?
— Гость (28/12/2012 23:00)   <#>
Ну, отмонтировать лишние тома точно не помешает

Если использовать рекламируемое unknownом иерархическое шифрование, то расшифровка корня приведёт к расшифровке всего остального. Поэтому самое надёжное – выключение, если нет уверенности что hibernate правильно сделан. А быть уверенным в хибернейте можно только если хорошо известно его устройство, в идеале нужно делать его самостоятельно.
— Гость (29/12/2012 05:51)   <#>
Гость (28/12/2012 23:00), согласен. В схеме unknown'а это работать не будет. Я имел в виду совершенно независимое монтирование томов, пусть хоть расположенных на одном и том же корневом разделе. Даже если противник получит доступ к корню, но, если некоторые внутренние разделы были отмонтированы и сделан luksClose, доступ к ним он получить всё равно не сможет.
— unknown (29/12/2012 09:58, исправлен 29/12/2012 10:05)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

При ручном отмонтировании томов LUKS по идее принудительно стирает их ключ из памяти и он вообще старается до последнего не попадать в своп кроме случая гибернейта.


Однако при гибернейте в свопе накапливается много лишней потенциально опасной информации, которая вся зависит от безопасности корневого шифрования. В этом его потенциальная опасность и компромиссность.


Поэтому в моём варианте своп шифруется дважды. Как самим фактом размещения логического своп-раздела на шифрованном физическом. Так и шифрованием производным ключом от физического раздела. Это позволяет мгновенно стереть ключ шифрования из LUKS слота своп-файла (при этом запись-чтение на этом ключе в своп продолжатся, в памяти то он продолжает висеть). А затем при отсутствии необходимости гибернейта сделать poweroff. Тогда после повторного включения своп будет нерасшифровываемым, т.к. ключ от него будет навсегда утерян и все накопленные в нём данные пропадут. Это гораздо быстрее (пара секунд), чем перетирать своп после гибернейтов (десятки минут) или отсоединять его для перешифровывания на рабочей системе (минуты). После загрузки не из гибернейта своп (по желанию) заново подключается и форматируется в шифрованном виде. Поскольку он уже отсоединённый и пустой, это тоже занимает секунды.



Простой скрипт, правка пары конфигов и обновление initrd.

На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3