Параметры VMX или защита ВМ

Этот перевод навеян шикарной статьей от Robert Patton, посвященной параметрам VMX-файлов виртуальных машин, предназначенным для устранения определенных уязвимостей. Как водится, перевод пристрастный 🙂

Если вы немного работали с продуктами VMware, вы, наверное, обратили внимание на VMX файлы. Каждый VMX содержит почти все настройки виртуальной машины, а также имеет несколько дополнительных настроек, которые нельзя добавить из графического интерфейса, а можно только с помощью редактора из консоли. В этом руководстве я опишу несколько параметров, призванных защитить вас от уязвимостей в VMware Tools и прикрыть каналы между гостевой ОС и хостом.
Параметры, о которых мы будем говорить, уже не раз встречались в различных источниках. Но почти нет информации о том, что именно они делают и для чего предназначены. Многие из этих параметров неприменимы к ESX 3,5. Поэтому, вместо того, чтобы опубликовать очередной список, я попытаюсь объяснить предназначение этих параметров. Даже если вы и не собираетесь заняться увеличением безопасности, продолжите чтение, и, может быть, мы откроем вам глаза на дыры в безопасности вашей инфраструктуры.
Мне нравится использовать связку PUTTY и VI для редактирования VMX файлов. Просто скопируйте в буфер список параметров в конце статьи, откройте VMX файл в VI и нажмите правую кнопку мыши в режиме вставки текста для того, чтобы вставить текст. Если же вы не знакомы с интерфейсом VI, то в самом конце статьи будет краткая справка по нему.
Также вы можете добавить эти параметры через VI Client, нажав правой кнопкой мыши на названии ВМ, выбрав пункт Edit Settings…, вкладку Options, Advanced – General, и нажав кнопку Configuration Parameters… Но, в сущности, это гораздо дольше делать, чем использовать VI. Вне зависимости от метода редактирования VMX файла, вам необходимо выключить ВМ. Если вы что-то изменяете в VMX файле, то после выключения ВМ эти изменения удалятся, так как во время работы ВМ все параметры VMX загружены в оперативную память хоста.

