Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Z tego co widać Truecrypt to już historia. Teraz jest jakiś Veracrypt. Chodzi mi o zaszyfrowanie całego dysku tzn. partycji sda1 , sda2. bo tyle mam. Szyfrowanie musi być z górnej półki aby nie było możliwości żadnym programem recovery odzyskać plików, a w szczególności dokumentów.
Czy tym Veracrypt jest to możliwe? bo w chwili obecnej nie mam jak utworzyć volumenu z uwagi, że na dysku są dane.
Offline
2771
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:35:42)
Offline
Ja podzieliłem dysk przez lvm + szyfrowanie LUKS i działa ok. Z live cd chyba nikt nie podmontuje woluminu bo musiałby najpierw powalczyć z lvm. Wydaje mi się, że jest to rozwiązanie bezpieczne porównując np. 'standardowy' podział na partycje i nie używając w ogóle szyfrowania.
Offline
Czemu powalczyć z LVM? Skoro twój system jest w stanie ustalić odpowiedni podział LVM, to nikomu innemu nie sprawi to większej trudności.
Ja ostatnio sobie opracowałem mechanizm "headless LUKS system", gdzie na dysku są jedynie zaszyfrowane dane, a nagłówki zaszyfrowanych kontenerów (w tym systemowy) są trzymane na pendrive, czy innym zewnętrznym nośniku. Dodatkowo cały bootloader jest trzymany również na tym nośniku dając gwarancję integralności partycji /boot/ . xD By otworzyć taki system, potrzeby jest pendrive skąd będzie czytana konfiguracja bootloadera. Po jej wczytaniu, zostaną przeczytane nagłówki LUKS, które również są na penie. Po tym, jak system wystartuje, można partycję boot odmontować, a pena wyciągnąć. xD
Offline
No taka opcja jak Twoja @morfik to bajka, dla mnie to raczej czarna magia bo aż taki biegły w tym temacie nie jestem. Jak szyfrowałem LUKS'em to była opcja eksportu na inny dysk, ale to była pierwsza w życiu instalka oparta o LUKS więc zostało tak do dziś:) Wariant który posiadam ja, na pewno nieco zniechęci kogoś kto ma podstawową wiedzę, jak przekopiować dane z dysku używając livecd z partycji linuksowych/windowsowych bez jakiegokolwiek zabezpieczenia. Ktoś bardziej 'kumaty' ogarnie pewnie bez problemu. Ale to chyba i tak bezpieczniejsze jak podział na fizyczne woluminy + standardowe hasło w gdm/lightdm :)
Ostatnio edytowany przez BlackEvo (2016-02-25 20:44:03)
Offline
Weź pod uwagę, że ta partycja /boot/ jest niczym nie chroniona i jak nie zabezpieczysz jej, to na nic ci to szyfrowanie się nie przyda. xD Można ci hacknąć bootloader jak i również initramfs. Poza tym ten initramfs zawiera szereg plików tego zaszyfrowanego systemu, a to już wręcz podawanie na tacy konfiguracji systemu. xD
Na dobrą sprawę ten mój setup to nie jest skomplikowany. Jedyne co to potrzebne były odpowiednie opcje i zgranie tego wszystko. Partycję /boot/ to chyba wiesz jak odseparować od systemu, zainstalować bootloader to też nie problem. A oddzielenie nagłówków od kontenerów to sprowadza się do zrobieniu backupu via luksHeaderBackup , zapisania go na pendrive i wyczyszczeniu oryginalnego nagłówka. Choć tu jest problem, bo potrzebny jest UUID kontenera. Jak ci się nie chce bawić, to tylko wybij sloty z hasłami via luksKillSlot i dodać do /etc/crypttab parametr:
header=/boot/header1.img
Ja jednak poszedłem dalej i rozmontowałem nagłówek LUKS i tam jest coś takiego:
Refers to LUKS On-Disk Format Specification Version 1.2.1 LUKS header: offset length name data type description ----------------------------------------------------------------------- 0x0000 0x06 magic byte[] 'L','U','K','S', 0xba, 0xbe 0 6 0x0006 0x02 version uint16_t LUKS version 6 3 0x0008 0x20 cipher-name char[] cipher name spec. 8 32 0x0028 0x20 cipher-mode char[] cipher mode spec. 40 32 0x0048 0x20 hash-spec char[] hash spec. 72 32 0x0068 0x04 payload-offset uint32_t bulk data offset in sectors 104 4 (512 bytes per sector) 0x006c 0x04 key-bytes uint32_t number of bytes in key 108 4 0x0070 0x14 mk-digest byte[] master key checksum 112 20 calculated with PBKDF2 0x0084 0x20 mk-digest-salt byte[] salt for PBKDF2 when 132 32 calculating mk-digest 0x00a4 0x04 mk-digest-iter uint32_t iteration count for PBKDF2 164 4 when calculating mk-digest 0x00a8 0x28 uuid char[] partition UUID 168 40 0x00d0 0x30 key-slot-0 key slot key slot 0 208 48 0x0100 0x30 key-slot-1 key slot key slot 1 256 48 0x0130 0x30 key-slot-2 key slot key slot 2 304 48 0x0160 0x30 key-slot-3 key slot key slot 3 352 48 0x0190 0x30 key-slot-4 key slot key slot 4 400 48 0x01c0 0x30 key-slot-5 key slot key slot 5 448 48 0x01f0 0x30 key-slot-6 key slot key slot 6 496 48 0x0220 0x30 key-slot-7 key slot key slot 7 544 48
Sloty wyczyściłem luksKillSlot'em, a pozostałe rzeczy via:
dd if=/dev/zero of=/dev/sdb2 bs=1 seek=6 count=162
Ale ja to jestem paranoik. xD
Offline
Nigdzie nie napisałem, że moje rozwiązanie jest genialne :D
Ale jak dla laika to chyba jest nieco lepsze niż 'standard' :)
Co rozumiesz przez odseparowanie /boot? Bo generalnie od ładnych kilku lat używam /boot na osobnym woluminie. A aktualnie systemowy dysk wygląda tak:
/dev/mapper/sda5_crypt: 148,6 GiB /dev/mapper/crypt_lvm-root: 46,6 GiB /dev/mapper/crypt_lvm-swap: 1,9 GiB /dev/mapper/crypt_lvm-home: 100,2 GiB
Jak był dawno temu drugi taki sam dysk to lvm'em spiąłem całą pojemność z /home pierwszego. Obecnie tyle się ostało :D
To co mówisz później to już nie jest dla mnie takie oczywiste, ale chyba sam byłeś w tym miejscu co ja więc wiesz o co chodzi :D
Jeszcze z 7 lat temu byłbym w stanie nad tym siedzieć i...być takim 'paranoikiem' w dobrym tego słowa znaczeniu :D ale dziś to już nie ma czasu i mobilizacji :]
Jak dla mnie, jest lepiej ale nigdzie nie powiedziałem że to twierdza :D
No chyba że masz gotowe How-to albo jak bywało kiedyś na irc - prowadzisz wykłady :D
Pozdro
Ostatnio edytowany przez BlackEvo (2016-02-25 22:45:47)
Offline
Co rozumiesz przez odseparowanie /boot? Bo generalnie od ładnych kilku lat używam /boot na osobnym woluminie.
No chodzi o to byś podłączył pendrive do kompa, zamontował jego jedną partycję w katalogu /boot/ . Uzupełnił odpowiednio wpisy w fstab, zainstalował w /boot/ bootloader i wio. xD Zaszyfrowany system bez odpowiednio konfiguracji, która jest w initrd nie podniesie się, a te obrazy initrd są właśnie w katalogu /boot/ . xD
W sumie to masz do ogarnięcia 2 polecenia: luksHeaderBackup i luksKillSlot . No i dopisanie parametru z odpowiednią ścieżką w /etc/crypttab. No i wygenerowanie nowego initramfs. To nie jest trudne. xD
Offline
morfik napisał(-a):
By otworzyć taki system, potrzeby jest pendrive skąd będzie czytana konfiguracja bootloadera. Po jej wczytaniu, zostaną przeczytane nagłówki LUKS, które również są na penie. Po tym, jak system wystartuje, można partycję boot odmontować, a pena wyciągnąć. xD
Co zrobisz jak padnie Ci ten pendrive? Jaką masz drogę odzyskania tych danych :)?
Offline
Po tym, jak system wystartuje, można partycję boot odmontować, a pena wyciągnąć. xD
A po co w ogóle montowanie /boot? Podczas bootowania nie jest to potrzebne
Offline
Nie no bez jaj, rzeczywiście niezaszyfrowany /boot to jest tak jakby nie bylo w ogóle szyfrowania?
To po co w ogóle opcja szyfrowania z oddzielonym /boot w instalatorze?
Offline