Obecnie najpopularniejszym rozwiązaniem pod kątem ograniczania dostępu do usług systemowych jest zapora sieciowa. Reguły iptables są w tym przypadku wręcz niezastąpione. Jednak poleganie na samych regułach iptables nie jest zbyt dobrym pomysłem. A to z tego względu, że jeśli skrypt firewall'a z jakiegoś powodu nie zostanie wywołany przy starcie systemu, to nasza maszyna pozostaje praktycznie bezbronna i będzie akceptować wszelkie próby połączeń do wszystkich nasłuchujących w takim systemie usług. Na szczęście nie jest znowu aż tak źle jak mogłoby się wydawać. Albowiem linux posiada dwa pliki /etc/hosts.allow i /etc/hosts.deny , które są w stanie zarządzać dostępem do usług systemowych. Poniższy wpis będzie poświęcony właśnie tym dwóm plikom.

Poniższy wpis ma na celu zaprezentować jak w prosty sposób dozbroić nieco serwer, tak by znajdujące się na nim usługi były należycie chronione. Zostanie to pokazane na przykładzie SSH, bo chyba każdy serwer posiada zdalny dostęp przez shell'a i za bardzo nie godzi się by zostawić tę usługę otwartą na zewnętrzny świat wirtualny bez jakiegokolwiek nadzoru. Postaramy się tutaj wdrożyć port knocking, z tym, że nie będziemy wykorzystywać do tego celu narzędzia knockd . Skorzystamy za to z fwknop , który eliminuje szereg wad występujących w leciwym już knockd .

Aktualizacje systemu niosą ze sobą nowsze wersje pakietów. Czasami mają one błędy, które wychodzą na jaw po jakimś czasie korzystania z danej aplikacji. W takiej sytuacji zwykle zachodzi potrzeba cofnięcia wersji kilku pakietów. Jest jednak wielce prawdopodobne, że akurat tej wersji pakietu, której potrzebujemy, nie znajdziemy z repozytorium debiana. Pobieranie pojedynczych pakietów z internetu przez klikanie w pierwszy lepszy link, który zostanie nam zwrócony przez wyszukiwarkę, nie jest dobrym pomysłem. Na szczęście w przypadku debiana nie musimy się aż tak narażać. A to z tego względu, że debian robi migawki (shapshots) swoich repozytoriów 4 razy dziennie (co 6 godzin). W ten sposób mamy dostęp do różnych stanów repozytoriów, w tym też tych, które zawierają pakiety aktualnie niedostępne w repozytoriach. W tym wpisie postaramy się pobrać i zainstalować nieistniejące pakiety z takich snapshot'ów.

Wielu ludzi nie lubi gdy maszyny monitorują każdy ich krok. W tym przypadku chodzi o pliki, które otwieramy czy zmieniamy podczas codziennej pracy na komputerze. Nasz system domyślnie tworzy listę i skrupulatnie dodaje do niej nowe pozycje. Ta lista jest przechowywana w pliku recently-used.xbel , który znajduje się w katalogu ~/.local/share/ . Gdy popatrzymy na tę funkcjonalność trochę pod inny kątem, możemy zauważyć, że w pewnych sytuacjach zagraża ona naszej prywatności. Skasowanie tego pliku nie rozwiązuje problemu, bo jest on tworzony na nowo, a nadawanie atrybutu odporności ( chattr +i ) nie jest żadnym rozwiązaniem. Na szczęście jest sposób na to by ten mechanizm dezaktywować i o tym będzie poniższy wpis.

W przypadku, gdy dzieją się dziwne rzeczy z naszym linux'em i ten zaczyna sypać niezrozumiałymi dla nas błędami, to zawsze możemy takie zachowanie uwiecznić na zrzucie ekranu. Co jednak w przypadku, gdy nawali nam środowisko graficzne i nie będziemy mieli jak zrobić zrzutu? Przecie takie aplikacje jak scrot czy też shutter działają w oparciu o Xserver i bez niego nie zrobią fotki naszego desktop'a. Zwykle gdy zmuszeni jesteśmy ratować nasz system, robimy to w konsoli TTY. No chyba, że sprawa jest poważniejsza, wtedy sięgamy po system live . Logi systemowe czy też aplikacji mogą okazać się pomocne ale przecie "fotka jest warta więcej niż tysiąc słów". Jak zatem zrobić zrzut ekranu mając do dyspozycji jedynie tekstową konsolę TTY? Czy jest to w ogóle możliwe?

Posiadając nowszej klasy procesor, jesteśmy w stanie korzystać z 64 bitowego systemu operacyjnego. W przypadku windowsów uruchamianie aplikacji 32 czy 64 bitowych nie stanowi większego problemu. W na debianie sprawa wygląda nieco inaczej. Gdy mamy wgranego 64 bitowego debiana, aplikacje 32 bitowe nie będą chciały się nam odpalić. Wszystkiemu winne są biblioteki 32 bitowe, które są wykorzystywane przez dany program, a bez nich on zwyczajnie nie może działać. Jednym z rozwiązań tego problemu może być kontener LXC, gdzie jesteśmy w stanie zainstalować 32 bitowy system wewnątrz środowiska 64 bitowego i to z tego systemu możemy uruchamiać 32 bitowe aplikacje. Skonfigurowanie takiego kontenera może być nieco skomplikowane, dlatego też dużo lepszym rozwiązaniem jest przerobienie naszego 64 bitowego systemu na muliarch, czyli taki, który jest w stanie obsługiwać wiele architektur (multiarch).

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.