The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Создание шифрованных образов виртуальных машин
Инструкция по созданию полностью зашифрованного образа гостевой системы, в
котором шифрование охватывает корневой раздел и стадию загрузки.

Извлекаем содержимое корневого раздела образа виртуальной машины, который
требуется зашифровать,  в 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
также нужно обновить метки (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 и на
последующих стадиях загрузки запрашиваться не будет.
 
Ключи: luks, crypt, dist, vm, image, boot / Лицензия: CC-BY
Раздел:    Корень / Безопасность / Шифрование, PGP

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, vantoo (ok), 10:42, 27/12/2020 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     
  • 1.2, pavlinux (ok), 12:32, 27/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    То есть, если спи...т диск, то ключик уже в комплекте?

    /etc/cryptsetup-keys.d/luks-<UUID>.key
     
     
  • 2.3, Аноним (3), 23:12, 27/12/2020 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +1 +/
    Видимо /etc/cryptsetup-keys.d должен быть симлинком на юсб-флешку, а еще лучше примонтированным сетевым устройством :)
     
     
  • 3.14, ОхотникНаОленей (?), 04:04, 10/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Это вообще видимо не для сокрытия данных, а скорее для контроля целостности загружаемого образа или я не понял нафига козе баян.
     
  • 2.9, Аноним (9), 16:11, 02/01/2021 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    угу, в комплекте. Лежит на зашифрованном разделе внутри образа. Без прав рута в работающей виртуалке доступ к нему получить затруднительно.

    ключик нужен чтобы запихнуть его в initrd и пароль дважды не вводить. Можно /boot сделать отдельным, а в initrd запихнуть dropbear, тогда разлочивать можно будет по ссх. Правда если совсем параноить, то надо проверять, что незашифрованная часть не менялась.

     
     
  • 3.17, pavlinux (ok), 03:42, 21/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > угу, в комплекте. Лежит на зашифрованном разделе внутри образа.

    Залью себя бетоном, попробуй найди.

    > Без прав рута ...

    Я диск спёр, я - бог, чо мне твой рут!?

    > и пароль дважды не вводить.

    А, то есть они ещё и одинаковые? )))

    > ключик нужен чтобы запихнуть его в initrd

    Тя научить разбирать initrd?


    Боги секурити собрались! )

     
     
  • 4.18, Аноним (18), 10:18, 23/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > Я диск спёр, я - бог, чо мне твой рут!?

    и ключ внутри зашифрованного файла. Виртуалку без пароля ты не запустишь

    > Тя научить разбирать initrd?

    разбирать initrd я умею, а ты научись сначала initrd вытаскивать из LUKS без пароля и ключа.

    Еще раз:
    1. товарищ шифрует раздел внутри образа диска
    2. для того, чтобы запустить виртуалку этот раздел надо расшифровать дважды: это делает груб, чтобы отыскать initrd и ядро, а затем ядро, чтобы смонтировать корень
    3. для того, чтобы убрать второй запрос пароля добавляется ключ, который может быть каким угодно, даже одинаковым с паролем.
    3.1 ключ лежит на зашифрованном разделе внутри образа. Т.е. без расшифровки ты его не получишь.
    3.2 ключ добавляется в initrd, который тоже лежит на зашифрованном разделе внутри образа. Т.е. без расшифровки ты его не получишь.

    ключей и паролей вне зашифрованных файлов на сервере не хранится (разве что кто-то ССЗБ), если ты спер диск, то тебе надо расшифровать все, чтобы получить ключи.

    Лучше не вынивать диск, а подменить груб или просканировать память виртуалки

     

  • 1.4, Аноним (4), 00:45, 28/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  [] []     [к модератору]
  • +/
    А что из них лучше luks1 или luks2 ?
     
     
  • 2.6, Аноним (-), 14:04, 28/12/2020 [^] [^^] [^^^] [ответить]      [к модератору]
  • +1 +/
    Насколько я понял, luks2 отличается от luks1 новым форматом заголовка (header).
    Так, слоты для ключей (keyslot) переведены в json формат, и убрано ограничение на их количество (в luks1 не более 7, в luks2 по умолчанию 32).
    Также добавлены новые алгоритмы (Argon2i и Argon2id) кодирования парольной фразы (passphrase | keyfile) основной смысл которых - повысить время перебора (bruteforce) для атакующей стороны.
    В заголовке теперь хранится резервная копия слотов.
    Из-за этого размер заголовка увеличился с 2 до 16 MiB, и теперь имеет плавающий (в большую сторону) размер.
    В плане шифрования данных они идентичны.
    Вот тут некоторые подробности:
    gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
     
     
  • 3.11, Аноним (11), 05:18, 05/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Чуть менее очевидная разница в том, что на данный момент многим программам, например grub2, о luks2 известно менее, чем о luks1, как следствие не все фишки работающие с первым можно повторить со вторым. Например, шифрованный /boot.
     
     
  • 4.22, Full Master (?), 19:35, 26/03/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    В grub 2.0.4 завезли поддержку LUKS2.
     

  • 1.5, Аноним (5), 13:33, 28/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    Автор забыл во вводной части указать кейсы его подхода с общим описанием идеи, а вычленять это из простыни не охота.
    Для страждущих рекомендую эту серию материалов: wiki.archlinux.org/index.php/dm-crypt

    зы
    в простыне виднеется ошибка для /etc/crypttab:
    cr_root UUID=<uuid> luks none
    последние два слова нужно поменять местами.

     
  • 1.7, Бесконечность (?), 12:43, 30/12/2020 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    А в чем плюс шифрования каждого гостя, кроме большей секурности за счет разных ключей?
     
     
  • 2.8, Аноним (8), 13:12, 02/01/2021 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    плюс в размере. Бэкапы гостей теперь несжимаемые.
     
     
  • 3.16, Бесконечность (?), 10:49, 20/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    > плюс в размере. Бэкапы гостей теперь несжимаемые.

    Сомневаюсь, что это плюс..

     
  • 2.10, XoRe (ok), 23:15, 02/01/2021 [^] [^^] [^^^] [ответить]  []     [к модератору]
  • +/
    Представьте, что у вас 23 личности. И каждая хочет себе зашифрованную виртуалку...
     

  • 1.12, Pavel Piatruk (?), 06:29, 06/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    отличная статья, но много осталось за кадром -- например, внедрение ключа в initrd для  centos. Я уже написал альтернативный скрипт, для более бездумного копипастинга. На выходе VMDK для загрузки шифрованной VM в режиме UEFI. Протестировано в vmware.
     
  • 1.13, Pavel Piatruk (?), 06:32, 06/01/2021 [ответить] [﹢﹢﹢] [ · · · ]      [к модератору]
  • +/
    P.S. Интересно, присутствует ли угроза подмены EFI файлов ( они на незашифрованном разделе ) и установки keylogger'a? Или там все подписано и их нет смысла менять?
     
  • 1.15, alexk (??), 05:23, 14/01/2021 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    А нахрена все это? Установщики перестали поддерживать шифрование при установке?
     
     
  • 2.19, Аноним (-), 08:24, 28/01/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Debootstrap никогда его и не поддерживал, а я в последнее время ставлю систему через него и развёртываю тоже.
     

  • 1.21, anonim365 (?), 23:12, 25/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  []     [к модератору]
  • +/
    Хм... Как-то проктологичски придумано имхо.
    На вдске грузиться микросборка c diskXp1, отправляет курлом мне в телегу сообщение типа "faking hoster is reboot your host".
    Я захожу по сысаш, делаю geli attach..
    Так уже немодно?
     
     
  • 2.23, yshurik (??), 11:14, 10/08/2021 [^] [^^] [^^^] [ответить]      [к модератору]
  • +/
    Можно подробнее, обычно на VDS сделать fulldisk шифрование проблематично
     


     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру