13.05.2007
Сервер на базе Debian GNU/Linux 4.0 Etch с зашифрованной корневой файловой системой и разделами подкачки.
У xSeries 206 есть 2 порта SATA и 1 двухканальный IDE, но мне необходимо было использовать 4 IDE диска (таково ТЗ, и это обусловлено реальной необходимостью). Поэтому был приобретён PCI IDE контроллер. В итоге я получил 4 диска через PCI IDE и CDROM, подключённый через набортный IDE. Отсюда такие имена устройств.
Disk /dev/hde: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hde1 * 1 31 248976 fd Linux raid autodetect /dev/hde2 32 93 498015 83 Linux /dev/hde3 94 336 1951897+ fd Linux raid autodetect /dev/hde4 337 19457 153589432+ fd Linux raid autodetect Disk /dev/hdf: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdf1 1 36483 293049666 fd Linux raid autodetect Disk /dev/hdg: 160.0 GB, 160041885696 bytes 255 heads, 63 sectors/track, 19457 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdg1 * 1 31 248976 fd Linux raid autodetect /dev/hdg2 32 93 498015 82 Linux swap / Solaris /dev/hdg3 94 336 1951897+ fd Linux raid autodetect /dev/hdg4 337 19457 153589432+ fd Linux raid autodetect Disk /dev/hdh: 300.0 GB, 300069052416 bytes 255 heads, 63 sectors/track, 36481 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdh1 1 36481 293033601 fd Linux raid autodetect
/dev/hde1 и /dev/hdg1 объединяем в RAID-1, используем как /boot, метим как загрузочный. /dev/hde2 используем как корневой раздел, позже от него избавимся. Остальные разделы пока не используем. Файловая система здесь не существенна, я использую ext3.
# aptitude install cryptsetup lvm2
Их нужно создать 3 штуки:
# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/hde3 /dev/hdg3 # mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/hde4 /dev/hdg4 # mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/hdf1 /dev/hdh1
Выясняем UUID каждого массива:
# mdadm --misc --detail /dev/md1|grep UUID # mdadm --misc --detail /dev/md2|grep UUID # mdadm --misc --detail /dev/md3|grep UUID
Прописываем массивы в `/etc/mdadm/mdadm.conf` (добавляем строчки, подставив соответствующие значиения UUID):
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx ARRAY /dev/md2 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx ARRAY /dev/md3 level=raid1 num-devices=2 UUID=xxxxxxxx:xxxxxxxx:xxxxxxxx:xxxxxxxx
Теперь лучше дождаться завершения синхронизации RAID. Отсследить можно командой:
# mdadm --misc --detail /dev/md1
Там смотрим на «State : active, resyncing» и «Rebuild Status : 27% complete». Процесс может занять весьма ощутимое время, так что лучше оставить это счастье синхронизироваться на ночь.
# cryptsetup -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/md1 # cryptsetup -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/md2 # cryptsetup -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/md3
Там задаёт интерактивные вопросы, нужно для начала набрать именно большими буквами YES, потом дважды пароль. В итоге получатся три зашифрованных раздела.
Полученные разделы нужно добавить в `/etc/crypttab`:
root /dev/md1 none luks,cipher=aes-cbc-essiv:sha256 lvm1 /dev/md2 none luks,cipher=aes-cbc-essiv:sha256 lvm2 /dev/md3 none luks,cipher=aes-cbc-essiv:sha256
И открывем их:
# /etc/init.d/cryptdisks restart
Будущий корневой раздел сразу форматируем:
# mkfs -t ext3 /dev/mapper/root
Создаём physical voilumes и volume group:
# pvcreate /dev/mapper/lvm1 # pvcreate /dev/mapper/lvm2 # vgcreate vg1 /dev/mapper/lvm1 /dev/mapper/lvm2
Хорошая идея всегда иметь немного оперативного пространства (например, на тот случай, если у нас заведутся необъятные логи), поэтому часть пространства при создании logical volumes оставляем нераспределённым:
# lvcreate --name usr --size 4G vg1 # lvcreate --name var --size 4G vg1 # lvcreate --name srv --size 300G vg1
Том под /home не создаю, поскольку локальных пользователей на этом серевере будет не много, и задача обеспечить их пространством не стоит.
Форматируем полученные тома:
# mkfs -t ext3 /dev/vg1/usr # mkfs -t ext3 /dev/vg1/var # mkfs -t ext3 /dev/vg1/srv
# mount /dev/mapper/root /mnt # mkdir /mnt/usr # mkdir /mnt/var # mount /dev/vg1/usr /mnt/usr # mount /dev/vg1/var /mnt/var # mount -o bind /dev /mnt/dev
Копируем содержимое текущей установки:
# cp -avx / /mnt
Для этого нужно сначала подмонтировать в новый корень /dev:
# mount -o bind /dev /mnt/dev
Теперь chroot:
# chroot /mnt
Здесь нужно подмонтировать `/proc` и `/boot`:
# mount /proc # mount /boot
Строчку `/dev/hde2 / ext3 defaults,errors=remount-ro 0 1` удаляем, вместо неё пишем:
/dev/mapper/root / ext3 defaults,errors=remount-ro 0 1 /dev/vg1/usr /usr ext3 defaults,errors=remount-ro 0 2 /dev/vg1/var /var ext3 defaults,errors=remount-ro 0 2 /dev/vg1/srv /srv ext3 defaults,errors=remount-ro 0 2
Для подстраховки, на тот случай, если что-то пойдёт не так, обеспечим возможность загрузиться с нешифрованного раздела и попробовать всё исправить. Для этого нужно создать копию текущего initrd:
# cp /boot/initrd.img-2.6.18-4-686 /boot/initrd.img-2.6.18-4-686.cryptobak
и добавить в `/boot/grub/menu.lst` после строчки `### END DEBIAN AUTOMAGIC KERNELS LIST`:
title Debian unencrypted root (hd0,0) kernel /vmlinuz-2.6.18-4-686 root=/dev/hde2 ro initrd /initrd.img-2.6.18-4-686.cryptobak
В том же `/boot/grub/menu.lst` находим строчку `# kopt=root=/dev/hde2 ro` и заменяем на:
# kopt=root=/dev/mapper/root ro
(знак комментария в начале строки НУЖЕН!)
Теперь делаем:
# update-grub # update-initramfs -u -k all
Перегружаем систему. В процессе загрузки на экране появится запрос:
Enter LUKS password:
Так как у нас целых 3 шифрованных раздела, то и вопрос будет задан трижды.
Отключаем действующий swap:
# swapoff -a
Добавляем в /etc/crypttab:
swape /dev/hde2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256 swapg /dev/hdg2 /dev/urandom swap,cipher=aes-cbc-essiv:sha256
И в /etc/fstab:
/dev/mapper/swape none swap sw 0 0 /dev/mapper/swapg none swap sw 0 0
Инициализируем свапы:
# mkswap /dev/hde2 # /etc/init.d/cryptdisks restart # swapon -a
Здесь действительно нужно в начале сделать mkswap, иначе `cryptdisks restart` откажется создавать шифрованный swap, мотивируя тем, что в разделе присутствует файловая система (это наш старый корень).
Так как у нас целых 3 шифрованных раздела, то при загрузке пароль приходится вводить три раза. Меня это на данный момент вполне устраивает, так как конечная конфигурация этой системы будет такова, что ключи для шифрования будут прередаваться на этапе загрузки по SSH (это будет описано отдельной статьёй). Как более простое решение, могу посоветовать использовать для всех разделов, за исключением корневого, ключевые файлы, которые можно положить на корневой зашифрованный раздел. Ключевые файлы нужно будет прописать в `/etc/crypttab` и перегенерировать initrd.
По техническим причинам зашифровать абсолютно всё не представляется возможным. Нешифрованным останется раздел `/boot`, в котором лежат образы ядра и initramfs-дисков. В такой ситуации возможна атака через троян, внедрённый в initramfs (как этому противостоять - тема для отдельной статьи). Однако, для организации такой атаки, в общем случае, необходим физический доступ к серверу.
27.08.07 11:14 Всеволод Балашов комментирует:
IMHO в надо описывать упрощенно - учебную конфигурацию ;)
10.09.07 07:27 uptimebox комментирует:
29.09.07 15:49 vig комментирует:
15.01.08 20:09 z0D5e8n7x комментирует:
16.01.08 07:51 mc комментирует:
18.04.08 11:31 Юрий комментирует:
Поскольку я в линуксе особо не шарю, мой админ сказал, что если зашифровать разделы с секретными данными с помощью
cryptsetup -c aes-cbc-essiv или cryptsetup -c twofish-cbc-essiv , то взлом будет практически нереален.
Подскажи, пожалуйста, так ли это, и какие могут быть дыры. Или хотя бы литературу, которую можно почитать об этом.
Если не сложно, на почту on@dotfix.ru, потому что в блоггере у меня не работает оповещение о комментариях, да и удобнее по почте.
Большое человеческое спасибо!
18.04.08 11:50 uptimebox комментирует:
Дыры могут быть самые разнообразные. Наиболее очевидный вектор атаки на описанный здесь метод шифрования - это внедрение руткита в единственный не зашифрованный раздел - /boot. Этот раздел - самое слабое место всей предлагаемой системы. Имея физический доступ к компьютеру, есть возможность установить даже модифицированную версию ядра.
В свою очередь, от этого можно защищаться, формируя при каждом обновлении /boot его контрольную сумму и проверяя её после монтирования зашифрованных дисков. Я даже написал для одной инсталляции скрипты, реализующие такой метод, но они далеки от совершенства и совершенно непригодны для публикации.
18.04.08 12:34 uptimebox комментирует: