Od czasu do czasu w logu systemowym mojego Debiana można zanotować szereg pakietów przychodzących, które są zrzucane przez linux'owy firewall (nftables/iptables ). Po krótkiej analizie okazało się, że są to pakiety protokołu TCP mające stan NEW (czyli są to nowe połączenia) ale niezawierające przy tym flagi SYN . Mój laptop nie ma aktualnie przydzielonego zewnętrznego routowalnego adresu IPv4/IPv6, więc nasunęło się pytanie o przyczynę takiego stanu rzeczy -- przecie będąc za NAT, nikt spoza sieci nie powinien być w stanie nawiązać połączenia z moją maszyną, a ewidentnie co się do jej bram dobija i to nie z adresu lokalnego. Niby mam też odfiltrowane pakiety w stanie INVALID (np. te mające niepoprawny zestaw flag) ale widać te pakiety, o których mowa, nie zaliczają się do tego stanu, więc wygląda na to, że wszystko z nimi jest w porządku. Czy tego typu pakiety TCP w stanie NEW niemające ustawionej flagi SYN stanowią jakieś zagrożenie dla naszego komputera? Czy powinno się je zablokować, a może przepuścić w filtrze pakietów? A jeśli zablokować, to czy zwykły DROP wystarczy czy może powinno się te pakiety potraktować przy pomocy REJECT ?

Ostatnio przeglądając nowe wpisy na forach trafiłem na pytanie o podział dysku pod instalację linux'a. Autorowi wątku chodziło o jak najlepszy podział dysku HDD ale najwyraźniej pogubił się on w tym całym bałaganie informacyjnym, który tyczy się procesu partycjonowania nośnika pod kątem jego optymalnego wykorzystania przez linux. Zagadnienie podziału dysków HDD/SSD nie jest zbytnio jakoś skomplikowane, a mimo to wciąż pojawiają się pytania o poprawne przeprowadzenie tego procesu i to pomimo faktu, że mamy obecnie już dość sporych rozmiarów dyski. To pytanie powoli przestaje mieć jakikolwiek sens, przynajmniej jeśli chodzi o przeciętnego Kowalskiego instalującego linux'a u siebie na kompie (desktop/laptop). Postanowiłem jednak napisać parę słów na temat tego całego podziału dysku na partycje, tak by dobrać optymalny ich rozmiar przy instalowaniu dowolnej dystrybucji linux'a.

Użytkownicy Debiana często w roli firewall'a wykorzystują już dość leciwy iptables . W zasadzie, to tej implementacji linux'owego filtra pakietów sieciowych nic nie dolega, no może poza szeregiem wad konstrukcyjnych, które są obecnie tak ciężkie do zaadresowania, że w sumie trzeba by cały ten iptables napisać od początku. Wszystko przez rozwój internetu, za sprawą którego pojawiło się zapotrzebowanie na tworzenie całej masy reguł (w postaci adresów/portów źródłowych/docelowych), gdzie w standardowym iptables trzeba tworzyć osobne wpisy. Im więcej reguł w filtrze, tym przechodzenie pakietów przez zaporę sieciową trwa dłużej i wiąże się z mocnym obciążeniem dla procesora (zwłaszcza, gdy tych reguł jest kilkadziesiąt tysięcy). By jakoś uporać się z tymi problemami (nieznanymi w innych filtrach sieciowych) stworzono ipset . I faktycznie odciążył on mocno procesor maszyny ale i tak nie wyeliminował on podstawowych wad iptables . Dlatego też zaczęto szukać innego rozwiązania i tak pojawiła się alternatywa m.in. w postaci nftables . W przyszłym stabilnym Debianie (buster) nftables będzie wykorzystywany jako domyślny filtr pakietów i ci, który korzystali z ipset mogą się nieco zdziwić, że nftables nie posiada dla niego wsparcia. Rzecz w tym, że nftables potrafi natywnie obsługiwać listy adresów/portów i ipset nie jest mu w tym do niczego potrzebny.

