Linux: LUKS и несколько жестких дисков

У меня установлена система Debian Linux (amd64) на зашифрованном устройстве системы RAID-1 (LVM на LUKS), и у меня будет RAID-6 с дисками> = 4, на которые я буду помещать свои данные (LUKS и, возможно, LVM).

Я думаю, что основная идея состоит в том, чтобы разблокировать системный зашифрованный раздел (при загрузке локально или через ssh) и сохранить ключевой файл в / etc / crypttab для зашифрованного раздела RAID-6. Это создает угрозу безопасности? Я имею в виду ... это довольно бесполезно, если кто-то может просто войти в мою систему локально / удаленно, и я думаю, что на серверах работает множество служб, уязвимых для "рутирования" (например, SSH). Есть ли альтернатива (помимо разблокировки раздела через SSH, что может быть проблемой, поскольку, например, операции резервного копирования начинаются еще до монтирования раздела данных).

На другой машине я буду использовать несколько дисков с LUKS + серая дыра (без RAID-6) для резервного копирования, и будет очень сложно разблокировать 10 дисков, введя 10 раз один и тот же пароль ...

linux security encryption raid luks user51166
источник

Если кто-то может взломать вашу систему и стать пользователем root, ему не нужно получать ключ к вашему зашифрованному разделу. Нет смысла защищать его от root (и это невозможно без специального оборудования, такого как TPM или работающего на виртуальной машине).

Жиль "ТАК - перестань быть злым"

Прошу прощения ? Даже если я root, мне нужно дать ключевой файл / фразу-пароль, чтобы разблокировать разделы LUKS. Я полагаю, вы имеете в виду, что если кто-то станет root, он получит полный доступ к моим зашифрованным данным. К сожалению, это просто правда, потому что после монтирования зашифрованного раздела не имеет значения, зашифрован он или нет. В чем же тогда преимущество виртуальной машины? Так почему шифрование должно помочь вообще? Является ли единственным решением запретить доступ к root через SSH и подобные сервисы? Но все же, если хакер входит в систему как обычный пользователь, он, как правило, имеет право на чтение каждого файла, не так ли?

user51166

Точно, если кто-то является пользователем root в вашей системе, он имеет доступ ко всему. ВМ может означать, что у них есть доступ ко всему в ВМ. Шифрование можно использовать только в том случае, если кто-то украл ваше оборудование.

Жиль "ТАК ... перестать быть злым"

Да, хорошо ... в этом случае мы можем утверждать, что единственный почти безопасный способ хранения данных - это зашифрованный компьютер, отключенный от всей сети и встроенный в здание. Тогда кто угодно может прийти с клавиатурой и украсть ваши данные без перезагрузки вашей системы. Я мог бы также изолировать свои системы от Интернета, так как это будет резервный сервер, поэтому доступ к локальной сети - это все, что ему нужно. Опять же ... если будет использоваться VPN или один из компьютеров локальной сети будет заражен, резервная машина также будет уязвима. Что бы вы сделали, чтобы решить эти проблемы?

user51166

см. также unix.stackexchange.com/a/110102/50601

Тим Абелл

Ответы:

Вы можете использовать /lib/cryptsetup/scripts/decrypt_derivedв своем, crypttabчтобы автоматически использовать ключ с одного диска на другой.

decrypt_derived Сценарий является частью пакета Cryptsetup Debian.

Небольшой пример добавления ключа из sda6crypt в sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

Поскольку в настоящее время очень трудно действительно удалить файл, убедитесь, что / path / to / mykeyfile находится на зашифрованном диске ( sda6cryptв моем примере это было бы хорошим решением).

В общем, вы можете добавить дополнительный уровень безопасности, используя шифрование файловой системы пространства пользователя, например, через encfs.

jofel
источник

Таким образом, мне не нужно хранить ключевой файл на диске. Это было бы чудесно. Однако считаете ли вы, что это стоит потраченных усилий (т. Е. Хранение ключевого файла на зашифрованном корневом устройстве «достаточно безопасно»)? Я спрашиваю мнение, так как у меня есть некоторые сомнения. Спасибо за предложение.

user51166

decrypt_derivedЕдинственное преимущество решения в том, что нет файла ключа. Если кто-то может получить root-доступ, вы все равно обычно теряетесь. Чтение ключевых файлов может быть немного проще для злоумышленника, чем запуск сценария. Чтобы повысить безопасность, вы можете укрепить свою систему, используя, например, TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... но это требует дополнительных усилий. И вопрос, стоит ли он того, тогда важнее. Пожалуйста, не забудьте иметь резервную копию ключа или отдельный ключ на случай, если диск выйдет из строя, когда ключ получен или сохранен.

Джофель

Я планировал также использовать grsecurity или аналогичные программы (не с самого начала, но когда у меня будет время, я обеспечу это). Я думаю об использовании только паролей, а не ключевых файлов, если это возможно. Ну, пароль будет храниться в оперативной памяти, так что я думаю, что вы также можете поспорить об этом.

user51166

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

Жиль "ТАК - перестань быть злым"

@ Жиль Так как я не эксперт по безопасному удалению файлов, я отредактировал свой ответ. Я рекомендую сейчас хранить ключевой файл на зашифрованном диске.

Джофель

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

Вы можете использовать /lib/cryptsetup/scripts/decrypt_derivedв своей crypttab для автоматического использования ключа с одного диска на другой. decrypt_derivedСценарий является частью пакета Cryptsetup Debian.

Модифицированный пример добавления ключа из sda6crypt в sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

keyscriptОпция работает только тогда , когда crypttabобрабатываются оригинальными инструментами Cryptsetup Debian, тот Systemd перевыполнение не поддерживает его. Если ваша система использует systemd (который является большинством систем), вам нужна initramfsопция для принудительной обработки в initrd средствами cryptsetup до запуска systemd.

JanKanis
источник