Итак, у нас есть:
сервер с установленной FreeBSD,
диск ad0, на который установлена эта ОС,
диск ad1, который мы будем использовать для создания секретного хранилища,
USB носитель da0, на котором будет размещаться мастер-ключ для доступа к зашифрованному разделу,
USB носитель da1, который будет использован для переноса данных восстановления на компьютер с пищущим приводом.
Приступим
Для создания зашифрованного хранилища мы используем geli - модуль шифрования дисковой подсистемы FreeBSD GEOM. Мы также настроим демон devd для того, чтобы отслеживать извлечение USB носителя и воспользуемся специальным скриптом late-geli.sh для подключения зашифрованного диска при загрузке и его уничтожения при извлечении USB-носителя.
Включение модуля geli
Для того, чтобы мы могли воспользоваться зашифрованным разделом, необходимо настроить автоматический запуск модуля ядра, обеспечмвающего работу geli. Сделать это можно двумя способами. Первый - добавить соответствующую строку в файл /boot/loader.conf и запустить его для того, чтобы не делать лишнюю перезагрузку:
# echo "geom_eli_load=\"YES\"" >> /boot/loader.conf
# geli load
# geli load
Второй способ - изменить конфигурацию ядра системы, добавить в конфигурацию ядра следующие строчки
options GEOM_ELI
device crypto
device crypto
и пересобрав ядро можно приступать к созданию секретного хранилища.
Создание хранилища
Подключите ранее заготовленный носитель к серверу. В системе пояаится диск da0. Необходимо сделать так, чтобы этот диск монтировался при загрузке, так как с него будет браться ключ для подключения зашифрованного диска. Основная проблема, связанная с монтированием USB носителей заключается в том, что их нумерация может меняться в зависимости от того, сколько их в системе. Носитель, подключенный к порту с меньшим номером (нумерацию USB портов на материнской плате узнать можно, но это требует дополнительных усилий), получает меньший номер устройства da при перезагрузке, что может привести к тому, что в папку с ключами будет подключен не тот носитель, который нужно. Для того, чтобы избежать такой ситуации, необходимо воспользоваться функциями модуля glabel, который во FreeBSD 7.2 вкючен по-умолчанию. Этот модуль создает "метки" - ссылки на устройства, имена которых не зависят от того, к какому порту или к какой шине они подключены. Метки дисковых устройств, созданных glabel зависят только от свойств файловой системы этого устройства. Поскольку, как уже говорилось выше, этот модуль вкючен по-умолчанию, метки им создаются автоматически. Проверим, какая метка была выдана нашему носителю:
# glabel list
Geom name: da0s1
Providers:
1. Name: msdosfs/PENDRIVE
Mediasize: 131572224 (125M)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 256977
length: 131572224
index: 0
Consumers:
1. Name: da0s1
Mediasize: 131572224 (125M)
Sectorsize: 512
Mode: r0w0e0
Geom name: da0s1
Providers:
1. Name: msdosfs/PENDRIVE
Mediasize: 131572224 (125M)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 256977
length: 131572224
index: 0
Consumers:
1. Name: da0s1
Mediasize: 131572224 (125M)
Sectorsize: 512
Mode: r0w0e0
Как видно из вывода программы, наш носитель da0 (а точнее его раздел - da0s1) получил метку "msdosfs/PENDRIVE", которая располагается в каталоге /dev. Именно эту метку мы будем использовать для монтирования носителя. Для начала, создадим папки, куда будут монтироваться устройства:
# mkdir /private
# mkdir /keys
# chmod 600 /keys/
# mkdir /keys
# chmod 600 /keys/
Теперь смонтируем носитель, на котором будут размещаться ключи, а также настроим его автоматическое монтирование при перезагрузке системы:
# mount -t msdosfs /dev/msdosfs/PENDRIVE /keys/
# echo "/dev/msdosfs/PENDRIVE /keys msdosfs rw 2 2" >> /etc/fstab
# echo "/dev/msdosfs/PENDRIVE /keys msdosfs rw 2 2" >> /etc/fstab
Также включим автоматическую проверку разделов на наличие ошибок в файловой системе - в этом случае не потребуется ручного вмешательства в работу системы в случае сбоя электропитания.
# echo "fsck_y_enable=\"YES\"" >> /etc/rc.conf
Создадим ключ, который будем использовать для организации зашифрованного хранилища и для последующего доступа к его данным:
# dd if=/dev/random of=/keys/master.ad1 bs=128k count=1
Таким образом, файл /keys/master.ad1 будет содержать 128Кб случайных данных - такой ключ крайне трудно подобрать. Теперь создадим и подключим зашифрованный том:
# geli init -s 4096 -P -K /keys/master.ad1 /dev/ad1
# geli attach -p -k /keys/master.ad1 /dev/ad1
# geli attach -p -k /keys/master.ad1 /dev/ad1
Проверим, все ли в порядке:
# dmesg | tail -n 3
GEOM_ELI: Device ad1.eli created.
GEOM_ELI: Encryption: AES-CBC 128
GEOM_ELI: Crypto: software
GEOM_ELI: Device ad1.eli created.
GEOM_ELI: Encryption: AES-CBC 128
GEOM_ELI: Crypto: software
Все отлично. Исходный диск называется ad1, а после инициализации подсистемы шифрования появилось новое устройство ad1.eli, которое мы и будем использовать в дальнейшей работе:
# ls /dev/ad1*
/dev/ad1 /dev/ad1.eli
/dev/ad1 /dev/ad1.eli
Теперь, когда зашифрованное хранилище создано, можно создать на нем файловую систему и смонтировать ее:
# newfs /dev/ad1.eli
/dev/ad1.eli: 1024.0MB (2097144 sectors) block size 16384, fragment size 4096
using 4 cylinder groups of 256.00MB, 16384 blks, 16384 inodes.
super-block backups (for fsck -b #) at:
160, 524448, 1048736, 1573024
# mount /dev/ad1.eli /private
/dev/ad1.eli: 1024.0MB (2097144 sectors) block size 16384, fragment size 4096
using 4 cylinder groups of 256.00MB, 16384 blks, 16384 inodes.
super-block backups (for fsck -b #) at:
160, 524448, 1048736, 1573024
# mount /dev/ad1.eli /private
Итак, в результате выполнения вышеописанных действий у нас получилось зашифрованное хранилище данных, полностью готовое к работе. Осталось создать диск с данными, необходимыми для восстановления хранилища после его уничтожения и настроить саму систему уничтожения данных.
Создание диска восстановления
Как упоминалось выше, на нашем сервере нет пишущего дисковода, поэтому мы разместим данные на отдельном USB носителе, а потом запишем их на диск, как более надежное средство хранения.
Итак, подключим дополнительный носитель к серверу и проверим его метку при помощи утилиты glabel, как это описывалось ранее. В нашем случае метка следующая: "msdosfs/FLASH". Смонтируем ее в папку /mnt:
# mount -t msdosfs /dev/msdosfs/FLASH /mnt/
Сохраним данные восстановления в файл backup.ad1, который потом запишем на диск. Затем отключим носитель:
# geli backup ad1 /mnt/backup.ad1
# umount /mnt
# umount /mnt
Если в последующем придется восстанавливать зашифрованное хранилище, то вы сможете сделать это приблизительно следующим образом:
# mount -t iso9660 /dev/acd0 /mnt/
# geli restore /mnt/backup.ad1 ad1
# umount /mnt
# geli restore /mnt/backup.ad1 ad1
# umount /mnt
Настройка автоматического монтирования хранилища и уничтожения данных
При настройке автоматического монтирования следует учесть следующее: ключ для подключения защищенного хранилища находится на USB-носителе, который должен быть смонтирован прежде, чем будет произведена попытка подключения. Опции "late" в файле /etc/fstab не достаточно, так как это касается только монтирования файловой системы. Можно по-разному решать эту проблему. Например, можно хранить копию ключа в папке /boot, можно также исправить скрипт /etc/rc.d/geli, добавив туда монтирование необходимых файловых систем. Мы предлагаем другой вариант - скрипт late-geli.sh, который также потребуется для того, чтобы уничтожить хранилище при отсутствии соответствующего USB-носителя.
Итак, разместим этот скрипт в папке с пользовательскими скриптами автозапуска:
# cd /usr/local/etc/rc.d
# fetch http://tau-system.ru/downloads/late-geli.sh
# chmod +x late-geli.sh
# fetch http://tau-system.ru/downloads/late-geli.sh
# chmod +x late-geli.sh
Включим автомонтирование и систему уничтожения данных, добавив следующие строчки в файл /etc/rc.conf:
late_geli_enable="YES"
late_geli_overkill_enable="YES"
late_geli_devices="ad1"
late_geli_ad1_mountpoint="/private"
late_geli_ad1_key="/keys/master.ad1"
late_geli_overkill_enable="YES"
late_geli_devices="ad1"
late_geli_ad1_mountpoint="/private"
late_geli_ad1_key="/keys/master.ad1"
Параметр late_geli_enable включает автоматическое подключение зашифрованного тома при запуске системы. Параметр late_geli_overkill_enable вкючает слежение за доступностью файла с ключем и запуск комманд уничтожения зашифрованного тома в случае отсутствия этого файла.
К сожалению, простого наблюдения за доступностью файла не достаточно. Дело в том, что при аварийном извлечении USB-носителя, файловая система остается смонтированной и файл с ключем хранится в системном буфере. Можно даже посмотреть его содержимое не смотря на то, что носитель, на котором расположен этот файл, отсутствует физически. Поэтому, настроим демон devd, предназначенный для наблюдения за добавлением и удалением различных устройств, таким образом, чтобы при извлечении USB-носителей, отключались соответствующие им файловые системы.
Для этого добавим следующие строчки в файл /etc/devd.conf:
detach 100 {
device-name "umass[0-9]+";
action "for spec in `mount|grep ^/dev|awk '{print $1}'`; do if [ ! -e ${spec} ]; then unmount -f ${spec}; fi; done";
};
device-name "umass[0-9]+";
action "for spec in `mount|grep ^/dev|awk '{print $1}'`; do if [ ! -e ${spec} ]; then unmount -f ${spec}; fi; done";
};
Теперь можно перезагрузиться, пронаблюдав за запуском системы. Если все нормально, то после старта Вы увидете смонтированный зашифрованный носитель, которым можно пользоваться. Например, его можно сделать общим для сети Windows-машин, используя samba.
Вы также можете проверить работоспособность системы, выдернув носитель с ключем. Система при этом должна отреагировать приблизительно следующим образом:
umass0: at uhub0 port 2 (addr 2) disconnected
(da0:umass-sim0:0:0:0): lost device
GEOM_LABEL: Label msdosfs/PENDRIVE removed.
(da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x39, scsi status == 0x0
(da0:umass-sim0:0:0:0): removing device entry
umass0:detached
GEOM_LABEL: Label for provider ad1.eli is ufsid/4aae9e4322acab28.
GEOM_ELI: ad1 has been killed.
GEOM_ELI: Device ad1.eli destroyed.
GEOM_LABEL: Label ufsid/4aae9e4322acab28 removed.
(da0:umass-sim0:0:0:0): lost device
GEOM_LABEL: Label msdosfs/PENDRIVE removed.
(da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x39, scsi status == 0x0
(da0:umass-sim0:0:0:0): removing device entry
umass0:detached
GEOM_LABEL: Label for provider ad1.eli is ufsid/4aae9e4322acab28.
GEOM_ELI: ad1 has been killed.
GEOM_ELI: Device ad1.eli destroyed.
GEOM_LABEL: Label ufsid/4aae9e4322acab28 removed.
Затем Вы можете восстановить уничтоженные данные, воспользовавшись ранее заготовленным диском.
Теперь, когда Вы убедились что все в порядке, можете приступать к работе, надеясь на то, что настроенная нами система не потребуется.
возможно у Вас отключен javascript, если включен - просто обновите страницу