Kluczową rolę w filtrze iptables pełnią stany połączeń. Zwykle mamy do czynienia z trzema z nich: NEW, RELATED i ESTABLISHED. Wszystko co nie pasuje do tych stanów, jest traktowane jako INVALID i tak dla przykładu trafiają tam pakiety mające niemożliwe kombinacje flag, przynajmniej jeśli chodzi o punkt widzenia poprawnej komunikacji sieciowej (ustawione flagi SYN i FIN jednocześnie). Jednak istnieje szereg pakietów, które mogą potencjalnie zagrażać bezpieczeństwu maszyny i nie są one uwzględnione w stanie INVALID. Takie pakiety są używane do skanowania portów w celu wykrycia usług znajdujących się na serwerze. Krótko mówiąc, stan INVALID nie złapie skanów UDP, ACK oraz SYN . Czy jesteśmy faktycznie bezbronni i nic nie możemy zrobić? Na szczęście iptables ma do dyspozycji moduł xt_recent, który jest w stanie zablokować wszystkie te powyżej wymienione formy ataków.

Port knocking zezwala na zdalny dostęp do usług, które są chronione za pomocą zapory sieciowej. Generalnie rzecz biorąc, iptables ma blokować jakikolwiek ruch na porcie, na którym nasłuchuje jakaś demon. Oczywiście tym sposobem żaden klient nie mógłby nawiązać połączenia z serwerem i tutaj właśnie znajduje zastosowanie knockd , który jest w stanie dodawać dynamicznie odpowiednie reguły do filtra iptables. Nawiązywanie połączenia trwa z reguły bardzo szybko. Po tym jak klient uzyskał dostęp do serwera, te dodane wcześniej reguły są usuwane blokując tym samym wszelkie nowe próby połączenia ale nie odcinając jednocześnie ustanowionych już połączeń. Ten wpis ma jedynie na celu zaprezentowanie narzędzia knockd . Niemniej jednak, jest ono już przestarzałe i powinno się od niego odchodzić na rzecz Single Packet Authorization, czyli alternatywnego port knocking'u.

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.