Osoby, które wykorzystują pełne szyfrowanie dysku, wiedzą, że nie zawsze da radę tak skonfigurować swój system, by upchnąć go na jednej partycji. Nawet jeśli korzystamy z LVM wewnątrz kontenera LUKS, to i tak zwykle możemy posiadać inne zaszyfrowane partycje, które są odrębną całością i montowane osobno przy starcie systemu. W takim przypadku zwykle jesteśmy zmuszeni do podawania hasła do każdego z tych dysków z osobna, co zajmuje czas. Ten problem opisałem po części przy okazji implementacji kontenera LUKS na potrzeby Dropbox'a, jak i we wpisie poświęconym przejściu z kontenerów TrueCrypt'a na te linux'owe, które są wspierane natywnie przez sam kernel. Niemniej jednak, tamto rozwiązanie było oparte głównie o starszy init (sysvinit), co wymagało dodatkowej konfiguracji, tak by system otworzył się po podaniu tylko jednego hasła. W tym wpisie postaramy się wdrożyć mechanizm, który jest oferowany przez systemd.

PulseAudio to serwer dźwięku, który jest w stanie otrzymywać zapytania ze zdalnych lokalizacji. Wobec czego, możemy realizować przesyłanie dźwięku przez sieć i usłyszeć go tam, gdzie go sobie życzymy. Problem w tym, że taki dźwięk jest przesyłany przez sieć w formie niezaszyfrowanej. Dlatego też jesteśmy narażeni na podsłuchanie wszystkiego co mówimy do mikrofonu lub też tego co pojawia się w naszych głośnikach. Możemy jednak zabezpieczyć komunikację między klientem i serwerem dźwięku wykorzystując do tego połączenie SSH. W ten sposób cały sygnał dźwiękowy, jaki jest generowany przez danego hosta w sieci, zostanie wrzucony w szyfrowany kanał TLS i nikt nie będzie w stanie go zinterpretować. Ten wpis ma na celu przedstawienie sposobu na zaszyfrowanie dźwięku, bez którego większość z nas nie wyobraża sobie pacy przy komputerze.

W przypadku zaufanych sieci lokalnych, czy też kontenerów LXC, nie musimy zbytnio się troszczyć o bezpieczeństwo przesyłanych danych. Nikt nam przecież nie założy tutaj podsłuchu. Dlatego też we wpisie poświęconym konfiguracji Wine nie szyfrowaliśmy praktycznie żadnego ruchu sieciowego. Gdyby jednak zaszła potrzeba przesłania pakietów do zdalnego Xserver'a przez internet, to takie rozwiązanie naraziłoby nas na przechwycenie wszystkich danych. By zabezpieczyć się przed tego typu scenariuszem możemy zaszyfrować ruch do Xserver'a forward'ując wszystkie zapytania przy pomocy szyfrowanego tunelu TLS. Możemy to zrobić przy pomocy SSH i w tym wpisie postaramy się skonfigurować ten mechanizm.

Wykorzystywanie pełnego szyfrowania dysku twardego ma jedną zasadniczą wadę. O ile nasze dane są należycie zabezpieczone, o tyle trzeba zwracać uwagę na to komu zezwalamy na dostęp do naszego komputera. Nie chodzi tutaj o to, kto będzie używał samego systemu operacyjnego, choć to też jest ważne, ale przede wszystkim chodzi o te osoby, które mają dostęp fizyczny do naszej maszyny. Czasem możemy nabrać podejrzenia, że ktoś mógł nam jakąś pluskwę podłożyć. Wykrycie takiego robala, np. w postaci sprzętowego keylogger'a, nie powinno sprawić problemów. Z kolei już manipulacja boot sektorem dysku twardego, lub też zmiany w initramfs, który znajduje się na niezaszyfrowanej partycji /boot/ mogą przejść niezauważone. Jak zatem odratować system, co do którego mamy jakieś zastrzeżenia?

Ogarnęliśmy już szyfrowanie plików na Dropbox przy pomocy encfs oraz kontenerów TrueCrypt. Każda z w/w operacji drastycznie poprawiła prywatność naszych plików, które przechowujemy w chmurze. Poniższy wpis będzie w podobnym klimacie, tj. spróbujemy umieścić na Dropbox kontener LUKS, co niesie ze sobą sporo udogodnień i czyni korzystanie z zaszyfrowanego Dropbox'a praktycznie transparentnym.

