Minęło już trochę czasu od momentu, w którym postanowiłem się przerzucić z iptables na nftables w swoim Debianie i w zasadzie większość mechanizmów obronnych mojego laptopowego firewall'a została już z powodzeniem przeportowana na ten nowy filtr pakietów. Poza tymi starymi regułami próbuję czasem ogarniać nieco bardziej wyrafinowane sposoby na unikanie zagrożeń sieciowych, choć implementacja niektórych rzeczy nie zawsze jest taka oczywista, z tym, że niekoniecznie niemożliwa do zrealizowana. Tak było w przypadku mechanizmu automatycznego blokowania hostów próbujących się łączyć z daną maszyną, która sobie najwyraźniej tego nie życzy. Dla przykładu, jest serwer udostępniający usługę SSH na porcie 11111 i tylko ten port jest wystawiony na świat. Wszelkiego rodzaju boty próbujące dostać się do maszyn linux'owych próbkują z kolei głównie standardowe porty, w tym przypadku 22 . Ci użytkownicy, którzy powinni mieć dostęp do usługi SSH, wiedzą na jakim porcie ona nasłuchuje. Można zatem założyć, że wszystkie połączenia na port 22 będą dokonywane przez boty albo przez użytkowników, którzy mają niecne zamiary. Wszystkie te połączenia można by zatem zablokować tworząc mechanizm automatycznego banowania hostów w oparciu o czas ostatniej próby połączenia, tak jak to zostało opisane mniej więcej w tym wątku na forum. Problem w tym, że tamto rozwiązanie dotyczy jedynie iptables w połączeniu z ipset , co nieco komplikuje wdrożenie go w przypadku nftables ale to zadanie jest jak najbardziej możliwe.

Obecnie nftables cierpi dość mocno z powodu pewnych problemów związanych z wydajnością przy aplikowaniu reguł zapory sieciowej. Niemniej jednak, w stosunku do iptables , nftables posiada tablicę netdev , która jest w stanie nieco zyskać w oczach tych nieco bardziej wybrednych użytkowników linux'a. Chodzi generalnie o fakt, że ta tablica jest umieszczona zaraz na początku drogi pakietów, tuż po odebraniu ich z NIC (interfejsu karty sieciowej), a biorąc pod uwagę fakt, że ruch sieciowy, który nigdy ma nie trafić do naszej maszyny, powinien być zrzucany jak najwcześniej (by nie marnować zasobów procesora i pamięci), to ta tablica wydaje się być idealnym miejscem by zablokować cały niepożądany ruch przychodzący. Przy wykorzystaniu iptables , takie pakiety zrzuca się w tablicy raw . Jeśli zaś chodzi o nftables , to zrzucanie pakietów w tablicy netdev jest ponad dwu lub nawet trzykrotnie bardziej wydajne (szybsze i mniej zasobożerne). Można zatem dość dobrze poradzić sobie z wszelkiego rodzaju atakami DOS/DDOS, np. ICMP/PING flood czy SYN flood. Zastanawiające może być natomiast ogarnięcie ataku UDP flood ale przed tym rodzajem ataku linux również jest w stanie się bez problemu ochronić.

W dzisiejszych czasach dystrybucje linux'a wykorzystują mechanizm sudo do wykonywania operacji jako administrator systemu. Zanika więc potrzeba stosowania polecenia su , by zalogować się na konto root i to z jego poziomu wykonywać wszystkie niezbędne rzeczy. Jednym z argumentów zwolenników sudo za takim sanem rzeczy jest możliwość nadania jedynie konkretnym użytkownikom w systemie uprawnień do wykonywania poleceń jako administrator, podczas gdy inni użytkownicy (niebędący w grupie sudo ) nie mogą w ogóle korzystać z tego mechanizmu . No faktycznie, dostęp do su jest w zasadzie dla każdego użytkownika w systemie i tylko hasło konta admina dzieli ich od uzyskania dość szerokich uprawnień. Niewiele jednak osób wie, że można skonfigurować su w taki sposób, by dostęp do niego mieli tylko ci użytkownicy, którzy powinni, np. ci obecni w grupie wheel .

