Linux: LUKS i wiele dysków twardych

11

Mam system Debian Linux (amd64) zainstalowany na zaszyfrowanym urządzeniu RAID-1 (LVM na LUKS) i będę miał RAID-6 o> = 4 dyskach, na których umieszczę moje dane (LUKS i być może LVM).

Myślę, że podstawową ideą jest odblokowanie zaszyfrowanej partycji systemowej (podczas rozruchu lokalnego lub przez ssh) i przechowywanie pliku klucza w / etc / crypttab dla zaszyfrowanej partycji RAID-6. Czy to stanowi zagrożenie dla bezpieczeństwa? To znaczy ... jest całkiem bezużyteczne, jeśli ktoś może po prostu wejść do mojego systemu lokalnie / zdalnie i myślę, że na serwerach podatnych na „rootowanie” (np. SSH) działa wiele usług. Czy istnieje alternatywa (oprócz odblokowania partycji przez SSH, co może być problemem, ponieważ np. Operacje tworzenia kopii zapasowej rozpoczynają się jeszcze przed zamontowaniem partycji danych).

Na innej maszynie użyję wielu dysków z LUKS + greyhole (bez RAID-6) do tworzenia kopii zapasowych i będzie to prawdziwy problem z odblokowaniem 10 dysków przez wprowadzenie 10 razy tego samego hasła ...

linux security encryption raid luks użytkownik51166
źródło
Jeśli ktoś może włamać się do twojego systemu i zostać rootem, nie musi uzyskać klucza do zaszyfrowanej partycji. Nie ma sensu chronić go przed rootem (i nie jest to możliwe bez specjalnego sprzętu, takiego jak TPM lub działającego na maszynie wirtualnej).
Gilles 'SO - przestań być zły'
Przepraszam ? Nawet jeśli jestem rootem, muszę podać plik klucza / hasło, aby odblokować partycje LUKS. Podejrzewam, że masz na myśli, że jeśli ktoś zostanie rootem, ma pełny dostęp do moich zaszyfrowanych danych. Niestety jest to po prostu prawda, ponieważ po zamontowaniu zaszyfrowanej partycji nie ma znaczenia, czy jest ona zaszyfrowana, czy nie. Jakie byłyby wówczas zalety maszyny wirtualnej? Dlaczego więc szyfrowanie powinno w ogóle pomóc? Czy jedynym rozwiązaniem jest odmowa dostępu do roota za pośrednictwem SSH i podobnych usług? Ale jeśli haker dostanie się do systemu jako zwykły użytkownik, zwykle ma dostęp do odczytu każdego pliku, prawda?
user51166,
1
Dokładnie, jeśli ktoś jest rootem w twoim systemie, ma dostęp do wszystkiego. Maszyna wirtualna może oznaczać, że ma dostęp do wszystkiego na maszynie wirtualnej. Jedynym zastosowaniem szyfrowania jest sytuacja, gdy ktoś ukradnie twój sprzęt.
Gilles „SO- przestań być zły”
Tak, cóż ... w takim przypadku możemy argumentować, że jedynym prawie bezpiecznym sposobem przechowywania danych jest szyfrowanie komputera odłączonego od całej sieci i zintegrowanego z budynkiem. Wciąż jednak każdy może przyjść z klawiaturą i ukraść dane bez ponownego uruchamiania systemu. Równie dobrze mogę odizolować swoje systemy od Internetu, ponieważ będzie to serwer zapasowy, dlatego dostęp do sieci LAN jest wszystkim, czego potrzebuje. Z drugiej strony ... w przypadku użycia sieci VPN lub zarażenia jednego z urządzeń LAN komputer zapasowy również zostałby ujawniony. Co byś zrobił, aby rozwiązać te problemy?
user51166
patrz również unix.stackexchange.com/a/110102/50601
Tim Abell

Odpowiedzi:

7

Możesz użyć /lib/cryptsetup/scripts/decrypt_derivedw swoim, crypttababy automatycznie użyć klucza z jednego dysku na inny.

decrypt_derived Skrypt jest częścią pakietu cryptsetup Debiana.

Mały przykład dodania klucza z sda6crypt do 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

Ponieważ obecnie bardzo trudno jest naprawdę usunąć plik, upewnij się, że / path / to / mykeyfile znajduje się na zaszyfrowanym dysku ( sda6cryptbyłoby to w moim przykładzie dobrym rozwiązaniem).

Zasadniczo można dodać dodatkową warstwę bezpieczeństwa, używając szyfrowania systemu plików w przestrzeni użytkownika, np encfs. Przez .

Jofel
źródło
W ten sposób nie powinienem przechowywać pliku kluczy na dysku. To byłoby miłe. Jak myślisz, czy warto jednak (np. Przechowywanie pliku klucza na zaszyfrowanym urządzeniu root jest „wystarczająco bezpieczne”)? Pytam o opinię, ponieważ mam wątpliwości. Dzieki za sugestie.
user51166
Rozwiązanie decrypt_derivedma tę jedyną zaletę, że nie ma pliku klucza. Jeśli ktoś może uzyskać dostęp do konta root, zazwyczaj i tak się gubi. Czytanie kluczy może być nieco łatwiejsze dla intruza niż uruchamianie skryptu. Aby uzyskać większe bezpieczeństwo, możesz wzmocnić swój system, używając np. TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... ale to wymaga dodatkowych wysiłków. Ważniejsze jest zatem pytanie, czy warto. Nie zapomnij mieć kopii zapasowej klucza lub oddzielnego klucza na wypadek awarii dysku w miejscu, w którym klucz pochodzi / jest przechowywany.
jofel
Planowałem także używać grsecurity lub podobnego oprogramowania (nie na początku, ale kiedy będę miał czas, zabezpieczy to). Mam na myśli używanie tylko haseł, a nie plików kluczy, jeśli to możliwe. Hasło zostanie zapisane w pamięci RAM, więc myślę, że możesz się o to kłócić.
user51166
Nie ma dobrego sposobu na usunięcie pliku klucza w dowolnym miejscu, bez zastąpienia całego systemu plików (a być może nawet wtedy, gdy dysk ulegnie awarii). System plików kronikowania nie pogarsza sytuacji.
Gilles „SO- przestań być zły”
@Gilles Ponieważ nie jestem ekspertem od bezpiecznego usuwania plików, zredagowałem swoją odpowiedź. Polecam teraz przechowywać plik klucza na zaszyfrowanym dysku.
jofel
1

Na podstawie odpowiedzi Jofels, oto ten sam przykład, ale bez konieczności przechowywania klucza w pliku. Klucz jest przekazywany w nazwanym potoku, który nie przechowuje niczego na dysku.

Możesz użyć /lib/cryptsetup/scripts/decrypt_derivedna swojej crypttab do automatycznego użycia klucza z jednego dysku na inny. decrypt_derivedSkrypt jest częścią pakietu cryptsetup Debiana.

Zmodyfikowany przykład dodawania klucza z sda6crypt do 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

keyscriptOpcja działa tylko wtedy, gdy crypttabsą przetwarzane przez oryginalnych narzędzi cryptsetup Debiana, tym Systemd reimplementacja obecnie nie obsługuje go. Jeśli twój system używa systemd (czyli większości systemów), potrzebujesz initramfsopcji wymuszenia przetwarzania w initrd przez narzędzia cryptsetup, zanim systemd się uruchomi.

JanKanis
źródło