Ostatnio na Niebezpieczniku pojawił się artykuł na temat niezbyt przyjaznych urządzeń podłączanych do komputera za sprawą portów USB (opisanych na przykładzie niepozornego przewodu) i tego jaką szkodę tego typu hardware może nam wyrządzić w systemie. Ataki z wykorzystaniem podstawionych urządzeń zadziałają nawet na linux, choć pewnie cała masa użytkowników wyznaje jeszcze mit, że ich komputer jest bezpieczny, bo przecie używają alternatywnego systemu operacyjnego, który jest OpenSource i za priorytet obrał sobie szeroko rozumiane bezpieczeństwo. Niestety nie jest tak różowo jakby mogło się co niektórym wydawać ale można ten stan rzeczy naturalnie zmienić i nie trzeba przy tym rekompilować kernela z zamiarem wyłączenia obsługi modułu USB, co ten opisany w podlinkowanym artykule atak oczywiście by również powstrzymało. Zamiast tego możemy zainstalować sobie narzędzie usbguard i przy jego pomocy skonfigurować politykę podłączanych do portów USB urządzeń.

Jakiś czas temu postanowiłem przetestować sposób zamknięcia graficznych aplikacji w kontenerze Docker'a. Całe rozwiązanie zostało opisane na przykładzie skonteneryzowania przeglądarki Firefox. Ten opisany w podlinkowanym artykule pomysł był nawet całkiem przyzwoity ale nie nadaje się on, gdy w grę wchodzą programy odtwarzające dźwięk. No może to za dużo powiedziane, że się nie nadaje, ale z pewnością brakuje mu jednego istotnego elementu. Nawet ta przykładowa przeglądarka internetowa jest w stanie odtwarzać dźwięki jeśli się odwiedzi stosowną stronę WWW. Standardowo jednak nic nie usłyszymy w głośnikach, gdy odpalimy dajmy na to stronę YouTube i puścimy jakiś materiał video. Dlatego też wypadałoby skonfigurować dźwięk i przesłać go do serwera PulseAudio, który będzie odpalony na naszym linux'owym hoście. Kiedyś już tego typu rozwiązanie nawet opisywałem na przykładzie zintegrowania PulseAudio z kontenerami LXC. Okazuje się, że tamto rozwiązanie znajduje również zastosowanie w przypadku Docker'a. Trzeba tylko nieco inaczej skonfigurować kontener i właśnie tej kwestii będzie dotyczył niniejszy wpis.

Zgodnie z informacją, która pojawiła się już ponad pół roku temu, dystrybucje linux'a powoli zaczynają odchodzić od iptables . Prawdopodobnie w niedługim czasie iptables zostanie już całkowicie wyparty i zastąpiony przez nftables , przynajmniej jeśli chodzi o desktopy. Nawet Debian zakomunikował, że następne wydanie stabilne tej dystrybucji (Buster) będzie domyślnie wykorzystywało nftables . Wypadałoby zatem się przenieść na ten nowy framework i przygotować sobie kilka podstawowych reguł firewall'a, które zabezpieczoną naszą maszynę przed nieautoryzowanym dostępem z sieci.

Przenosząc swoje reguły z iptables na nftables zauważyłem, że jedna z nich (gdyby tylko jedna) nie została przetłumaczona przez ten dedykowany translator do reguł. Chodzi o mechanizm SYNPROXY, który jest zwykle wykorzystywany do ograniczenia skali ataków DDOS z wykorzystaniem pakietów SYN. Co by nie mówić, to ochrona jaką daje SYNPROXY jest jak najbardziej pożądana z perspektywy serwerów. Dlaczego zatem, gdy się zajrzy na stronę wspieranych rzeczy w nftables, to przy SYNPROXY widnieje bliżej nieokreślone sformułowanie consider native interface ? Po rozmowach z deweloperami udało się ustalić, że ten zapis oznacza brak wsparcia dla SYNPROXY w nftables . Jeśli zatem ktoś wykorzystuje ten mechanizm mając dodane stosowne reguły w iptables , to czy powinien się on obawiać przejścia na nftables ?

