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 разів один і той же пароль ...

— user51166
джерело

Якщо хтось може прорватися до вашої системи та отримати root, їм не потрібно отримати ключ до вашого зашифрованого розділу. Немає сенсу захищати його від root (і це неможливо без спеціального обладнання, наприклад, TPM або запуску у віртуальній машині).

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

Вибачте ? Навіть якщо я root, я повинен надати ключ-файл / пароль для розблокування розділів LUKS. Я думаю, ви маєте на увазі, що якщо хтось стає root, він має повний доступ до моїх зашифрованих даних. На жаль, це просто вірно, оскільки після того, як зашифрований розділ змонтований, це не має значення, зашифрований він чи ні. Яка б тоді була перевага віртуальної машини? То чому б взагалі допомагати шифрування? Є єдине рішення заборонити доступ до root через SSH та подібні сервіси? Але все ж, якщо хакер потрапляє в систему як звичайний користувач, він зазвичай має доступ до читання кожного файлу, чи не так?

— user51166

Точно, якщо хтось працює на вашій системі, він має доступ до всього. VM може означати, що вони мають доступ до всього, що знаходиться у ВМ. Єдине використання шифрування - це якщо хтось краде ваше обладнання.

— Жил 'ТАК - перестань бути злим'

Так добре ... у цьому випадку ми можемо стверджувати, що єдиний майже безпечний спосіб зберігання даних - це зашифрований комп'ютер, відключений від усієї мережі та інтегрований у будівлю. Тоді все одно хтось може прийти з клавіатурою і вкрасти ваші дані, не перезавантажуючи систему. Я можу також ізолювати свої системи від Інтернету, оскільки це буде резервний сервер, тому доступ до локальної мережі - це все, що потрібно. Потім знову ... якщо використовується VPN або інфікується одна з машин локальної мережі, резервна машина також буде піддана. Що б ви зробили для вирішення цих проблем?

— користувач51166

дивіться також unix.stackexchange.com/a/110102/50601

— Tim Abell

Відповіді:

Ви можете використовувати /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

Оскільки в даний час дуже важко дійсно видалити файл, переконайтеся, що / шлях / до / mykeyfile знаходиться на зашифрованому диску (це sda6cryptбуло б в моєму прикладі хорошим рішенням).

Загалом, ви можете додати додатковий рівень захисту, використовуючи шифрування файлової системи користувача, наприклад, через encfs.

— йофель
джерело

Таким чином мені не потрібно було зберігати файл ключів на диску. Це було б чудово. Однак ви вважаєте, що це варте клопоту (тобто зберігання файлу ключів на зашифрованому кореневому пристрої є "безпечним"? Я запитую думку, оскільки маю певні сумніви. Дякую за пропозицію.

— користувач51166

Рішення з decrypt_derivedмає єдину перевагу - відсутність ключового файлу. Якщо хтось може отримати кореневий доступ, ви все одно втрачаєтесь. Читання ключових файлів для зловмисника може бути трохи простіше, ніж виконання сценарію. Щоб отримати більшу безпеку, ви можете посилити свою систему, використовуючи, наприклад, TOMOYO Linux, AppAmor, SMACK, SELinux, безпеку, ... але це потребує додаткових зусиль. І питання, чи варто воно, тоді важливіше. Будь ласка, не забувайте мати резервну копію ключа або окремий ключ на випадок виходу з ладу накопичувача, від якого ключ отриманий / збережений.

— jofel

Я планував використовувати також безпеку або подібні програмні засоби (не на початку, але коли я встигну, захистив би це). Я думаю використовувати лише паролі, а не ключові файли, якщо це можливо. Добре, що пароль буде зберігатися в оперативній пам’яті, тому я думаю, що ви можете посперечатися і з цим.

— user51166

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

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

@Gilles Оскільки я не є експертом із безпечного видалення файлів, я змінив свою відповідь. Рекомендую зараз зберігати файл ключів на зашифрованому диску.

— jofel

На основі відповіді jofels, ось той самий приклад, але без необхідності зберігання ключа у файлі. Ключ передається в названій трубці, яка нічого не зберігає на диску.

Ви можете використовувати /lib/cryptsetup/scripts/decrypt_derivedу своїй криптовалюті для автоматичного використання ключа з одного диска на інший. 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.

— ЯнКаніс
джерело