Оффлайн
- Регистрация
- 19.09.18
- Сообщения
- 141
- Реакции
- 79
- Репутация
- 1
Всем привет. Продолжаю разбор тем по практической анонимности — сегодня хочу закрыть вопрос, который мне кажется одним из самых недооценённых среди тех, кто строит свою защиту на виртуальных машинах. Многие воспринимают VM как магическую границу: всё, что происходит внутри гостевой системы, остаётся внутри неё. На практике это далеко не так, и я хочу разобрать конкретно, что реально остаётся на хост-системе и почему это важно для модели угроз.
Снапшоты — это не просто "точка восстановления"
Снапшот виртуальной машины это полный слепок состояния оперативной памяти, диска и иногда даже состояния процессора на конкретный момент времени. Проблема в том, что этот слепок физически хранится на диске хост-системы в виде файлов (например .vmem для VMware или аналогичных файлов для VirtualBox), и в этих файлах буквально лежит дамп RAM гостевой системы на момент создания снапшота. Если вы делали снапшот во время активной сессии — там может быть всё: расшифрованные данные, ключи из оперативной памяти, открытые сессии в браузере, даже пароли, если они на тот момент находились в памяти в открытом виде.
Самое неприятное — даже если вы потом откатили снапшот или удалили VM целиком, сам файл снапшота на хосте не обязательно удаляется безопасно. Стандартное удаление файла просто убирает запись из таблицы файловой системы, а данные физически остаются на диске до перезаписи. То есть форензик-специалист с доступом к хост-машине может восстановить эти файлы стандартными инструментами восстановления данных.
Что остаётся на хосте помимо самих снапшотов
Гипервизор ведёт собственные логи — VMware Workstation и VirtualBox пишут файлы конфигурации, логи запуска/остановки VM, иногда даже историю изменений настроек сети. Это метаданные о самом факте существования и использования виртуальной машины, и эти логи лежат на хосте, а не внутри гостевой системы — то есть шифрование диска внутри VM их вообще не защищает.
Дальше — файл подкачки (swap/pagefile) хост-системы. Гипервизор активно использует оперативную память, и если у хоста недостаточно RAM, часть данных гостевой VM может выгружаться операционной системой хоста в файл подкачки на диске. Это означает, что фрагменты содержимого гостевой памяти теоретически могут оказаться в page file хоста, полностью за пределами вашей "защищённой" виртуальной среды.
Похожая история с файлом гибернации хост-системы (hiberfil.sys в Windows) — если хост уходил в сон или гибернацию, пока VM была запущена, в этом файле может застрять снимок всей оперативной памяти, включая память, относящуюся к гостевой системе.
Метаданные файловой системы хоста
Даже без анализа содержимого, сами временные метки создания, изменения и доступа к файлам VM (vmdk, vdi, vmem, конфигурационные файлы) дают форензику временную линию активности — когда VM создавалась, когда последний раз использовалась, сколько раз вносились изменения. Это не раскрывает содержание, но восстанавливает паттерн поведения, что часто бывает достаточно в сочетании с другими данными.
Почему Whonix и подобные решения снижают, но не убирают эту проблему полностью
Архитектура Whonix (Gateway + Workstation) решает конкретную проблему — утечку реального IP при компрометации браузера внутри гостевой системы. Но она не решает проблему форензики на уровне хоста, описанную выше. Если злоумышленник или следствие получает физический или удалённый доступ к самому хосту, а не к гостевой VM, вся изоляция внутри гипервизора не имеет значения — артефакты лежат снаружи периметра, который эта изоляция защищает.
Практические выводы, которые я считаю важными
Полнодисковое шифрование хост-системы (а не только гостевой VM) — это не опция, а необходимость, если в модели угроз есть физический доступ к устройству. Без этого все перечисленные файлы — снапшоты, page file, hiberfil.sys — лежат в открытом виде на хосте независимо от того, как защищена сама VM.
Отключение файла гибернации на хосте и настройка достаточного объёма RAM, чтобы избежать активного использования swap, снижает вероятность утечки фрагментов памяти гостевой системы на диск хоста.
Безопасное удаление снапшотов (с перезаписью, а не просто delete) обязательно, если снапшот содержал чувствительную сессию — иначе восстановление стандартными форензик-инструментами тривиально.
Live-системы вроде Tails в этом смысле архитектурно сильнее именно для разовых задач — они принципиально не создают персистентных файлов на хосте после завершения сессии, потому что вся система работает из RAM и не пишет состояние на диск. Это прямое архитектурное решение проблемы, которую виртуализация на постоянной основе не решает сама по себе.
Снапшоты — это не просто "точка восстановления"
Снапшот виртуальной машины это полный слепок состояния оперативной памяти, диска и иногда даже состояния процессора на конкретный момент времени. Проблема в том, что этот слепок физически хранится на диске хост-системы в виде файлов (например .vmem для VMware или аналогичных файлов для VirtualBox), и в этих файлах буквально лежит дамп RAM гостевой системы на момент создания снапшота. Если вы делали снапшот во время активной сессии — там может быть всё: расшифрованные данные, ключи из оперативной памяти, открытые сессии в браузере, даже пароли, если они на тот момент находились в памяти в открытом виде.
Самое неприятное — даже если вы потом откатили снапшот или удалили VM целиком, сам файл снапшота на хосте не обязательно удаляется безопасно. Стандартное удаление файла просто убирает запись из таблицы файловой системы, а данные физически остаются на диске до перезаписи. То есть форензик-специалист с доступом к хост-машине может восстановить эти файлы стандартными инструментами восстановления данных.
Что остаётся на хосте помимо самих снапшотов
Гипервизор ведёт собственные логи — VMware Workstation и VirtualBox пишут файлы конфигурации, логи запуска/остановки VM, иногда даже историю изменений настроек сети. Это метаданные о самом факте существования и использования виртуальной машины, и эти логи лежат на хосте, а не внутри гостевой системы — то есть шифрование диска внутри VM их вообще не защищает.
Дальше — файл подкачки (swap/pagefile) хост-системы. Гипервизор активно использует оперативную память, и если у хоста недостаточно RAM, часть данных гостевой VM может выгружаться операционной системой хоста в файл подкачки на диске. Это означает, что фрагменты содержимого гостевой памяти теоретически могут оказаться в page file хоста, полностью за пределами вашей "защищённой" виртуальной среды.
Похожая история с файлом гибернации хост-системы (hiberfil.sys в Windows) — если хост уходил в сон или гибернацию, пока VM была запущена, в этом файле может застрять снимок всей оперативной памяти, включая память, относящуюся к гостевой системе.
Метаданные файловой системы хоста
Даже без анализа содержимого, сами временные метки создания, изменения и доступа к файлам VM (vmdk, vdi, vmem, конфигурационные файлы) дают форензику временную линию активности — когда VM создавалась, когда последний раз использовалась, сколько раз вносились изменения. Это не раскрывает содержание, но восстанавливает паттерн поведения, что часто бывает достаточно в сочетании с другими данными.
Почему Whonix и подобные решения снижают, но не убирают эту проблему полностью
Архитектура Whonix (Gateway + Workstation) решает конкретную проблему — утечку реального IP при компрометации браузера внутри гостевой системы. Но она не решает проблему форензики на уровне хоста, описанную выше. Если злоумышленник или следствие получает физический или удалённый доступ к самому хосту, а не к гостевой VM, вся изоляция внутри гипервизора не имеет значения — артефакты лежат снаружи периметра, который эта изоляция защищает.
Практические выводы, которые я считаю важными
Полнодисковое шифрование хост-системы (а не только гостевой VM) — это не опция, а необходимость, если в модели угроз есть физический доступ к устройству. Без этого все перечисленные файлы — снапшоты, page file, hiberfil.sys — лежат в открытом виде на хосте независимо от того, как защищена сама VM.
Отключение файла гибернации на хосте и настройка достаточного объёма RAM, чтобы избежать активного использования swap, снижает вероятность утечки фрагментов памяти гостевой системы на диск хоста.
Безопасное удаление снапшотов (с перезаписью, а не просто delete) обязательно, если снапшот содержал чувствительную сессию — иначе восстановление стандартными форензик-инструментами тривиально.
Live-системы вроде Tails в этом смысле архитектурно сильнее именно для разовых задач — они принципиально не создают персистентных файлов на хосте после завершения сессии, потому что вся система работает из RAM и не пишет состояние на диск. Это прямое архитектурное решение проблемы, которую виртуализация на постоянной основе не решает сама по себе.