Połączenie z internetem, z którego ostatnio przyszło mi korzystać, nie należało zbytnio do tych najbardziej wydajnych pod względem prędkości przesyłu danych. O ile szybkość transferu można by jeszcze przemilczeć, to owe łącze nie należało też do tych najstabilniejszych i czasem kontakt ze światem był zwyczajnie zrywany. Krótko rzecz ujmując, ten net nadawał się chyba jedynie do przeglądania stron WWW. Pech jednak chciał, że potrzebowałem zassać na takim połączeniu repozytorium git'a z patch'ami Debiana nakładanymi na kernel linux'a. To repozytorium nie należy do największych ale też do małych ono się nie zalicza -- waży około 2 GiB. Oczywiście można by zrobić jedynie płytki klon takiego repo za sprawą git clone --depth=1 , co skutkowałoby pobraniem plików w wersji z ostatniego commit'a, co z kolei zredukowałoby w znacznym stopniu wielkość pobieranych danych (parę-paręnaście MiB). Co jednak zrobić w przypadku, gdy musimy sklonować sporych rozmiarów repozytorium git, a dysponujemy przy tym dość wolnym połączeniem sieciowym? Czy jest to w ogóle możliwe, bo przecież git nie ma zaimplementowanej opcji wznawiania przerwanej synchronizacji i każde zakłócenie tego procesu skutkować będzie tym, że całe repozytorium trzeba będzie pobrać jeszcze raz i to bez względu na to, czy proces się zawiesi zaraz na początku, czy też pod koniec operacji.

Protokół IPv6 został opracowany już dość dawno temu, a jednak ilość hostów w internecie komunikujących się za jego pomocą wciąż nie jest zbyt wysoka i oscyluje w granicach 25%. Faktem jest, że migracja z IPv4 na IPv6 może być sporym kosztem dla niektórych podmiotów jeśli chodzi o kwestię związaną z wymianą sprzętu i ze zmianą konfiguracji sieci, co pewnie zniechęca część ISP do wdrożenia tego protokołu. Użytkownicy korzystający z sieci z kolei nie wiedzieć czemu też preferują IPv4 nad IPv6. Jakiś czas temu czytałem nawet artykuł na temat zagrożenia prywatności jakie może nieść ze sobą protokół IPv6. Chodzi generalnie o to, że obecnie wszyscy przywykliśmy do rozwiązania jakie oferuje nam NAT, które jest w stanie utrudnić nieco naszą identyfikację i analizę naszej aktywności w internecie. W przypadku IPv6 adresy IP są dość unikatowe w skali globalnej, a część odpowiedzialna za identyfikację hosta (ostatnie 64 bity) stanowi identyfikator EUI64, który z kolei jest generowany na podstawie adresu MAC karty sieciowej. W taki oto sposób interfejs tej karty będzie miał stały identyfikator EUI64, a hosta będzie można zidentyfikować bez problemu i bez względu na to u którego ISP podłączymy nasz komputer. Rozwiązaniem tego problemu jest mechanizm zwany IPv6 Privacy Extensions. Przydałoby się zatem rzucić na niego okiem i jeśli okaże się użyteczny, to wypadałoby go włączyć w naszym Debian Linux.

Konfigurując filtr pakietów iptables/nftables na Debianie zwykle nie przykładamy większej wagi do procesów, które chcą nawiązać połączenia wychodzące z naszego linux'owego hosta. Mamy przecież "skonfigurowany" firewall w łańcuchach INPUT i FORWARD i wszelkie zagrożenia z sieci nie powinny nas dotyczyć. Problem w tym, że jeśli jakiś złowrogi proces zostanie uruchomiony w naszym systemie, to jest on w stanie komunikować się ze światem zewnętrznym praktycznie bez żadnych ograniczeń za sprawą braku jakichkolwiek reguł w łańcuchu OUTPUT . Można oczywiście temu zaradzić budując zaporę sieciową na bazie cgroups , gdzie każda aplikacja będzie miała oznaczone pakiety, przez co będzie można je rozróżnić i zablokować albo przepuścić przez filter. W tym wpisie jednak nie będziemy się zajmować konstrukcją tego typu FW, tylko spróbujemy sobie odpowiedzieć na pytanie jak namierzyć proces, który komunikuje się z siecią (lub też próbuje), posiadając jedynie log iptables/nftables .