Pełne szyfrowanie Ubuntu

[markii]

W jaki sposób najlepiej całkowicie zaszyfrować Ubuntu? Chodzi mi o szyfrowanie wszystkich dysków i partycji na nich (w tym /, /home, swap, innych partycji (w tym pod NTFS)?
Na HDD jest tylko i wyłącznie Ubuntu (nie ma dwóch OSów).
Rozwiązanie ma być bezproblemowe w eksploatacji i nie upierdliwe w użytkowaniu.

Pod Windowsem wystarczającym i sprawdzającym się w praktyce rozwiązaniem jest TrueCrypt (szyfrowanie partycji systemowej+wszystkich innych partycji z automontowaniem przy starcie systemu).


Jak to rozwiązać pod Ubuntu?

[sj65]

http://www.linuxbsdos.com/2011/05/10/ho ... le-system/
Warto się zastanowić czy partycji boot nie stworzyć np na penrive albo drugim dysku.
W ten sposób raczej nie czy da się zaszyfrować partycji ntfs.


Przećwicz dostęp do zaszyfrowanych plików z wersji live na wypadek tfu, tfu jakiejś awarii.

Pozdrawiam

[infort]

Jako, że sam korzystam z tego rozwiązania, to garść uwag, może sie komuś przydadzą.

1. Jedyną rozsądną metodą pełnego zaszyfrowania dysku w Ubuntu jest użycie płyty Alternate w sposób podany w linku powyżej - istnieje metoda zaszyfrowania już istniejącego systemu ale to raczej nie dla początkujących, a szansa że coś pójdzie źle jest duża. Tym samym najpierw kopia danych a potem instalacja i partycjonowanie na nowo.

2. Konieczna jest partycja /boot (niezaszyfrowana). Resztę partycji tworzymy na zaszyfrowanym wolumenie LVM. Z przyczyn praktycznych lepiej jest utworzyć jeden taki wolumen.

3. Zaszyfrowany system nie chodzi wolniej niż niezaszyfrowany (na przeciętnym sprzęcie). Dostęp do partycji zaszyfrowanej z Ubuntu Live-CD jest możliwy po zainstalowaniu pakietu LVM2, bezproblemowo.

4. Problem pojawia się przy aktualizacji systemu do nowej wersji. Upgrade jest bez większych problemów, natomiast instalowanie na czysto skutkuje albo skasowaniem starych partycji(!) - wersje 11.04 lub wcześniejsze, albo niemożnością uruchomienia systemu (dane są bezpieczne) - ciągle nienaprawiony błąd w 11.10. Do wersji 12.04 miejmy nadzieję wszystko będzie działać zadowalająco.

5. Szyfrowanie LUKS umożliwia ustalenie więcej niż jednego hasła a także możliwość uruchomienia za pomocą klucza USB. Korzystając z tej ostatniej możliwości, ZAWSZE ustalmy też alternatywne hasło bo przy uszkodzeniu lub zgubieniu klucza nie dostaniemy się już więcej do danych.

6. Obecność Windowsa na dysku w niczym nie przeszkadza szyfrowanemu Linuksowi. Istnieje możliwość zaszyfrowania go Truecryptem a Linuxa LUKSem i działa to świetnie. Do partycji Windowsowych dostajemy się wtedy przez Truecrypt. W drugą stronę jest problem, bo o ile szyfrowanie LUKS jest rozpoznawane przez FreeOTFE, o tyle z LVM to raczej sobie nie poradzi.

[Lord_J]

Witam. Chciałem ustawić nowe konto z ustawieniami standardowymi i szlag mnie trafił gdy zobaczyłem że nie tylko nie dodało nowego konta, ale zmieniło mi moje konto na standardowe i teraz root nie przyjmuje mi mojego hasła . Czy wszystko musi być w ubuntu takie skomplikowane? Dlaczego nie ma opcji "ustaw nowe konto" ? Tylko trzeba dokonywać kosmicznych ewolucji żeby wykonać tak prostą czynność? Jak to można cofnąć?

[gesnet]

2. Konieczna jest partycja /boot (niezaszyfrowana). Resztę partycji tworzymy na zaszyfrowanym wolumenie LVM. Z przyczyn praktycznych lepiej jest utworzyć jeden taki wolumen.

Ja bym radził /boot i GRUBA trzymać osobno, czyli nie na dysku gdzie jest OS.

[infort]

Ja bym radził /boot i GRUBA trzymać osobno, czyli nie na dysku gdzie jest OS.

A można wiedzieć dlaczego? W laptopach (a tu pełne szyfrowanie ma największe zastosowanie) zwykle jest jeden dysk. Więc trzeba by używać pamięci USB co komplikuje sprawę uruchamiania komputera. Dla samego systemu nie ma to znaczenia gdzie jest Grub, bo do danych można sie dostać (znając hasło) z LiveCD, zresztą szyfrując dysk tylko idiota nie robi kopii. Więc jedynie względy bezpieczeństwa informacji wchodzą w grę, pytanie tylko jakie. Jedyne co mi przychodzi do głowy to obrona przed atakiem typu 'Evil maid'. Jednakże, jeśli ktoś ma na dysku dane na tyle istotne, by podejmowano przeciwko niemu takie próby, to używa dodatkowej linii obrony. W typowym przypadku to raczej sensu nie ma.

[gesnet]

bo do danych można sie dostać (znając hasło) z LiveCD,

Hasło da się złamać. Lepszy key

Kod: Zaznacz cały

I decided on the key size now. How do I protect the key?

Protecting the key is vital: With it the attacker does have instant access to the data. So what can be done to protect this crucial string of bits?

    You can use a "one-time key" that is changed at each startup. These keys are usually created by reading /dev/Xrandom during dm-crypt setup. No key is stored this way and no passphrase needed, but this method can only be used on filesystems that can be formated at each reboot (like swap or maybe /tmp if you do not want to retain the information stored there). Using suspend to disk will be impossible with one-time keys used on the swap device.
    You can store the key on removable storage. That way it is only accessible when needed. Your data is in the open when the storage is stolen or copied.
    You can generate a hash value (== a pseudorandom number) from a keyphrase and use that as a key. The key is not stored on media that way at all, but you can not change the passphrase (a different key is generated then). All people with access to the encrypted data need to know this passphrase. This is a bit impractical in a multi user environment.
    You can encrypt the key. The encrypted key is stored on the computer with the encrypted device. You can change the passphrase by reencrypting the key with a different one and you can have several copies of the same key encrypted for several people.
    You can encrypt the key and store it on a removeable media.
    You can use smartcards, etc. This is the most secure option. 

W typowym przypadku to raczej sensu nie ma.

Zgadza się.

[infort]

Hasło da się złamać. Lepszy key

No to się zdecyduj. Albo potrzebujesz pendrive po to by tam zainstalować Grub - sens tego jest żaden poza obroną przed atakiem Evil maid, albo zamiast hasła używasz pendrive jako klucza - wtedy Grub zostaje na dysku twardym.

Co do przewagi klucza nad hasłem... W typowym przypadku tak, jeśli ktoś używa haseł typu "Misiek1". Ale jeśli masz dobre hasło, to klucz sprzętowy nie ma już tej przewagi - można go zgubić, ukraść, skopiować, mogą ci go zabrać przy przeszukaniu... A do podania hasła w tym ostatnim przypadku nie można cię zmusić (zasada Nemo tenetur se ipsum accusare).

Łamanie haseł to mit. Jeśli wiesz jak wybrać dobre, długie hasło, to metoda brute force nic nie da. Pozostaną ataki socjotechniczne, podstęp, szantaż, wreszcie użycie siły. A wtedy, czy masz klucz czy hasło, jego wartość jest taka sama.

[pioruns]

@infort:
Daj spokój, komu Ty to tłumaczysz. Ten facet nie wie, jak się instaluje Firefoksa w Ubuntu... A zabiera się za tora, gentoo i szyfrowanie systemów.

Jak ktoś zamierza robić coś nielegalnego lub bardzo poufnego to nie ma sensu szyfrować całego systemu/dysku, bo od razu będzie wiadomo, że coś tam ukrywamy i będzie albo zastosowana groźba i szantaż przez napastnika, albo sąd na nas wymusi podanie hasła/klucza pod groźbą kary i odpowiedzialności (nie wiem jak jest w Polsce, ale w wielu europejskich krajach można zostać skazanym, jeśli jest się o coś podejrzanym i się nie poda hasła).
Lepiej zrobić kontener podwójny Truecrypt (tzn. istnieje drugi ukryty kontener w jednym) i wrzucić tam tylko to, co jest poufne. Jeśli nazwiemy kontener TC bardzo niepozornie i ukryjemy wśród innych podobnych plików, to duża szansa, że nikt się nie domyśli przeznaczenia danego pliku (np. o rozszerzeniu .iso albo hiberfile.sys) Zawsze można się wyprzeć, że nie wiemy co to za plik. Oczywiście trzeba dbać o brak jakiejkolwiek historii w systemie, TC, edytorze plików, programie multimedialnym i tak dalej.

[infort]

nie wiem jak jest w Polsce, ale w wielu europejskich krajach można zostać skazanym, jeśli jest się o coś podejrzanym i się nie poda hasła

Są kraje gdzie rzeczywiście nie obowiązuje pełne prawo do obrony (Wielka Brytania jest tego najlepszym przykładem). Ale w Polsce każdy podejrzany może odmówić zeznań lub odpowiedzi na dowolne pytanie i nie pogarsza to jego sytuacji prawnej. To fundament wywodzący się jeszcze z prawa rzymskiego.

Lepiej zrobić kontener podwójny Truecrypt (tzn. istnieje drugi ukryty kontener w jednym) i wrzucić tam tylko to, co jest poufne. Jeśli nazwiemy kontener TC bardzo niepozornie i ukryjemy wśród innych podobnych plików, to duża szansa, że nikt się nie domyśli przeznaczenia danego pliku (np. o rozszerzeniu .iso albo hiberfile.sys) Zawsze można się wyprzeć, że nie wiemy co to za plik. Oczywiście trzeba dbać o brak jakiejkolwiek historii w systemie, TC, edytorze plików, programie multimedialnym i tak dalej.

To dobra metoda. Co prawda na podstawie entropii pliku można podejrzewać, że coś jest kontenerem truecrypta, udowodnić jednak tego nie sposób. Jedno małe ale... ci, którzy wiedzą o co grają sobie poradzą, natomiast reszta zawsze zostawi jakieś ślady w systemie. Ilu z nas ma /tmp albo /var/log na ramdysku? Co prawda analiza systemów linuxowych nie jest ulubioną rozrywką naszych biegłych i niewielu jest tak zdeterminowanych by chciało im się szukać zbyt głęboko. Zwłaszcza jak nie wiedzą czego.

Na szczęście 99% ludzi szyfruje dane po to, by nie wpadły w niepowołane ręce w razie kradzieży, a nie dlatego, że są przestępcami. I takim zawsze warto pomóc to ogarnąć. Nawet jeśli to będą tylko prywatne zdjęcia, to nie ma powodu by ktoś miał do nich dostęp.

[pioruns]

Na szczęście 99% ludzi szyfruje dane po to, by nie wpadły w niepowołane ręce w razie kradzieży, a nie dlatego, że są przestępcami. I takim zawsze warto pomóc to ogarnąć. Nawet jeśli to będą tylko prywatne zdjęcia, to nie ma powodu by ktoś miał do nich dostęp.

W takim razie tym 99% ludzi wystarczyło by trzymać plik .zip z hasłem z prywatnymi zdjęciami:) Pełne szyfrowanie systemu, co jest tematem tego wątku, to, można by powiedzieć, biznesowy, korporacyjny cel - normalnemu Kowalskiemu się to niezbyt przyda:) To porywanie się z motyką na Słońce.

