W dobie całego tego świata informatycznego zwykliśmy polegać na osobach, których nigdy w życiu na oczy nie wiedzieliśmy, nie wspominając o jakimkolwiek kontakcie fizycznym. Zaufanie to obecnie chyba najbardziej krytyczna luka bezpieczeństwa jeśli chodzi o oprogramowanie, z którego korzystamy na co dzień. My, którzy używamy debiana w swojej pracy, polegamy na mechanizmach jakie oferuje nam apt czy aptitude przy weryfikacji pakietów przed ich instalacją w systemie. Co się jednak by stało gdyby w tych menadżerach pojawił się błąd, który by uniemożliwiał poprawną weryfikację pakietów? Skąd wiemy czy te mechanizmy zabezpieczające w ogóle działają? Może one nam dają jedynie fałszywe poczucie bezpieczeństwa, a tak naprawdę przez niczym nas nie chronią? W tym wpisie postaramy się odpowiedzieć na te powyższe pytania i sprawdzimy czy manualna weryfikacja pakietu jest w ogóle możliwa

Obecnie systemy operacyjne stają się nieco bardziej stabilne i czasy, w których reinstalacja takiego systemu, czy też nawet format dysku, odchodzą powoli w niebyt. Data instalacji mojego linux'a wskazuje na prawie 2 lata wstecz. Jakby nie patrzeć jest to szmat czasu, w czasie którego przez mojego Debiana przetoczyła się ogromna ilość oprogramowania. Nie zawsze były to pakiety, które pochodziły z głównych repozytoriów tej dystrybucji. Niemniej jednak, każde repozytorium z pakietami jest podpisane i by móc z nich bezpiecznie korzystać, trzeba pozyskać klucz GPG i dokonać jego weryfikacji. Prędzej czy później przyjdzie czas, gdy takie klucze GPG przestaną być ważne lub też zmianie ulegną źródła pakietów. W ten sposób baza danych kluczy zawierać będzie szereg zbędnych pozycji. Może wielu ludziom nie przeszkadza ten fakt ale raz na jakiś czas przydałoby się oczyścić keyring ze śmieci, które są już nam do niczego niepotrzebne.

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.

Bardzo wielu ludzi nie uświadamia sobie faktu, że w przypadku komputerów praktycznie wszystkie dane, z którymi mamy styczność, są zapisane za pomocą dwóch znaków, tj. 0 i 1. Mając to na względzie, nie ma chyba informacji, której by nie można było przesłać przez sieć. Serwer dźwięku, jak sama nazwa wskazuje, jest w stanie odbierać dane zawierają informacje dźwiękowe. Dlatego też jeśli jakiś komputer nie posiada karty muzycznej lub/i nie jest fizycznie podłączony do głośników, to nie stanowi to większego problemu by był on w stanie odtwarzać dźwięk, przynajmniej w tym sensie jakim my to rozumiemy. W tym wpisie sþróbujemy zrealizować przesyłanie dźwięku przez sieć wykorzystując do tego PulseAudio i zobaczymy czy sprawi nam to jakieś problemy.

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.

Na debianie Xserver domyślnie ma wyłączoną możliwość nasłuchiwania połączeń zdalnych. Chodzi oczywiście o kwestie bezpieczeństwa, bo przecie nie od dziś wiadomo, że akurat to oprogramowanie jest dziurawe jak sito i nikt rozsądny nie chciałby instalować go na swoim serwerze. Należałoby jednak rozgraniczyć wykorzystywanie podatności jakiegoś oprogramowania od możliwości wejścia z nim w interakcję. Jakby nie patrzeć, sam Xserver posiada co najmniej trzy mechanizmy ochrony, a do tego dochodzą jeszcze reguły iptables , czy też pliki /etc/hosts.allow i /etc/hosts.deny . Prawdopodobnie jest ich jeszcze kilka ale te najczęściej wykorzystywane mechanizmy gdy pojawia się słowo Xserver, to -nolisten tcp (domyślnie aktywowany), xhost oraz xauth . Pierwszy z nich wyklucza się z pozostałymi i to tym dwóm ostatnim przyjrzymy bliżej w tym wpisie.

Mechanizmy xhost oraz xauth w żaden sposób nie zabezpieczają informacji przesyłanych do Xserver'a. Wobec czego, całą komunikację można bez problemu podsłuchać. Stwarza to zagrożenie przechwycenia nie tylko obrazu wyświetlanego na monitorze ale także danych dotyczących myszy i przyciskanych klawiszy na klawiaturze.

Każdy kto zmienił architekturę systemu z i386 na amd64 raczej nie dostrzegł większej różnicy w operowaniu na którejś z nich. Czasem jedynie pakiety w nazwie mają 64 zamiast 32. Jest natomiast jedna rzecz, która drażni chyba każdego. Mowa tutaj o projekcie Wine. Wine nie umie obsługiwać natywnie serwera dźwięku PulseAudio. Do tego dochodzi jeszcze problem, który związany jest z tymi wszystkimi pakietami 32 bitowymi, które trzeba zainstalować. I w ten sposób nasz system staje się bardziej multiarch niż amd64. W tym wpisie postaramy się przy pomocy kontenera LXC odizolować Wine od całej reszty systemu operacyjnego, tak by nie musieć wgrywać do niego całej masy zbędnych bibliotek.

Kontenery LXC mają za zadanie odizolować poszczególne usługi od pozostałej części systemu. LXC jest podobny nieco do maszyn wirtualnych, np. tych tworzonych przez VirtualBox. Niemniej jednak, oba mechanizmy różnią się trochę. Zasadnicza różnica między nimi polega na tym, że LXC wykorzystuje środowisko chroot , w którym współdzielone jest jądro operacyjne. Nie trzeba także z góry określać zasobów pod działanie takiego kontenera, tak jak to ma w przypadku maszyn wirtualnych. Rzućmy zatem okiem jak wygląda konfiguracja takich kontenerów na linux'ie.

Ogromna większość ludzi korzysta z jednego profilu swojej przeglądarki internetowej. Niesie to ze sobą spore zagrożenie bezpieczeństwa jak i może godzić w naszą prywatność. Jeśli dzielimy z kimś komputer, to raczej wszyscy domownicy posiadają osobne konta w systemie, a co z tym się wiąże, inny profil przeglądarki. I na tym zwykle podział się kończy ale przecie to nie wszystko. Profil, jak sama nazwa wskazuje, jest w stanie dostosować opcje przeglądarki, np. pod kątem pewnych aktywności. W tym wpisie postaramy się utworzyć kilka profili w Firefox'ie i sprawdzimy korzystanie z nich będzie odczuwalne w jakiś sposób dla przeciętnego użytkownika internetu.

SysRq (System Request) to klawisz na klawiaturze, po którego przyciśnięciu można wysłać niskopoziomowe zapytana bezpośrednio do kernela linux'a. Te komendy działają nawet w przypadku pozornego braku kontaktu z systemem operacyjnym, tj. zacięcia dźwięku, nieruchomy kursor myszy, a nawet w przypadku braku możliwości wpisywania znaków z klawiatury. Zwykle po opisanych wyżej symptomach, człowiek jest skłonny przycisnąć przycisk reset na obudowie swojego komputera, no bo jak inaczej odwiesić taki system? Problem z twardym resetem (za pomocą przycisku) jest taki, że praktycznie zawsze po nim występuje uszkodzenie struktury systemu plików na dysku, a czasami uszkodzeniu ulega cała partycja. To niesie ze sobą ryzyko utraty danych. Dlatego też powinniśmy zaprzestać resetowania komputerów przy pomocy przycisków i zacząć korzystać z klawisza SysRq .