Podczas rutynowego skanu powierzchni dysków HDD w moim laptopie, S.M.A.R.T wykrył w jednym z nich podejrzany blok, który zdawał się wyzionąć już ducha, przez co proces weryfikacji integralności powierzchni dysku twardego nie był w stanie zakończyć się z powodzeniem. Komunikat zwracany przy czytaniu padniętego sektora też był nieco dziwny: bad/missing sense data, sb[] . Jakiś czas temu już opisywałem jak realokować uszkodzony sektor dysku HDD i w zasadzie wszystkie informacje zawarte w tamtym artykule można by wykorzystać do próby poprawienia zaistniałego problemu, gdyby tylko nie fakt, że w tym przypadku badblock znalazł się w obszarze voluminu logicznego LVM na partycji zaszyfrowanej przy pomocy mechanizmu LUKS. Taki schemat układu partycji sprawia, że do realokowania błędnego bloku trzeba podejść nieco inaczej uwzględniając w tym procesie kilka offset'ów, bez których w zasadzie nic nie da się zrobić. Postanowiłem zatem napisać na konkretnym przykładzie jak realokować badsector dysku, gdy do czynienia mamy z zaszyfrowanym linux'em zainstalowanym na voluminach LVM.

Pisząc jakiś czas temu poradnik na temat budowania paczek .deb dla dystrybucji linux'a Debian, poruszyłem w nim kwestię związaną z aktualizacją paczki, która zawierała projekt utrzymywany w systemie kontroli wersji (CVS), np. git. Rozchodzi się tutaj o format źródeł. Do niedawna myślałem, że są w zasadzie dwa formaty (tych, z których się zwykle korzysta): 3.0 (native) oraz 3.0 (quilt) . Wszystkie moje pakiety budowane do tej pory miały ten drugi format. Podglądając ostatnio kilka paczek .deb , natrafiłem w jednej z nich na format źródeł 3.0 (git) . Okazuje się, że ten format jest w stanie bardzo łatwo ogarnąć projekty hostowane w takich serwisach jak GitHub, czy GitLab i można za jego sprawą nieco ułatwić sobie życie. Wypadałoby zatem rzucić na niego okiem i ocenić go pod kątem przydatności przy budowaniu pakietów dla Debiana.

Po wyjaśnieniu paru rzeczy w kwestii przestrzeni wymiany, a konkretnie [co jest lepsze: plik SWAP czy osobna partycja]({{ site.baseurl }}/post/czy-w-linux-plik-swap-jest-lepszy-niz-partycja-wymiany/), postanowiłem nieco zmienić układ partycji na dysku mojego laptopa (LUKS+LVM) i zaimplementować sobie przestrzeń wymiany w postaci pliku SWAP. Standardowo jednak plik SWAP nie działa w przypadku hibernacji linux'a i kernel ma problemy z wybudzeniem maszyny z głębokiego snu. Jeśli zamierzamy korzystać z hibernacji, to trzeba inaczej skonfigurować system, by nauczyć go korzystać z przestrzeni wymiany w postaci pliku. W tym artykule rzucimy sobie okiem na ten niezbyt skomplikowany proces.

Użytkownicy linux'a są zwykle chronieni przez mechanizmy bezpieczeństwa, które ten system jest w stanie zaoferować. Oczywiście deweloperzy różnych dystrybucji, np. Debiana, dokładają wszelkich możliwych starań, by system jako całość był wstępnie skonfigurowany tak, by końcowy użytkownik nie musiał za wiele majstrować przy zabezpieczeniach i mógł się czuć i być (przynajmniej względnie) bezpieczny. No i faktycznie złowrogie oprogramowanie ma czasem spore problemy dostać się do maszyny, którą operuje linux. Niemniej jednak, gdy już taki syf się do systemu dostanie, to zwykle niewiele dzieli go od przejęcia kontroli nad komputerem. Może i część zabezpieczeń linux'a zadziała i sprawi, że taki wirus/trojan czy nawet zwykły skrypt będzie miał ograniczone pole manewru, to i tak będzie on mógł przeprowadzić te akcje, które zwyczajny użytkownik systemu (nie root) jest zwykle w stanie poczynić, np. odebrać dźwięk i video ze stosownych urządzeń i przesłać te dane przez sieć. My z kolei możemy nawet tego faktu nie być świadomi. Jasne, że powinno się zwracać uwagę na to jakie pliki się pobiera z internetu i nie uruchamiać wszystkiego lekkomyślnie ale też trzeba mieć na uwadze fakt, że często jedna maszyna jest współdzielona, np. z członkami rodziny i oni już niekoniecznie muszą władać zaawansowaną wiedza z zakresu IT, by przewidzieć wszystkie możliwe zagrożenia czyhające na nich w sieci. Można za to postarać się, by uczynić naszą maszynę nieco bardziej odporną na niezbyt przemyślane zachowania użytkowników jej systemu operacyjnego. Jednym z kroków, które możemy podjąć, jest wdrożenie mechanizmu Trusted Path Execution (TPE), który póki co jest dostępny jedynie w formie patch'a na kernel linux'a lub też jako jego osobny moduł oferujący sporo więcej możliwości w stosunku do wspomnianej wcześniej łaty. W niniejszym artykule rzucimy sobie okiem na ten cały mechanizm TPE i zobaczymy jak jest on w stanie uchronić nasz OS przed niezbyt zaawansowaną ludzką inteligencją.