[gesnet]

Ilu z nas ma /tmp albo /var/log na ramdysku?

Niewiele to pomoże jak masz szyfrowanie.

-- 24 lis 2011 19:43 --

Jak ktoś zamierza robić coś nielegalnego lub bardzo poufnego to nie ma sensu szyfrować całego systemu/dysku, bo od razu będzie wiadomo, że coś tam ukrywamy

Masz rację, najlepiej, ku wzbudzeniu powszechnego szanowania społecznego i wzbudzeniu zaufania, rzecz jasna, iść na księdza do seminarium. Co najwyżej zostaniemy posądzeni o gwałcenie czy molestowanie dzieci, ewentualnie o jakie sprzeniewierzenie kasy z funduszu kościelnego.

Spec się znalazł

[sj65]

Dziwne, że jeszcze administrator tu się jeszcze nie wtrącił.
Ten wątek przemienił się w "dlaczego szyfrować" i kto to robi lepiej, albo dlaczego gorzej. Wracając do sedna.

Zamykamy drzwi do mieszkania, do samochodu.
Roweru nie zostawiamy na ulicy bez zabezpieczenia.
Piwnice też zamykamy.
Zaklejamy listy i zabezpieczamy paczki.
Popatrzcie nawet banki zamykają i pieniądze przechowują w sejfach.
Spróbujcie dostać się do Jaśnie Panującego nam tu lub tam.
Wszyscy się zabezpieczają, tylko nam nie wolno, bo to tylko uczciwi nic nie mają do ukrycia. Czyżby ci w pałacach nie byli uczciwymi?
Sami stworzyliśmy mit, że jak coś ukrywamy to jesteśmy przestępcami.
Dzisiaj służby mogą wejść, bo uznają że coś udostępniliśmy przez np. Deluge.
Czy w związku z tym mają oglądać prywatne fotki które znajdą na dysku, lub próby literackie. Nie daj Boże, by zakwalifikowali te treści jako wywrotowe lub mające związki z grupami terrorystycznym.
Czyżbyśmy się nadal z Szuflandii wydostawali?


