Pewnego niezbyt pamiętnego dnia byłem zmuszony skorzystać z windowsa. Po chwili pracy na nim, musiałem odejść od komputera na dłuższą chwilę. Chciałem zatem wyłączyć monitor bez jednoczesnego wyłączania całego komputera, czy przełączania go w stan uśpienia. Problem na jaki się natknąłem był taki, że kompletnie nie miałem pojęcia jak tego dokonać i ostatecznie zakończyło się to przyciśnięciem fizycznego przycisku na obudowie monitora. Gdybym tego nie zrobił, monitor by się wyłączył sam ale dopiero po pewnym czasie, który został określony w opcjach zarządzania energią. Nie miałem za bardzo czasu i chęci szukać rozwiązania tego problemu ale z tego co widziałem na necie, to ludzie rozpisywali jakieś tutorale na ten temat, co wydało mi się co najmniej dziwne. Czy w windowsie nie nie ma żadnej opcji by wyłączyć w prosty sposób monitor? Najwyraźniej nie ma, przynajmniej ja jej nie znalazłem. Czy my na linux'ie też mamy takie problemy? W tym wpisie postaramy się odpowiedzieć na pytanie czy jest jakiś prosty sposób by na linux'ie wyłączyć monitor z wiersza poleceń, tak by efekt był praktycznie natychmiastowy.

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.