Ostatnimi czasy, z racji rozwoju technologicznego, mamy do dyspozycji coraz to szybsze komputery, co przekłada się w znacznym stopniu na prędkość wykonywania operacji przez ich systemy operacyjne. Obecnie przeciętnej klasy desktop czy laptop jest już wyposażony w 16G czy nawet 32G pamięci operacyjnej (w niedługim czasie nawet smartfony będą posiadać 12G RAM). Spada zatem zapotrzebowanie wykorzystania dysku twardego jako pamięci RAM. W linux używanie dysku twardego jako rozszerzenie pamięci operacyjnej było i jest w dalszym ciągu realizowane za sprawą przestrzeni wymiany SWAP. Ta przestrzeń wymiany może być zaimplementowana w postaci osobnej partycji dysku twardego albo też jako plik umieszczony w obrębie systemu plików, np. ext4. Część dystrybucji linux'a decyduję się na porzucenie partycji wymiany na rzecz pliku SWAP. Czy taki krok jest uzasadniony i czy korzystając aktualnie z partycji wymiany powinniśmy zmigrować na plik SWAP?

Przeglądając dzisiaj rano logi systemowe wpadł mi w oczy komunikat, którego treść brzmiała mniej więcej tak: e2scrub Volume group "wd_blue_label" has insufficient free space (0 extents): 64 required , po którym z kolei można zanotować e2scrub snapshot FAILED, will not check! oraz Failed to start Online ext4 Metadata Check for /media/Debian . Oczywiście ten punkt montowania to nazwa partycji odnosząca się do jednego z dysków logicznych struktury LVM. Skąd się te błędy wzięły? Przecież jeszcze do niedawna (przez ostatnich parę lat) wszystko z moim linux'em rezydującym na dysku (LUKS+LVM) było w porządku, a teraz nagle takie bardzo niepokojące błędy. Czym jest w ogóle ten e2scrub i czym jest ten cały Online ext4 Metadata Check , który najwyraźniej ma coś wspólnego ze sprawdzaniem systemu plików voluminów logicznych w locie? No i najważniejsze chyba pytanie -- czemu to nie działa jak należy?

Kernel linux'a jest dość złożonym organizmem, który może zostać rozbudowany przy pomocy dodatkowego kodu ładowanego w postaci zewnętrznych modułów. Czasem ze względu na wczesny etap prac nad nową funkcjonalnością jądra, taki moduł może zachowywać się dość nieprzewidywalnie, co przekreśla jego szanse na pojawienie się w stabilnych wydaniach kernela. Czasem też z jakiegoś niezrozumiałego powodu pewne rzeczy nie są celowo dodawane do jądra operacyjnego. Jedną z nich jest moduł Trusted Path Execution (TPE), który jest w stanie znacznie poprawić bezpieczeństwo systemu uniemożliwiając przeprowadzenie w nim szeregu podejrzanych działań. W Debianie tego typu niedogodności związane z brakiem pewnych modułów można obejść przez zastosowanie mechanizmu DKMS, który przy instalacji modułu spoza głównego drzewa kernela linux'a jest nam go w stanie automatycznie zbudować. W repozytorium dystrybucji Debiana znajduje się już szereg pakietów z modułami (mają końcówki -dkms ) i w prosty sposób można je sobie doinstalować. Co jednak w przypadku, gdy mamy moduł, którego nikt jeszcze nie przygotował i nie wrzucił do repozytorium? Co, gdy takich modułów mamy kilka, a przy tym korzystamy z najnowszego stabilnego kernela, który jest aktualizowany średnio co kilka dni? Ręczna budowa wszystkich zewnętrznych modułów za każdym razem jak tylko wyjdzie nowsza wersja kernela, to nie najlepsze wyjście, zwłaszcza jak dojdzie nam do tego aktualizacja samych modułów. Można za to zrobić sobie paczkę .deb tak, by przy instalacji nowego jądra operacyjnego, system nam automatycznie zbudował wszystkie dodatkowe moduły, których nasz komputer wymaga do poprawnej pracy.