Dlaczego nie szyfrujemy przesyłek elektronicznych i umożliwiamy grzebanie po dysku?
Mówi o bezpieczeństwie, ale czy kto kasuje logi w swoim systemie.
Czy ktoś czyści raz na jakiś czas wolne miejsca na dysku.
A co robicie z dostępnymi danymi w uszkodzonych sektorach dysku. Tam w nieuszkodzonej części mogą być hasła lub coś co z czego można wysnuć całą spiskową teorie na temat waszej naszej twojej czy mojej wrogiej działalności do systemu.
A to forum i wszystkie inne, czy tak trudno o połączenie bezpieczne. Jak ładnie by wyglądało https://ubuntu.pl/.

Pozdrawiam

[zovalik]

Dzisiaj zabieram się za szyfrowanie całej instalacji Ubuntu.

Mam więc pytania. Jak wygląda potem kwestia dostępu do zaszyfrowanych danych? Wyjmuję dysk z laptopa wsadzam do kieszeni i podłączam pod Windowsa/Ubuntu. Z tego co doczytałem to pod Ubuntu nie będzie problemu z odczytem danych jednak pod Windowsem nie da rady tego ruszyć, tak?

Jak takie szyfrowanie ma się do dysków SSD? Są jakieś przeciwwskazania?
Jak ma się wydajność takiego rozwiązania, spowalnia to system w stosunku do "normalnej" instalacji?

