Создание защищенного файлового хранилища

Для решения данной задачи нам необходим сервер с установленной ОС FreeBSD . Также необходим flash-носитель любой емкости (минимальной емкости более чем достаточно). В инструкции подразумевается, что для секретного хранилища Вы выделяете отдельный жесткий диск, однако это не обязательно — для этих целей можно выделить раздел на системном диске. Необходимо также заготовить компакт-диск для хранения данных для восстановления информации. Если на сервере нет пишущего дисковода, рекомендуем заготовить отдельный USB носитель для переноса данных на компьютер с пишущим приводом (хранить данные на таких носителях  не рекомендуется ввиду их недолговечности).

  

Итак, у нас есть:

сервер с установленной 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

Второй способ — изменить конфигурацию ядра системы, добавить в конфигурацию ядра следующие строчки

options GEOM_ELI

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

Как видно из вывода программы, наш носитель da0 (а точнее его раздел — da0s1) получил метку «msdosfs/PENDRIVE», которая располагается в каталоге /dev. Именно эту метку мы будем использовать для монтирования носителя. Для начала, создадим папки, куда будут монтироваться устройства: 

# mkdir /private

# mkdir /keys

# chmod 600 /keys/

Теперь смонтируем носитель, на котором будут размещаться ключи, а также настроим его автоматическое монтирование при перезагрузке системы: 

# mount -t msdosfs /dev/msdosfs/PENDRIVE /keys/

# 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

Проверим, все ли в порядке:

 

# dmesg | tail -n 3

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

Теперь, когда зашифрованное хранилище создано, можно создать на нем файловую систему и смонтировать ее: 

# 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

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

 

Создание диска восстановления

 

Как упоминалось выше, на нашем сервере нет пишущего дисковода, поэтому мы разместим данные на отдельном USB носителе, а потом запишем их на диск, как более надежное средство хранения.

 

Итак, подключим дополнительный носитель к серверу и проверим его метку при помощи утилиты glabel, как это описывалось ранее. В нашем случае метка следующая:

«msdosfs/FLASH».

Смонтируем ее в папку /mnt:

# mount -t msdosfs /dev/msdosfs/FLASH /mnt/

Сохраним данные восстановления в файл backup.ad1, который потом запишем на диск. Затем отключим носитель: 

# geli backup ad1 /mnt/backup.ad1

# umount /mnt

Если в последующем придется восстанавливать зашифрованное хранилище, то вы сможете сделать это приблизительно следующим образом: 

# mount -t iso9660 /dev/acd0 /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

Включим автомонтирование и систему уничтожения данных, добавив следующие строчки в файл /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_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»;

};

Теперь можно перезагрузиться, пронаблюдав за запуском системы. Если все нормально, то после старта Вы увидете смонтированный зашифрованный носитель, которым можно пользоваться. Например, его можно сделать общим для сети 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.

Затем Вы можете восстановить уничтоженные данные, воспользовавшись ранее заготовленным диском. 

Теперь, когда Вы убедились что все в порядке, можете приступать к работе, надеясь на то, что настроенная нами система не потребуется.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *