Każdy terminal jest w stanie wyświetlić tekst w kilku kolorach. Zwykle mamy ich do dyspozycji 8 lub 16. Niektóre terminale potrafią rozróżniać nawet 256 kolorów. Niemniej jednak, kolor całego tekstu jaki jest wyświetlany w terminalu jest zwykle jednolity i nie ma w nim praktycznie żadnych urozmaiceń. W taki sposób mamy czarny tekst i białe tło. Jako, że te terminale są w stanie wyświetlić więcej kolorów, to dla większej czytelności przydałoby się skonfigurować kolorowanie wyjścia takich narzędzi jak ls , grep czy man . Jesteśmy w stanie pokolorować także szereg innych rzeczy i o tym będzie ten poniższy wpis.

Bash nie nadaje się dla nieco bardziej zaawansowanych użytkowników linux'a. Najbardziej odczuwalnym elementem bash'a jest brak uzupełniania poleceń za pomocą klawisza Tab . Nie mówimy tutaj o przeszukiwaniu zmiennej $PATH pod kątem dopasowań pliku wykonywalnego do tego co wpisujemy aktualnie w terminalu. Nie chodzi też o uzupełnianiu ścieżek podawanych do cd ale o opcje, które jakiś program może przyjąć jako argument. Zwykle musimy się uczyć ich na pamięć lub zaglądać do help'a czy manuala. Możliwe jest jednak skorzystanie z dodatku zwanego bash completion, który w sporej części przypadków potrafi dostarczyć dość zaawansowane uzupełnianie poleceń, którymi się posługujemy na co dzień. Ten wpis ma na celu pokazanie jak włączyć ten cały mechanizm i uprościć sobie nieco życie podczas pracy w terminalu.

Jakiś czas temu opisywałem konfigurację historii bash'a w pliku .bash_history ale możliwości konfiguracyjne bash'a nie ograniczają się jedynie do zmiany kilku parametrów czy zmiennych dotyczących historii wpisywanych w terminalu poleceń. Ten wpis ma na celu zebranie tych bardziej użytecznych funkcjonalności bash'a, które często są wykorzystywane przez użytkowników linux'a i dopisywane w pliku .bashrc .

Podczas uruchamiania się systemu, na ekranie zwykle widzimy szereg komunikatów. Informują nas one o tym jakie usługi są aktywowane oraz czy wystąpiły jakieś błędy. Po tym jak faza boot dobiegnie końca, wszystkie te informacje dalej są wyświetlane na konsoli TTY i możemy je podejrzeć po przyciśnięciu klawiszy Ctrl-Alt-F1 . W pewnych sytuacjach może to stwarzać zagrożenie bezpieczeństwa, bo są tam zawarte informacje o tym jakie usługi zostały uruchomione. Przydałoby się zatem wyczyścić tę konsolę TTY po załadowaniu się systemu i o tym będzie poniższy wpis.

Po przesiadce z sysvinit na systemd okazało się, że system inaczej się zachowuje po przyciśnięciu kombinacji klawiszy Ctrl-Alt-Del . Niby za wiele nie zmieniałem w konfiguracji systemu ale w żaden sposób przy pomocy plików konfiguracyjnych nie szło zmienić zachowania tego powyższego skrótu. Okazuje się bowiem, że w systemd, akcję pod ten skrót przypisuje się w nieco innym miejscu niż to było robione w sysvinit. W tym wpisie postaramy się zmienić domyślne zachowanie tego skrótu, tak by po jego przyciśnięciu wyłączyć komputer.

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.