[soulreaver1]

Dzisiaj zabieram się za szyfrowanie całej instalacji Ubuntu.

Mam więc pytania. Jak wygląda potem kwestia dostępu do zaszyfrowanych danych? Wyjmuję dysk z laptopa wsadzam do kieszeni i podłączam pod Windowsa/Ubuntu. Z tego co doczytałem to pod Ubuntu nie będzie problemu z odczytem danych jednak pod Windowsem nie da rady tego ruszyć, tak?

Sposób odczytu zaszyfrowanych danych zależy od rozwiązania jakie zastosujesz. W każdym razie na innym komputerze z linuxem odczytasz dane, o ile oczywiście znasz hasło i dysk nie jest uszkodzony. Pamiętaj że każde uszkodzenie hdd jest znacznie groźniejsze dla danych na zaszyfrowanym dysku (mała niespójność może uniemożliwić odczyt całości). Radzę robić regularny backup np. rsync-em po ssh na serwer z szyfrowanym raidem .

Jak takie szyfrowanie ma się do dysków SSD? Są jakieś przeciwwskazania?

Nie powinno mieć to żadnego wpływu na żywotność ssd ponieważ dane szyfrowane/deszyfrowane są w pamięci ram.

Jak ma się wydajność takiego rozwiązania, spowalnia to system w stosunku do "normalnej" instalacji?

