Инструкция по созданию полностью зашифрованного образа гостевой системы, в котором шифрование охватывает корневой раздел и стадию загрузки.Извлекаем содержимое корневого раздела образа виртуальной машины, который требуется зашифровать, в tar-архив vm_root.tar. Проверяем, чтобы в образе были необходимые для шифрования и EFI-загрузки разделов утилиты, такие как cryptodisk и grub-efi.
Создаём файл с дисковым образом, содержащим два раздела - небольшой раздел для EFI (p1, 100МБ) и корневой раздел, содержимое которого будет зашифровано (p2).
truncate -s 4GB disk.img
parted disk.img mklabel gpt
parted disk.img mkpart primary 1Mib 100Mib
parted disk.img mkpart primary 100Mib 100%
parted disk.img set 1 esp on
parted disk.img set 1 boot onНастраиваем EFI на первом разделе и дисковое шифрование LUKS на втором. Для повышения защищённости можно заполнить шифрованный раздел случайными числами, но это приведёт к увеличению размера итогового образа qcow2. Создаём на шифрованном разделе ФС Ext4.
привязываем образ к loop-устройству
losetup -P -f disk.img
определяем имя созданного устройства (/dev/loopN), в дальнейшем используем переменную $l вместо устройства
l=($(losetup -l|grep disk.img))
создаём раздел с EFI, используем VFAT
mkfs.vfat ${l}p1
определяем UUID раздела EFI
blkid ${l}p1
создаём шифрованный раздел, в процессе задаём временный пароль для расшифровки
cryptsetup --type luks1 luksFormat ${l}p2
определяем UUID шифрованного раздела
blkid ${l}p2
активируем шифрованный раздел и создаём на нём ФС ext4
cryptsetup luksOpen ${l}p2 cr_root
mkfs.ext4 /dev/mapper/cr_rootмонтируем раздел, копируем в него содержимое tar-архива с начинкой корневого раздела и создаём каталоги для точек монтирования /run, /sys, /proc и /dev.
mount /dev/mapper/cr_root /mnt
tar -C /mnt -xpf vm_root.tar
for m in run sys proc dev; do mount --bind /$m /mnt/$m; doneвходим в окружение созданного корневого раздела
chroot /mnt
В /etc/fstab определяем метку корневого раздела (/dev/disk/cr_root) и раздела EFI (/boot/efi).
Настраиваем и устанавливаем загрузчик GRUB (в некоторых дистрибутивах вместо /boot/grub используется /boot/grub2, а вместо префикса "grub" - "grub2-"):
echo "GRUB_ENABLE_CRYPTODISK=y" >> /etc/default/grub
mount /boot/efi
grub-install --removable --target=x86_64-efi
grub-mkconfig -o /boot/grub/grub.cfgДля систем с mkinitramfs (Debian) дополнительно нужно добавить параметры шифрованного раздела в /etc/crypttab:
cr_root UUID=<uuid> luks none
После чего пересоздаём образ ram-диска с компонентами для начальной загрузки.
Для систем с dracut требуется изменить настройки /etc/default/grub, указав в GRUB_CMDLINE_LINUX привязку rd.luks.uuid=<UUID>. Для дистрибутивов с SELinux также нужно [[https://wiki.centos.org/HowTos/SELinux обновить метки]] (relabel).Отмонтируем созданные в процессе подготовки образа разделы из /mnt и пытаемся загрузить образ, используя режим EFI. В процессе загрузки вводим заданный ранее временный пароль и проверяем работоспособность окружения.
Заменяем временный пароль на ключ для быстрой загрузки и настраиваем ram-диск для его использования. Для образа, примонтированного через /dev/sda:
dd if=/dev/urandom bs=1 count=33|base64 -w 0 > /etc/cryptsetup-keys.d/luks-<UUID>.key
chmod 600 /etc/cryptsetup-keys.d/luks-<UUID>.key
cryptsetup --key-slot 1 luksAddKey /dev/sda2 # первичный ключ для восстановления
cryptsetup --key-slot 0 luksRemoveKey /dev/sda2 # удаляем временный ключ
cryptsetup --key-slot 0 --iter-time 1 luksAddKey /dev/sda2 /etc/cryptsetup-keys.d/luks-<UUID>.keyУказание опции "-w 0" в dd необходимо для того, чтобы исключить появление в пароле символа перевода строки.
Для систем с mkinitramfs теперь нужно изменить настройки /etc/crypttab, указав путь к сгенерированному ключу:
cr_root UUID=<UUID> /etc/cryptsetup-keys.d/luks-<UUID>.key luks
Для систем с dracut необходимо добавить hook ключа в /etc/dracut.conf.d, а для Debian также потребуется указать маску определения файла с ключом:
cryptodisk.conf
install_items+=" /etc/cryptsetup-keys.d/* "echo "KEYFILE_PATTERN=\"/etc/cryptsetup-keys.d/*\"" >>/etc/cryptsetup-initramfs/conf-hook
Теперь можно перегенерировать образ RAM-диска начальной загрузки. После попытки загрузки пароль будет спрошен один раз только на стадии запуска GRUB и на последующих стадиях загрузки запрашиваться не будет.
URL: https://blog.hansenpartnership.com/building-encrypted-images.../
Обсуждается: http://www.opennet.dev/tips/info/3169.shtml
В наше время это очень полезное руководство, особенно в России.
То есть, если спи...т диск, то ключик уже в комплекте?
/etc/cryptsetup-keys.d/luks-<UUID>.key
Видимо /etc/cryptsetup-keys.d должен быть симлинком на юсб-флешку, а еще лучше примонтированным сетевым устройством :)
Это вообще видимо не для сокрытия данных, а скорее для контроля целостности загружаемого образа или я не понял нафига козе баян.
угу, в комплекте. Лежит на зашифрованном разделе внутри образа. Без прав рута в работающей виртуалке доступ к нему получить затруднительно.ключик нужен чтобы запихнуть его в initrd и пароль дважды не вводить. Можно /boot сделать отдельным, а в initrd запихнуть dropbear, тогда разлочивать можно будет по ссх. Правда если совсем параноить, то надо проверять, что незашифрованная часть не менялась.
> угу, в комплекте. Лежит на зашифрованном разделе внутри образа.Залью себя бетоном, попробуй найди.
> Без прав рута ...
Я диск спёр, я - бог, чо мне твой рут!?
> и пароль дважды не вводить.
А, то есть они ещё и одинаковые? )))
> ключик нужен чтобы запихнуть его в initrd
Тя научить разбирать initrd?
Боги секурити собрались! )
> Я диск спёр, я - бог, чо мне твой рут!?и ключ внутри зашифрованного файла. Виртуалку без пароля ты не запустишь
> Тя научить разбирать initrd?
разбирать initrd я умею, а ты научись сначала initrd вытаскивать из LUKS без пароля и ключа.
Еще раз:
1. товарищ шифрует раздел внутри образа диска
2. для того, чтобы запустить виртуалку этот раздел надо расшифровать дважды: это делает груб, чтобы отыскать initrd и ядро, а затем ядро, чтобы смонтировать корень
3. для того, чтобы убрать второй запрос пароля добавляется ключ, который может быть каким угодно, даже одинаковым с паролем.
3.1 ключ лежит на зашифрованном разделе внутри образа. Т.е. без расшифровки ты его не получишь.
3.2 ключ добавляется в initrd, который тоже лежит на зашифрованном разделе внутри образа. Т.е. без расшифровки ты его не получишь.ключей и паролей вне зашифрованных файлов на сервере не хранится (разве что кто-то ССЗБ), если ты спер диск, то тебе надо расшифровать все, чтобы получить ключи.
Лучше не вынивать диск, а подменить груб или просканировать память виртуалки
А что из них лучше luks1 или luks2 ?
Насколько я понял, luks2 отличается от luks1 новым форматом заголовка (header).
Так, слоты для ключей (keyslot) переведены в json формат, и убрано ограничение на их количество (в luks1 не более 7, в luks2 по умолчанию 32).
Также добавлены новые алгоритмы (Argon2i и Argon2id) кодирования парольной фразы (passphrase | keyfile) основной смысл которых - повысить время перебора (bruteforce) для атакующей стороны.
В заголовке теперь хранится резервная копия слотов.
Из-за этого размер заголовка увеличился с 2 до 16 MiB, и теперь имеет плавающий (в большую сторону) размер.
В плане шифрования данных они идентичны.
Вот тут некоторые подробности:
gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
Чуть менее очевидная разница в том, что на данный момент многим программам, например grub2, о luks2 известно менее, чем о luks1, как следствие не все фишки работающие с первым можно повторить со вторым. Например, шифрованный /boot.
В grub 2.0.4 завезли поддержку LUKS2.
Автор забыл во вводной части указать кейсы его подхода с общим описанием идеи, а вычленять это из простыни не охота.
Для страждущих рекомендую эту серию материалов: wiki.archlinux.org/index.php/dm-cryptзы
в простыне виднеется ошибка для /etc/crypttab:
cr_root UUID=<uuid> luks none
последние два слова нужно поменять местами.
А в чем плюс шифрования каждого гостя, кроме большей секурности за счет разных ключей?
плюс в размере. Бэкапы гостей теперь несжимаемые.
> плюс в размере. Бэкапы гостей теперь несжимаемые.Сомневаюсь, что это плюс..
Представьте, что у вас 23 личности. И каждая хочет себе зашифрованную виртуалку...
отличная статья, но много осталось за кадром -- например, внедрение ключа в initrd для centos. Я уже написал альтернативный скрипт, для более бездумного копипастинга. На выходе VMDK для загрузки шифрованной VM в режиме UEFI. Протестировано в vmware.
P.S. Интересно, присутствует ли угроза подмены EFI файлов ( они на незашифрованном разделе ) и установки keylogger'a? Или там все подписано и их нет смысла менять?
А нахрена все это? Установщики перестали поддерживать шифрование при установке?
Debootstrap никогда его и не поддерживал, а я в последнее время ставлю систему через него и развёртываю тоже.
Хм... Как-то проктологичски придумано имхо.
На вдске грузиться микросборка c diskXp1, отправляет курлом мне в телегу сообщение типа "faking hoster is reboot your host".
Я захожу по сысаш, делаю geli attach..
Так уже немодно?
Можно подробнее, обычно на VDS сделать fulldisk шифрование проблематично