Вам действительно необходимо увидеть уязвимости VMware Tools для того, чтобы представить область их действия. Для демонстрации уязвимостей мы возьмем свежую ВМ с установленной ОС Windows Server 2003 Standard и установленными VMware Tools. Создадим локального пользователя testuser, и добавим его в группу Remote Desktop Users. Соответственно, наш пользователь будет членом групп Users и Remote Desktop Users на этом сервере. Заметьте, он не является локальным администратором. 😉 По сути дела, это типичный аккаунт для использования Citrix или же терминальных серверов Microsoft.
Если вы думаете, что вы защищены, потому что в правом нижнем углу нет значка VMware Tools, то вы ошибаетесь. Любой пользователь может запустить его с помощью команды “C:\Program Files\VMware\VMware Tools\VMControlPanel.cpl”.
Отключение устройств
Начнем мы с обзора возможностей по подключению и отключению CD-ROM, FDD и сети из панели управления VMware Tools. Создайте RDP сессию к нашему тестовому серверу и войдите в систему под именем testuser. Кликните по значку VMware Tools и перейдите на закладку Devices. Снимите флаг рядом с сетевой платой и нажмите кнопку Apply. Вы можете наблюдать, как ваша RDP сессия повисла, а сервер не отвечает на запросы. Да-да, обычный пользователь только что выдрал с корнем провод из виртуальной сетевой платы, полностью отключив сервер от сети. Если у вас уже есть терминальные сервера, вы можете себе представить масштабы этой угрозы.
К счастью для нас, это легко отключается с помощью следующих параметров VMX файла:
isolation.device.connectable.disable = “true”
isolation.device.edit.disable = “true”
Угрозы времени
Давайте снова создадим RDP сессию и откроем панель VMware Tools. На вкладке Options снимем флаг Time synchronization between the virtual machine and the host operating system. Нажмем Apply и Ok. Закройте и снова откройте панель VMware Tools – вы увидите, что эти изменения сохраненились.
Конечно, если вы используете службу W32Time, вы можете сказать, что это все ерунда. Но когда злобный пользователь включит синхронизацию времени с хостом, вы получите два процесса синхронизации времени, не знающих друг о друге. А если у вас отключена синхронизация времени через W32Time и пользователь отключит\включит синхронизацию времени с хостом, то, возможно, ВМ не сможет авторизоваться в домене.
Этот флаг меняет параметр в VMX файле – tools.syncTime. Соответственно, следующий параметр запрещает изменение этого параметра:
isolation.tools.setOption.disable = “true”
Даже если вы снимете/поставите флаг и нажмете Apply, а затем Ok, после перезапуска панели VMware Tools, вы увидите, что параметр не изменился.
Подождите секунду…
Я было поставил точку в этой статье, но старый-старый скрипт снова изменил параметр синхронизации. Мог ли непривилегированный пользователь сделать это? Я «вспомнил» команду C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd “vmx.set_option synctime 0 1” и запустил ее из сеанса testuser и без включенного параметра set.Option.disable мне удалось включить синхронизацию времени с хостом.
Хмм, set_option сильно похоже на параметр setOption.disable. Давайте почитаем справку командной строки – VMwareService.exe –help
Usage: c:\Program Files\VMware\VMware Tools\VMwareService.exe {-v,-i,-u,-kill,-cmd ““}
Да уж, не особенно понятнее стало. Немного информации есть в SDK, но недостаточно для понимания сути. В конце концов, я скачал исходный код VMware Tools и начал рыться в нем. После долгих трудов я нашел несколько процедур, которые можно отнести к уязвимостям. Следующая команда позволит вам писать в лог ВМ определенный текст:
C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd “log %string %string”
А эта позволит создать переменную типа Guestinfo для хранения информации о виртуальной машине в памяти ESX-сервера:
C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd “info-set guestinfo.%variable %string”
Ну и чтение из переменной GuestInfo:
C:\Program Files\VMware\VMware Tools\VMwareService.exe -cmd “info-get guestinfo.%variable”
Обратите внимание на то, что эти переменные не хранятся постоянно. Они запоминают состояние при перезагрузке ВМ, но если вы ее выключаете, то они стираются.
Эта информация имеется в руководстве “VI3 Security Hardening” в разделе “Limit Data Flow from the Virtual Machine to the Datastore”. И, конечно, все команды может выполнить непривилегированный пользователь.
Закрываем дыры
Для проверки использования этих дыр я написал несколько скриптов и запустил их от имени testuser. Для спам-атаки на лог-файлы сервера ESX я пытался записать 1KB данных в цикле, повторявшемся миллион раз. Я наблюдал за ростом файла логов и обнаружил, что как только он разрастается до размера в 1МБ, рост прекращается. Расследование показало, что в конце лога имеется сообщение “Log Throttled” (журнал прерван). Это хороший знак, значит, VMware установило ограничение на рост размера файлов. Но я предпочитаю, чтобы вообще не было возможности воспользоваться этой уязвимостью, поэтому использую следующую команду:
isolation.tools.log.disable = “true”
УРА. Теперь использование этой дыры стало невозможным, зато продолжается запись журналов в файл vmware.log, который можно использовать при наличии проблем с ВМ.
После этого я попробовал забросать ОЗУ сервера ненужными значениями переменной. Выяснилось, что на одну ВМ разрешено хранить до 32 двух переменных, на каждую выделяется до 32КБ данных. В результате, с помощью этой уязвимости разрешаено записать в память до 1МБ данных.
Руководство “VI3 Security Hardening” предлагает два способа для закрытия этой дыры. Например, мы можем отключить создание переменных GuestInfo с помощью команды isolation.tools.setInfo.disable = “true”.
Но я не могу с чистым сердцем рекомендовать эту директиву, ведь после этого ВМ не сможет сообщить хосту свой ip-адрес и dns имя. Нет гарантий, что VCB или приложения других компаний продолжат работу. Зато мы можем ограничить размер, выделяемый под хранение переменных GuestInfo с помощью другой команды – tools.setInfo.sizeLimit = “some # in bytes”.
Вообще говоря, 1МБ – достаточно важная цифра. Если вы можете жить без данных об ip или dns – лучше отключить использование переменных GuestInfo. Так как могут возникнуть проблемы с использованием, я убрал эту рекомендацию из списка команд в конце статьи.
Уменьшение диска ВМ
Давайте снова откроем панель VMware Tools и перейдем на вкладку Shrink. Я не буду объяснять, зачем нужна эта операция. Почему-то компания VMware решила, что эти опции должны быть доступны любому пользователю, даже не администратору. Когда выполняется операция Shrink, процессор ВМ загружается почти на 100% и ВМ перестает отвечать на запросы. Операция Shrink не запустится, если у пользователя нет прав на запись в корневой каталог того логического диска, который он будет уменьшать.
Но если другой администратор или приложение предоставит доступ на запись в корневой каталог диска группе Users или Everyone, то вы попали…
Если вы не используете Shrink в своей инфраструктуре, то можно устранить эту уязвимость с помощью следующих команд:
isolation.tools.diskWiper.disable = “true”
isolation.tools.diskShrink.disable = “true”
Угроза PXE
Я столкнулся с этой уязвимостью, когда разбирался с одной проблемой, связанной с SAN. Сервера ESX внезапно отключились от iSCSI лунов, и, когда мы открыли консольное подключение к ВМ, мы были удивлены увиденным. Все ВМ были запущены, но автоматически перезагрузились, когда пропал жесткий диск. Так как VMX файлы находились в оперативной памяти, то ESX-сервера не обратили внимания на то, что луны с дисками пропали. Соответственно, ВМ проверили все источники загрузки и запустились с PXE-сервера.
Обдумав ситуацию, я решил, что это может быть страшной атакой. Если кто-то сможет подключиться к PXE-серверу в сети и запустить DoS-атаку на сеть iSCSI, они смогут перезапустить ВМ со своими образами ОС, в которых будут все необходимые им инструменты для дальнейшего взлома сети. К счастью, загрузку по PXE через сетевые адаптеры vlance и vmxnet легко отключить:
vlance.noOprom = “true”
vmxnet.noOprom = “true”
Если вы используете адаптер e1000 для виртуальных машин, придется использовать другой метод для отключения загрузки по PXE, так как нет опции .noOprom для этого адаптера. Следующая команда уменьшит объем памяти, который выделяет BIOS для загрузки. Заметьте, это настройка на определенную сетевую карту:
ethernet0.opromsize = “0”
Запрет общего буфера
Чтобы предотвратить возможность утечки конфиденциальной информации, например, паролей, из буфера обмена vClient в буфер обмена ВМ, желательно запретить возможность использования совместного буфера и операций copy/paste. Это легко сделать, и это не должно принести серьезных проблем, если вы не используете vClient для повсеместной работы с ВМ.
isolation.tools.copy.disable = “true”
isolation.tools.paste.disable = “true”
Часто встречается еще и третья команда – isolation.tools.setGUIOptions.enable = “false”, но я не смог найти никакой документации по этой команде. Другая интересная? вещь в том, что иногда в контексте она пишется как Gui, с заглавной G. Также есть команда isolation.tools.setGUIOptions.disable, но и для нее я не нашел документации. Также я не нашел разницы в работе при использовании параметров true или false. Давайте все же добавим его в список наших команд, потому что он есть в некоторых руководствах и документах и вроде бы ни на что не влияет.
isolation.tools.setGUIOptions.enable = “false”
Журналы – это наше все
Последний набор параметров, который мы рассмотрим, относятся к файлам логов ВМ – vmware.log. Мы уже сталкивались с тем, как этот файл может быть испорчен с помощью уязвимости, но есть еще одна уязвимость. Я столкнулся с этой проблемой лицом к лицу. У нас была ВМ, не подающая никаких признаков беспокойства, но VCB бэкап которой падал каждый вечер. К счастью, мы использовали VCB Wrangler для управления нашими бэкапами; скрипт, который по расписанию запускал vcbmounter.exe, а затем отправлял результат выполнения бэкапа и список скопированных файлов на почту. Расследуя проблему с бэкапами, мы обнаружили, что лог-файлы vmware-####.log достигли значения 7000. Используя в SSH сессии команду ls –la в каталоге ВМ, мы увидели, что лог-файлы были созданы в течение часа. Какой-то процесс вызывал активную запись в журнал логов, к счастью, мы уже использовали следующие команды:
log.rotateSize = “100000” (предельный размер файла логов)
log.keepOld = “10” (количество логов для хранения)
Если бы этих команд не было, файлы логов заняли бы все свободное место и вызвали сбой с неизвестной причиной.
Тест-тест-тест 🙂
Если вы сделали эти изменения в VMX, и тестируете их на ВМ, то могли заметить, что на вкладке Options в панели VMware Tools по прежнему есть две опции, позволяющие непривилегированному пользователю изменять и сохранять Show VMware Tools in the taskbar и Notify if update is available. Эти параметры хранятся в реестре в ветке HKEY_CURRENT_USER, и хранятся отдельно для каждой учетной записи. Так как это не глобальные параметры, то их можно проигнорировать, ведь непривилегированный пользователь не сможет обновить VMware Tools. Также я слышал совет по ограничению через NTFS прав на каталог C:\Program Files\VMware\VMware Tools. У VMware на эту тему есть статья в базе знаний. Основная проблема заключается в том, что если пользователь где-то раздобудет VMControlPanel.cpl или VMwareService.exe и скопирует их на рабочий стол, то он будет в состоянии использовать панель VMware Tools. Если хотите, то можете это проверить 🙂