Pracuje już kilka dni na pełnym szyfrowaniu dysku w Fedorze 17 (lvm + LUKS) i nie zauważyłem spadku wydajności w porównaniu do niezaszyfrowanego, jest znacznie szybciej niż w przypadku szyfrowania samego /home za pomocą ubuntowego ecryptfs.

[zovalik]

Mam zamiar szyfrować lvm + LUKS ofc, z alternate cd.

Jako, że tych naprawdę ważnych danych nie mam za dużo to szyfruje je i wrzucam w chmurę (dla bezpieczeństwa w kilka, dropbox, box, ubuntuone, dysk google) no i oczywiście na innym HDD. Może trochę paranoiczne podejście ale jakoś nie mam do końca zaufania co do stabilności chmury

EDYTA: Jest jakiś limit na ilość wpisania błędnego hasła? Co się wówczas dzieje?

[infort]

Jest jakiś limit na ilość wpisania błędnego hasła? Co się wówczas dzieje?

Nie ma, więc nic sie nie dzieje. Jeśli myślisz o filmowych rozwiązaniu typu: po trzech błędnych hasłach dane ulegają skasowaniu to cię zmartwię - nie istnieje żadne gotowe rozwiązanie i chyba nikt nad takim czymś nie pracuje... Oczywiście da się coś takiego napisać samemu i nawet nie jest to trudne, wystarczy zamazać nagłowek LUKS i po danych, ale moim zdaniem to bez sensu. Na 99,9% sam sobie zrobisz krzywdę przez pomyłkę, a jak ktoś spróbuje profesjonalnie podejść do łamania hasła, to zrobi cyfrową kopię dysku i na niej będzie próbował.

Pod Windows da się oczytać szyfrowanie LUKSem w programie FreeOTFE (darmowy). Ale najpierw trzeba się uporać z woluminami lvm2, nie mam zielonego pojęcia czy Windows to ugryzie.

[xc1256]

Jako, że sam korzystam z tego rozwiązania, to garść uwag, może sie komuś przydadzą.


6. Obecność Windowsa na dysku w niczym nie przeszkadza szyfrowanemu Linuksowi. Istnieje możliwość zaszyfrowania go Truecryptem a Linuxa LUKSem i działa to świetnie. Do partycji Windowsowych dostajemy się wtedy przez Truecrypt. W drugą stronę jest problem, bo o ile szyfrowanie LUKS jest rozpoznawane przez FreeOTFE, o tyle z LVM to raczej sobie nie poradzi.

NSA.GOV i podobne jej agendy w kilka sekund dostają się do zaszyfrowanych danych za pomocą Truecrypta - tak na marginesie

[brezniew]

NSA.GOV i podobne jej agendy w kilka sekund dostają się do zaszyfrowanych danych za pomocą Truecrypta - tak na marginesie

A jakieś źródło tych informacji posiadasz? Czy po prostu miałeś taki odkrywczy sen?

[Milek999]

W jaki sposób mają ominąć zabezpieczenia opensourcowego programu? Nie dorzucą tam swojego kodu, więc jedyną możliwością jest złamanie hasła, ale to zadanie na kilka wieków.