Linux: LUKS ve çoklu sabit sürücüler

RAID-1 sistem şifreli bir cihaza (LUKS üzerinde LVM) yüklü bir Debian Linux sistemi (amd64) var ve verilerimi (LUKS ve belki LVM) koyacağım> = 4 diskten oluşan bir RAID-6 olacak.

Temel fikir sistem şifreli bölüm kilidini (yerel veya ssh üzerinden önyükleme sırasında) ve / key / crypttab RAID-6 şifreli bölüm için bir anahtar dosya saklamak olduğunu düşünüyorum. Bu bir güvenlik riski oluşturuyor mu? Yani ... birisinin sistemime yerel olarak / uzaktan girebilmesi oldukça işe yaramaz ve bence "köklenme" ye (örneğin SSH) karşı savunmasız olan sunucular üzerinde çalışan birçok hizmet olduğunu düşünüyorum. Bir alternatif var mı (örneğin, yedekleme işlemleri veri bölümü monte edilmeden önce bile başladığı için bir sorun olabilir) SSH üzerinden bölüm kilidini açmak yanında).

Başka bir makinede Yedeklemeler için LUKS + greyhole (RAID-6 yok) ile birden fazla disk kullanacağım ve aynı şifreyi 10 kez girerek 10 diskin kilidini açmak gerçek bir acı olacak ...

— user51166
kaynak

Birisi sisteminize girip root olabilirse, şifreli bölümünüzün anahtarını alması gerekmez. Kökten korumanın bir anlamı yoktur (ve TPM gibi özel bir donanım olmadan veya sanal bir makinede çalışmak mümkün değildir).

— Gilles 'SO- kötü olmayı bırak'

Affedersiniz ? Kök olsam bile, LUKS bölümlerinin kilidini açmak için anahtar dosyasını / parolayı vermem gerekiyor. Sanırım birisi kök haline gelirse şifrelenmiş verilerime tam erişime sahip demektir. Ne yazık ki bu doğrudur, çünkü şifreli bölüm bir kez monte edildiğinde, şifrelenip şifrelenmemesi fark etmez. O halde sanal makinenin avantajı ne olurdu? Peki şifreleme neden yardımcı olsun ki? SSH ve benzeri hizmetler yoluyla root erişimini engelleyen tek çözüm mü? Ancak yine de bir bilgisayar korsanı normal bir kullanıcı olarak sisteme girerse, her dosyaya okuma erişimi vardır, değil mi?

— user51166

Tam olarak, birisi sisteminizde kökse, her şeye erişebilir. VM, VM'deki her şeye erişime sahip oldukları anlamına gelebilir. Şifrelemenin tek kullanımı, birisinin donanımınızı çalmasıdır.

— Gilles 'SO- kötü olmayı bırak'

Evet ... bu durumda veri depolamanın neredeyse güvenli bir yolunun tüm ağla bağlantısı kesilmiş ve binaya entegre edilmiş şifreli bir bilgisayarda olduğunu iddia edebiliriz. Sonra yine de herkes bir klavye ile gelebilir ve sisteminizi yeniden başlatmadan verilerinizi çalabilir. Yedekleme sunucusu olacağı için sistemlerimi internetten de yalıtabilirim, bu yüzden LAN erişimi tek ihtiyacı var. Sonra tekrar ... bir VPN kullanılırsa veya LAN makinelerinden birine bulaşırsa, yedek makine de ortaya çıkar. Bu sorunları çözmek için ne yapardınız?

— user51166

ayrıca bkz. unix.stackexchange.com/a/110102/50601

— Tim Abell

Yanıtlar:

Sen kullanabilirsiniz /lib/cryptsetup/scripts/decrypt_derivedGözlerinde farklı crypttabotomatik olarak başka bir diskin anahtarı kullanmak.

decrypt_derived Komut Debian'ın cryptsetup paketinin bir parçasıdır.

Sda6crypt'den sda5'e anahtar eklemek için küçük örnek:

/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

Günümüzde bir dosyayı gerçekten silmek çok zor olduğundan, / path / to / mykeyfile dosyasının şifrelenmiş bir sürücüde olduğundan emin olun ( sda6cryptbenim örneğimde iyi bir çözüm olacaktır).

Genel olarak, kullanıcı alanı dosya sistemi şifrelemesini kullanarak örneğin ek bir güvenlik katmanı ekleyebilirsiniz encfs.

— jofel
kaynak

Bu şekilde, anahtar dosyasını diskte saklamam gerekmiyor. İyi olur. Bununla birlikte, soruna değdiğini düşünüyor musunuz (yani, anahtar dosyasını şifrelenmiş kök cihazda saklamak "yeterince güvenli")? Bazı şüphelerim olduğu için bir fikir istiyorum. Önerin için teşekkürler.

— user51166

Çözümün decrypt_derivedtek avantajı var, anahtar dosya yok. Birisi root erişimi alabilirse, normalde zaten kaybolursunuz. Önemli bir dosyayı okumak, davetsiz misafir için bir komut dosyasını çalıştırmaktan biraz daha kolay olabilir. Daha fazla güvenlik elde etmek için, örneğin TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... kullanarak sisteminizi sertleştirebilirsiniz, ancak bu ek çaba gerektirir. Ve buna değer olup olmadığı sorusu daha önemlidir. Lütfen sürücünün anahtarın türetildiği / depolandığı yerde çökmesi durumunda anahtarın yedeğini veya ayrı bir anahtarı kullanmayı unutmayın.

— jofel

Ben de güvenlik güvenliği veya benzeri yazılımları kullanmayı planladım (başlangıçta değil, ama zamanım olduğunda bunu güvende tutacağım). Mümkünse sadece parola değil anahtar dosya kullanmayı düşünüyorum. Parola RAM'de saklanacak, bu yüzden de bu konuda tartışabilirsiniz.

— user51166

Tüm dosya sisteminin üzerine yazmaktan (ve belki de disk arızalıysa bile) bir anahtar dosyasını hiçbir yerde silmenin iyi bir yolu yoktur. Günlük dosya sistemi işleri daha da kötüleştirmez.

— Gilles 'SO- kötü olmayı bırak'

@Gilles Güvenli dosya silme uzmanı olmadığım için cevabımı düzenledim. Şimdi anahtar dosyasını şifreli sürücüde saklamanızı tavsiye ederim.

— jofel

Jofels yanıtına göre, burada aynı örnek var, ancak anahtarı bir dosyada saklamak zorunda kalmadan. Anahtar, diskte hiçbir şey saklamayan adlandırılmış bir kanalda geçirilir.

Sen kullanabilirsiniz /lib/cryptsetup/scripts/decrypt_derivedotomatik diğeri için bir diskten anahtarı kullanacak şekilde crypttab içinde. decrypt_derivedKomut Debian'ın cryptsetup paketinin bir parçasıdır.

Sda6crypt'den sda5'e anahtar eklemek için değiştirilmiş örnek:

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

Bu keyscriptseçenek yalnızca crypttabDebian'ın orijinal şifreleme araçları tarafından işlenirse çalışır , sistemd yeniden uygulaması şu anda desteklemez. Sisteminiz systemd (çoğu sistemdir) kullanıyorsa, initramfssystemd başlamadan önce işlemin kripto kurulum araçları tarafından initrd'de yapılmasını zorlama seçeneğine ihtiyacınız vardır .

— JanKanis
kaynak