Żyjemy w czasach, w których mobilność jest tak samo ważna albo może i ważniejsza (dla niektórych ludzi na pewno) jak i bezpieczeństwo i poufność danych. Użyteczność zwykle nie idzie w patrze z bezpieczeństwem, bo im prostszy jest dla nas dostęp do danych, tym bardziej zagraża ich bezpieczeństwu. W tym przypadku chcielibyśmy mieć możliwość dostępu do plików, np. naszego domowego PC, z dowolnego miejsca na ziemi. Czy można w prosty i w miarę bezpieczny sposób coś takiego osiągnąć? Jakiś czas temu opisywałem implementację encfs na dropbox'ie, w tym artykule zostanie zaś opisane sprzęgnięcie dropbox'a z kontenerem TrueCrypt.

Jakiś czas temu, można było usłyszeć, że TrueCrypt nie dba wcale o bezpieczeństwo danych zaszyfrowanych za jego pomocą. Audyt bezpieczeństwa jednak nie wykazał większych podatności w tym oprogramowaniu. Analiza binarek dostępnych na stronie TrueCrypt'a pod kątem Reproducible Builds również nie wykazała większych odchyłów w stosunku do binarek generowanych prosto z kodu źródłowego. Problematyczne może być jednak to, że tak naprawdę nie wiadomo kto stoi za tym całym projektem, przynajmniej gdy był jeszcze rozwijany. Cała sytuacja zamknięcia TrueCrypt'a z sieci była też co najmniej dziwna. W obliczu takich niewiadomych, powinniśmy rozważyć przejście na natywne rozwiązania linux'owe, które są jawnie rozwijane, wiadomo kto za nimi stoi i, co najważniejsze, mają wsparcie w samym kernelu.

Jako, że ostatnio zaszyfrowaliśmy katalog domowy przy pomocy encfs , to nie sposób sobie nie zadać pytania czy tego typu mechanizm może działać w oparciu o serwisy online takie jak, np. dropbox. Chodzi o to, że dropbox umożliwia synchronizację plików w czasie rzeczywistym, co może być problematyczne, gdy w grę wchodzi szyfrowanie danych. Wszelkie inne rozwiązania na bazie LUKS są mało praktyczne w tym przypadku. Natomiast synchronizowanie pojedynczych plików zaszyfrowanych przy pomocy encfs zapowiada się obiecująco.

Opisując mechanizm szyfrowania katalogu domowego przy pomocy narzędzia encfs , wspomniałem o problemie jaki powstaje przy jednoczesnym braku szyfrowania przestrzeni wymiany SWAP. Oczywiście, jeśli posiadamy w systemie dużą ilość pamięci RAM, to raczej nie potrzebna nam jest przestrzeń wymiany. Podobnie sprawa ma się w przypadku, gdy nie korzystamy z hibernacji. Natomiast, jeśli jedna z naszych partycji jest sformatowana jako SWAP i aktywnie z niej korzystamy, to niepełne szyfrowanie dysku, jakie zapewnia encfs może doprowadzić do skompromitowania zaszyfrowanych danych.

Wielu ludzi uważa, że szyfrowanie całego dysku jest zbędne i pozbawione większego sensu, no bo przecie "system nie zawiera żadnych wrażliwych danych, które by wymagały szyfrowania". Nie będę się tutaj spierał co do tego punktu widzenia, bo raczej wszyscy znają moje zdanie na temat "danych wymagających szyfrowania" i skupię się tu raczej na tym jak troszeczkę podratować niepełne szyfrowanie, które ludzie, nie wiedząc czemu, są bardziej skłonni stosować, niż cały ten full disk encryption.

Narzędzie encfs nie przeszło pomyślnie audytu bezpieczeństwa, a to z takiego powodu, że projekt nie był rozwijany przez szereg lat. Obecnie jest on w rekach społeczności i to od niej będzie zależeć czy te wykryte błędy zostaną poprawione.