Вот список изменений, рекомендованных к внедрению. Если вы займетесь самостоятельным поиском, то обнаружите, что есть много дополнительных параметров, которые здесь не указаны, некоторые из них настоятельно рекомендуются к использованию. Но я рекомендую вам тщательнейшим образом проверять параметры, отсутствующие в этом списке, прежде чем вы добавите их в производственную среду. Все параметры из этой статьи, за исключением isolation.tools.setOption.disable, vlance.noOprom, и vmxnet.noOprom, рекомендуются в документе “VI3 Security Hardening”.
Долгожданный список 🙂
isolation.device.connectable.disable = “true”
isolation.device.edit.disable = “true”
isolation.tools.setOption.disable = “true”
isolation.tools.log.disable = “true”
isolation.tools.diskWiper.disable = “true”
isolation.tools.diskShrink.disable = “true”
isolation.tools.copy.disable = “true”
isolation.tools.paste.disable = “true”
isolation.tools.setGUIOptions.enable = “false”
log.rotateSize = “100000”
log.keepOld = “10”
vlance.noOprom = “true”
vmxnet.noOprom = “true”

# PXE boot on the e1000 vNIC can be disabled with this directive:
ethernet0.opromsize = “0”

А теперь обещанное howto по VI
Это коротенькая вводная по VI для тех, кто еще не открыл для себя великий потенциал этого редактора. Откройте SSH сессию к вашему ESX серверу и наберите VI в командной строке. Если вы нажмете в окне редактора i, то увидите надпись —INSERT— в левом нижнем углу. Наберите любой текст, а затем нажмите Esc – надпись пропадет, а текст перестанет печататься в файл. VI имеет два режима: режим ввода команд и режим ввода текста, после нажатия клавиши Esc вы попадаете в режим ввода команд. Для ввода текста в формате wysiwyg просто нажмите i и вы увидите надпись —INSERT—.
Ну и напоследок – сохранение документов.
:wq – сохранение документа;
:q! – выход без сохранения.
Перед редактированием VMX-файла убедитесь, что ВМ выключена и сделайте ее резервную копию с помощью
cp /vmfs/volumes/somevolume/somevm/somevm.vmx /root
Для редактирования VMX используйте
vi /vmfs/volumes/somevolume/somevm/somevm.vm