Wszyscy wiemy, że ogromna rzesza ludzi nie patrzy w logi systemowe. Nawet jeśli części z nas zdarza się to raz na jakiś czas, to zwykle nie wtedy, gdy coś złego się dzieje z naszym systemem. W przypadku jakichkolwiek problemów, mamy spore prawdopodobieństwo, że szereg zdarzeń może zostać zalogowanych w dzienniku systemowym. Dlaczego zatem nie osadzić jakiegoś terminala na pulpicie, w którym będą zbierane logi w czasie rzeczywistym? W takim przypadku co kilka (czy kilkanaście) minut będziemy w stanie podejrzeć wszystkie komunikaty jakie zostały zalogowane przez system. W tym wpisie postaramy się osadzić na pulpicie terminal urxvt i posłużymy się w tym celu menadżerem okien openbox .

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.