Защита виртуальных машин#
Для снижения риска заражения ОС на хостах и гостевых ОС вредоносным ПО администратору виртуализации ОС SberLinux OS Server следует убедиться в максимальной безопасности ВМ.
Ниже приведены описания механизмов защиты ВМ на хосте и представлен список методов повышения их безопасности.
Принципы обеспечения безопасности виртуальных машин#
При использовании ВМ несколько ОС могут быть размещены на одном хосте. ОС связаны с хостом через гипервизор и виртуальную сеть. Каждая ВМ в данном случае может быть использована в качестве вектора для атаки на хост с помощью вредоносного ПО, а хост может быть использован в качестве вектора для атаки на любую из ВМ.
Поскольку гипервизор использует ядро хоста для управления ВМ, службы, работающие в ОС ВМ, часто используются для введения вредоносного кода в систему хоста. Тем не менее есть возможность защитить систему от таких угроз безопасности, используя ряд функций безопасности на хосте и гостевых ОС.
Функции безопасности, такие как SELinux или QEMU-sandbox, предоставляют различные меры, которые затрудняют атаку вредоносного кода на гипервизор и передачу данных между хостом и ВМ.
Многие функции, которые ОС SberLinux OS Server предоставляет для безопасности ВМ, всегда активны и не требуют включения или настройки. Подробную информацию об автоматических функциях обеспечения безопасности смотрите в разделе «Автоматические функции для обеспечения безопасности виртуальных машин».
Кроме того, следует придерживаться различных передовых практик, чтобы свести к минимуму уязвимость ВМ и гипервизора. Для получения дополнительной информации смотрите раздел «Лучшие практики по обеспечению безопасности виртуальных машин» ниже.
Лучшие практики по обеспечению безопасности виртуальных машин#
Следование приведенным ниже инструкциям значительно снижает риск заражения ВМ вредоносным кодом и использования их в качестве векторов атак для заражения хоста.
На стороне гостевой ОС – защитите ВМ так, как если бы это была физическая машина. Конкретные методы, доступные для повышения безопасности, зависят от выбранной пользователем гостевой ОС.
На стороне хоста:
При удаленном управлении ВМ используйте криптографические утилиты, такие как SSH, и сетевые протоколы, такие как SSL, для подключения к ВМ.
Используйте ВМ с SecureBoot.
Примечание
SecureBoot - это функция, которая гарантирует, что ВМ работает под управлением криптографически подписанной ОС. Это предотвращает загрузку ВМ, ОС которых была изменена в результате атаки вредоносного ПО.
SecureBoot можно использовать только при установке ВМ Linux, использующей прошивку OVMF. Для получения инструкций см. раздел «Создание виртуальной машины SecureBoot».
Не используйте команды
qemu-*, например,qemu-kvm.QEMU является важным компонентом архитектуры виртуализации в ОС SberLinux OS Server, но им трудно управлять вручную, а неправильные конфигурации QEMU могут вызвать уязвимости безопасности. Поэтому использование большинства команд
qemu-*не поддерживается ОС SberLinux OS Server. Вместо этого используйте утилитыlibvirt, такие, какvirsh,virt-installиvirt-xml, так как они организуют QEMU в соответствии с лучшими практиками.Примечание
Подробнее про утилиту
virshсм. раздел «Инструменты виртуализации».Важно
Утилита
qemu-imgподдерживается для управления образами виртуальных дисков.
Создание виртуальной машины SecureBoot#
Создание ВМ с гостевой ОС Linux, которая использует функцию SecureBoot, гарантирует, что ВМ будет работать под управлением криптографически подписанной ОС. Данная функция полезна, если гостевая ОС ВМ была изменена вредоносным ПО. В таком сценарии SecureBoot предотвращает загрузку ВМ, что останавливает потенциальное распространение вредоносного ПО на хосте.
Перед созданием ВМ убедитесь, что:
ВМ использует тип машины
Q35;архитектура хоста AMD64 или Intel 64;
установлен пакет
edk2-OVMF;Примечание
Если пакет
edk2-OVMFне установлен, установите его командой:dnf install edk2-ovmfисточник для установки ОС доступен локально или по сети. Форматы:
ISO-образ на установочном носителе;
Образ диска существующей ВМ.
Внимание
Установка с CD-ROM или DVD-ROM хоста в ОС SberLinux OS Server невозможна. Если выбрать CD-ROM или DVD-ROM в качестве источника установки при использовании любого метода установки ВМ, доступного в ОС SberLinux OS Server, установка завершится с ошибкой.
Примечание
Для более быстрой и простой настройки установки используйте файл Kickstart.
Для создания ВМ SecureBoot выполните следующий сценарий:
Создайте ВМ в соответствии с инструкциями в разделе «Создание виртуальных машин». Для опции
--bootиспользуйте значениеuefi,nvram_template=/usr/share/OVMF/OVMF_VARS.secboot.fd. В нем используются файлыOVMF_VARS.secboot.fdиOVMF_CODE.secboot.fdв качестве шаблонов для настроек неперемещаемой оперативной памяти (NVRAM) ВМ, что включает функцию SecureBoot:virt-install --name <example-vm> --memory 4096 --vcpus 4 --os-variant <os-variant> --boot uefi,nvram_template=/usr/share/OVMF/OVMF_VARS.secboot.fd --disk boot_order=2,size=10 --disk boot_order=1,device=cdrom,bus=scsi,path=/images/RHEL-9.0-installation.isoСледуйте процедуре установки ОС в соответствии с инструкциями на экране.
Для проверки сценария выполните следующие шаги:
После установки гостевой ОС получите доступ к командной строке ВМ, подключившись к гостевой ОС с помощью SSH.
Чтобы подтвердить, что SecureBoot был включен на ВМ, используйте команду:
mokutil --sb-stateПример вывода команды:
SecureBoot enabled
Ограничение действий пользователей виртуальных машин#
В некоторых случаях действия по умолчанию со стороны пользователей ВМ, размещенных на ОС SberLinux OS Server, могут представлять угрозу безопасности. Если это так, можно ограничить действия, доступные пользователям ВМ, настроив демоны libvirt для использования инструментов политики polkit на хосте.
Для ограничения действий пользователя ВМ выполните следующий сценарий:
Опционально. Убедитесь, что политики управления
polkitв ОС, связанные сlibvirt, настроены в соответствии с требованиями:Найдите все файлы, связанные с
libvirt, в каталогах/usr/share/polkit-1/actions/ и /usr/share/polkit-1/rules.d/:ls /usr/share/polkit-1/actions | grep libvirtls /usr/share/polkit-1/rules.d | grep libvirtОткройте файлы и просмотрите настройки правил.
Измените политику управления
libvirt:Создайте новый файл
.rulesв каталоге/etc/polkit-1/rules.d/.Добавьте пользовательские политики в данный файл и сохраните его.
Настройте ВМ для использования политик доступа, определенных
polkit:find /etc/libvirt/ -name virt*d.conf -exec sed -i 's/#access_drivers = \[ "polkit" \]/access_drivers = \[ "polkit" \]/g' {} +Команда ищет все файлы конфигурации драйверов виртуализации в каталоге
/etc/libvirt/.Раскомментируйте в найденных файлах строку
access_drivers = [ "polkit" ].Для каждого файла, который был изменен на предыдущем шаге, перезапустите соответствующую службу.
Примечание
Например, если изменения были для
/etc/libvirt/virtqemud.conf, перезапустите службуvirtqemud.systemctl try-restart virtqemud
Для проверки сценария от имени пользователя ВМ, действия которого необходимо было ограничить, попробуйте выполнить одно из ограниченных действий. Например, если непривилегированным пользователям запрещено просматривать ВМ, созданные в системном сеансе, проверьте это командой:
virsh -c qemu:///system list --all
Пример вывода команды:
Id Name State
-------------------------------
Если в выводе команды не перечислены ВМ, когда в системе существует одна или несколько ВМ, polkit успешно ограничивает действие для непривилегированных пользователей.
Информацию о политиках контроля доступа polkit можно получить в документации libvirt.
Автоматические функции для обеспечения безопасности виртуальных машин#
В дополнение к ручным средствам повышения безопасности ВМ ряд функций безопасности предоставляется пакетом программного обеспечения libvirt и автоматически включается при использовании виртуализации в ОС SberLinux OS Server.
К таким функциям относятся:
Системные и сессионные подключения.
Чтобы получить доступ ко всем доступным утилитам для управления ВМ в ОС SberLinux OS Server, необходимо использовать системное подключение
libvirt–qemu:///system. Для этого у пользователя должны быть административные полномочия (например,root) в системе или он должен быть частью группы пользователейlibvirt.Пользователи без административных полномочий, не относящиеся к группе
libvirt, могут получить доступ только к сессионному подключениюlibvirt–qemu:///session, которое должно соответствовать правам доступа локального пользователя при доступе к ресурсам. Например, используя сессионное соединение, пользователь не сможет обнаружить или получить доступ к ВМ, созданным в системном соединении или другими пользователями. Кроме того, доступные варианты конфигурации сети ВМ значительно ограничены.Важно
Документация ОС SberLinux OS Server подразумевает, что у пользователя есть привилегии для системного подключения
libvirt.Изоляция ВМ.
Отдельные ВМ работают как изолированные процессы на хосте и полагаются на безопасность, обеспечиваемую ядром хоста. ВМ в данном случае не может читать или получать доступ к памяти или хранилищу других ВМ на том же хосте.
QEMU-sandbox.
Функция, не позволяющая коду QEMU выполнять системные вызовы, которые могут поставить под угрозу безопасность хоста.
Рандомизация адресного пространства ядра (KASLR).
Позволяет случайным образом определять физические и виртуальные адреса, по которым распаковывается образ ядра. Таким образом, KASLR предотвращает гостевые эксплойты безопасности на основе расположения объектов ядра.