Автоматизация тестовой среды: создание идеального «одноразового» ПК
Идеальный ПК для тестирования подозрительного программного обеспечения — это машина, где ошибки не влекут за собой последствий. На текущий момент Windows Sandbox обеспечивает быструю изоляцию, запускаясь за секунды на базе текущей сборки ОС, однако она всегда предоставляет базовую, не настроенную среду. Конфигурационные файлы .wsb позволяют сопоставлять папки или запускать команды при старте, но они не сохраняют установленные интерактивно приложения для следующих сеансов. Как только возникает потребность в использовании нескольких инструментов постоянно, процесс пересборки окружения становится крайне неудобным, что вынуждает прибегать к снимкам (снапшотам) VMware.
Ограничения существующих решений
Снимки VMware позволяют сохранить уже настроенную машину, но их главный недостаток заключается в человеческом факторе: необходимо помнить о необходимости восстановления нужного состояния после работы. Если забыть сделать снапшот перед началом тестирования, вся защита сводится на нет. Я искал решение, которое объединило бы полезные черты обоих подходов: полноценный ПК с Windows 11, уже загруженный необходимыми инструментами, который очищается автоматически при каждом выключении.
Создание виртуальной машины DISPOSABLE-PC
Чтобы решить задачу окончательно, я создал виртуальную машину на базе Windows 11 25H2 Pro под названием DISPOSABLE-PC, использовав для лицензирования запасной ключ. Конфигурация получила 8 ГБ оперативной памяти, четыре vCPU и динамически выделяемый виртуальный диск на 80 ГБ. В процессе установки я создал локальную учетную запись (выбрав настройку «для работы или учебы» с опцией «Присоединиться к домену» на этапе входа) и установил необходимый софт: VMware Tools, 7-Zip, Notepad++, Process Explorer и Wireshark.
Перед тем как «заморозить» диск, я создал постоянный маркер командой New-Item C:\Baseline -ItemType Directory «PERMANENT BASELINE» | Set-Content C:\Baseline\BASELINE.txt. Этот файл с временной меткой стал доказательством того, что система успешно возвращается в исходное состояние после любого «одноразового» сеанса.
Настройка независимого энергонезависимого режима (Independent-Nonpersistent)
Для реализации задуманного я воспользовался функцией VMware Workstation под названием «Independent-Nonpersistent» (Независимый-энергонезависимый режим). Это позволило фиксировать базовую конфигурацию, не создавая классических снапшотов. Перед активацией режима я зафиксировал SHA-256 хеш файла VMDK с помощью команды Get-FileHash «C:\VM\Disposable Windows 11\Windows 11 x64.vmdk» -Algorithm SHA256 на хост-машине. Убедившись, что Snapshot Manager пуст (важный шаг, чтобы доказать, что сброс происходит автоматически, а не через скрытые снапшоты), я перевел настройки диска в режим «Independent» и выбрал «Nonpersistent».
Изменения зафиксировались в конфигурационном файле VMX: nvme0:0.mode = «independent-nonpersistent». При следующей загрузке VMware создала файл Windows 11 x64.vmdk.REDO_a40316. Теперь исходный VMDK выступает как диск для чтения, а все новые операции записи перенаправляются во временный redo-файл. После осмотра файлов стало ясно: redo-слой занимал всего 10 МБ при оригинальном диске объемом 26 ГБ. Примечательно, что этот метод не является снапшотом, так как независимые диски исключены из системы снимков VMware.
Нюансы эксплуатации и обслуживание
Данный подход обладает одним важным требованием к обслуживанию: «замороженный» диск необходимо рассматривать как «золотой образ». Для установки обновлений Windows его нужно переводить обратно в обычный режим, а после проверки — снова возвращать в состояние «nonpersistent».
Для подтверждения эффективности я подверг сеанс пяти различным способам «загрязнения»: редактировал реестр, создавал файлы, устанавливал приложения, менял историю браузера и персонализацию. Режим Independent-Nonpersistent гарантирует, что любое выключение стирает все изменения, возвращая виртуальный диск в исходное состояние байт-в-байт.
Справка о продукте:
VMware Workstation Pro — настольный гипервизор для запуска Windows, Linux и других ОС как изолированных ВМ. Включает функции снимков, клонирования, расширенной сетевой настройки, шифрования, vTPM и Secure Boot. Разработчик: VMware (часть Broadcom). Модель распространения: бесплатно для личного и образовательного использования. Версия: 261. Поддерживает 64-битные системы Windows и Linux, а также процессоры Intel и AMD x86/x86-64.
Проверка системы на устойчивость и настройка сетевой изоляции
Для начала проверки я создал тестовую директорию и маркер внутри неё, а также разместил дополнительный файл на рабочем столе с помощью PowerShell: New-Item C:\Session-Test -ItemType Directory «This file should disappear» | Set-Content C:\Session-Test\THIS-SHOULD-DISAPPEAR.txt «Erase me too!!» | Set-Content «$HOME\Desktop\Temporary session.txt». Ради визуальной проверки я заменил стандартные обои Windows на максимально неприятный красный фон в MS Paint с надписью «TEMPORARY SESSION». После этого я установил медиаплеер VLC через Winget и запустил его вручную.
Менее заметные, но не менее важные изменения также были внесены: в реестре по пути HKCU\Software\DisposablePC-Test я добавил ключ SessionStatus = THIS SHOULD DISAPPEAR. В завершение я посетил сайты example.com и wikipedia.org через браузер Edge, чтобы запись о них сохранилась в локальной истории.
Реакция на перезагрузку и выключение
Существовало мнение, что перезагрузка виртуальной машины Windows через меню «Пуск» сохраняет внесенные изменения. Это крайне полезная функция, так как многие установщики требуют перезапуска системы. Чтобы убедиться, что изменения не пропадут преждевременно, я провел тест. После перезагрузки Windows выяснилось, что VMware, имитируя реальный ПК, не отключала питание виртуальной машины, из-за чего файл изменений (redo-файл) оставался подключенным. Все внесенные правки сохранились: обои остались прежними, VLC запускался, а файлы, история браузера и ключи реестра были на месте.
Затем я выполнил полное завершение работы через меню «Пуск > Питание > Завершение работы». В этот момент VMware Workstation удалила слой изменений (redo-файл). При следующей загрузке восстановились исходные статические обои и инструменты тестирования. Плеер VLC, временные файлы, ключи реестра и история посещений Edge исчезли. Самое важное для теста: файл C:\Baseline\BASELINE.txt остался нетронутым. Виртуальная машина Windows успешно сохранила базовую конфигурацию, отбросив всё, что было сделано после.
Сетевая безопасность и управление доступом
VMware позволяет гибко настраивать параметры подключения «одноразового» ПК. Если работа с дисками обеспечивает локальную изоляцию, то виртуальная сеть VMware отвечает за взаимодействие с внешним миром. Я использовал NAT, так как мне требовался доступ в интернет для обновлений и загрузки приложений. Это предотвратило превращение ВМ в независимо доступный узел в моей физической сети, хотя она всё еще могла «видеть» устройства в локальной сети.
В отличие от Windows Sandbox, VMware предлагает больше альтернатив:
- Bridged: размещение ВМ напрямую в физической сети через адаптер хоста.
- Host-only без виртуального адаптера: для взаимодействия ВМ между собой.
- Host-only с виртуальным адаптером: для связи ВМ с хостом.
Если приложению больше не нужен интернет, достаточно снять галочку Connected в настройках, что эквивалентно физическому отключению кабеля Ethernet. Для простых тестов Windows Sandbox позволяет включать и выключать сеть, но топологии VMware гораздо полезнее, когда «одноразовый» ПК нужно интегрировать в домашнюю лабораторию или связать с другой ВМ. Дополнительно я отключил общие папки, перетаскивание файлов (drag-and-drop), буфер обмена и автоматическое подключение USB. Эти настройки находятся вне защиты энергонезависимого VMDK, поэтому их необходимо блокировать принудительно, несмотря на потерю удобства.
Ограничения и выводы по безопасности
Автоматический сброс удобен, но это не «непробиваемая тюрьма» для вредоносного ПО. Моя базовая ВМ занимает около 25 ГБ на диске и использует 8 ГБ оперативной памяти хоста, а её подготовка занимает гораздо больше времени, чем сессия в Windows Sandbox. Любые обновления, установленные в режиме без сохранения данных, также исчезнут, поэтому для обслуживания системы нужно временно переводить диск в режим записи, обновлять ПО и «замораживать» его снова.
Границы защиты ограничены файлом VMDK. Вредоносное ПО может атаковать VMware Tools, попытаться совершить побег из виртуальной машины или атаковать устройства в сети. Данные, скопированные в общую папку, буфер обмена или на USB-накопитель, сохранятся на хосте, хотя отключение этих интеграций значительно снижает риск. Для повторяемых тестов программного обеспечения и настроек такая конфигурация ВМ подходит мне гораздо лучше других решений. Стоит отметить, что возможность создания энергонезависимых дисков есть не только у VMware — аналогичную функцию предлагают «иммутабельные» диски в VirtualBox. Windows Sandbox остается моим выбором для проверки одного неизвестного файла, а снимки состояния (snapshots) предпочтительнее, когда нужно иметь несколько точек восстановления. При этом рассматриваемый метод идеален: перезагрузка гостевой системы сохраняет сессию, а полное выключение — автоматически её очищает.
Итоги проверки целостности виртуальной машины
Финальный хеш SHA-256 полностью совпал с базовым значением, которое было зафиксировано мною до начала тестирования. Этот факт доказывает, что состояние виртуальной машины не просто выглядело восстановленным, а системный виртуальный диск (vDisk) вернулся к исходному состоянию побайтово.
Дальнейшее использование и рекомендации
В дальнейшем я планирую использовать данную виртуальную машину для выполнения разовых задач, связанных с тестированием ПО и веб-серфингом. Однако я серьезно рассмотрю возможность перехода на специализированные онлайн-платформы, такие как Hybrid Analysis. Подобные ресурсы позволяют проводить запуск вредоносного программного обеспечения в по-настоящему изолированной среде.
