Operowanie na linux'ie wiąże się w dużej mierze z wpisywaniem poleceń do terminala. Każdy kto spędził trochę czasu w tym systemie, wie, że do komfortowej pracy potrzebny jest przyzwoicie skonfigurowany shell. Domyślnym shell'em w debianie, jak i wielu innych linux'ach, jest bash. Każdy z nas na początku wpisywał wszystkie polecenia ręcznie i nawet nie wiedział, że istnieje coś takiego jak uzupełnianie pewnych fraz, czy też nazw, przy pomocy klawisza Tab . Z czasem nasz stopień poznania jakiejś dystrybucji linux'a osiąga pewien dość zaawansowany poziom i wpisywanie za każdym razem tych samych poleceń jedynie spowalnia naszą pracę. Dlatego właśnie bash, podobnie jak i inne shell'e, mają swoje pliki konfiguracyjne, w których to możemy dostosować naprawdę sporo rzeczy. W tym wpisie skupimy się na historii poleceń, która trafia do pliku .bash_history w katalogu domowym każdego użytkownika w systemie.

Ostatnio opisywałem jak zaimplementować na swoim serwerze mechanizm port knocking'u , który oparty był o Single Packet Authorization. Tamten wpis dotyczył głównie wykorzystania szyfrów symetrycznych ale istnieje też możliwość skorzystania z kluczy GPG. W ten sposób uwierzytelnianie oraz szyfrowanie pakietów odbywałoby się przy ich pomocy. W tym wpisie postaramy się tak skonfigurować narzędzie fwknop , tak by było ono w stanie przepuszczać jedynie tych klientów, którzy posługują się kluczami GPG.

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).