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 .

W kontenerach Docker'a nie powinno się uruchamiać więcej usług niż jedna. Czasami jednak zachodzi potrzeba, by właśnie uruchomić kilka niezależnych od siebie procesów, które będą ze sobą współpracować w obrębie takiego pojedynczego kontenera. Weźmy sobie na przykład serwer WWW Apache2 i bazę danych MySQL/MariaDB. Każda z tych usług posiada swój dedykowany kontener (nawet oficjalny) i generalnie skonfigurowanie komunikacji między tymi dwoma kontenerami Docker'a nie jest niczym trudnym. Jeśli jednak ktoś by się uparł, to może stworzyć sobie taki kontener, który będzie uruchamiał obie te usługi. Oczywiście w tym przypadku raczej nikt nie będzie łączył tych dwóch kontenerów w jeden ale są pewne sytuacje, w których będziemy chcieli uruchomić więcej niż jeden proces wewnątrz kontenera i gdy ten czas nadejdzie, to wypadałoby wiedzieć jak się do tego przedsięwzięcia zabrać.

By wyłączyć komputer, jego system operacyjny musi pierw zatrzymać (lub też ubić siłowo) wszystkie działające usługi za wyjątkiem tego mającego PID z numerkiem 1. Zwykle proces zamykania się systemu Debian Linux nie trwa więcej niż parę sekund ale czasami pojawiają się dziwne problemy, które mogą to zadanie utrudnić lub też całkowicie uniemożliwić. Nawet jeśli system będzie się w stanie zresetować, to zanim to nastąpi, to na konsoli mogą pojawić się komunikaty mogące pomóc nam w zdiagnozowaniu dolegliwości, która doskwiera naszej maszynie. Problem w tym, że część tych wiadomości nie zostanie nigdy zalogowana do pliku, gdzie moglibyśmy ich poszukać. Dzieje się tak dlatego, że w pewnym określonym momencie zamykania się systemu trzeba wyłączyć usługę logowania, co zwykle widać w logu jako systemd-journald[]: Journal stopped . Gdy dziennik zostanie zatrzymany, żadna wiadomość, która od tego momentu pojawi się na ekranie, nie zostanie już zalogowana do pliku. Jeśli teraz pojawią nam się ostrzeżenia lub błędy, a po chwili komputer się zresetuje, to możemy mieć nie lada problem z ustaleniem przyczyny mimo, że system nam ją zgłasza. Przydałoby się zapisać te komunikaty, tylko jak to zrobić, skoro usługa logowania jest już nieaktywna?

Bawiąc się ostatnio na Debianie przestrzeniami nazw sieciowych, wpadł mi do głowy pomysł na nieco bardziej zautomatyzowaną formę separacji procesów użytkownika od pozostałej części systemu. Co by nie mówić, opisany w podlinkowanym artykule sposób uruchomienia Firefox'a niezbyt mi przypadł do gustu. Nowy sposób separacji zakłada za to wykorzystanie kontenerów Docker'a, w których to będzie uruchamiany dowolny proces, np. Firefox, a całym przedsięwzięciem związanym z procesem konteneryzacji będzie zajmował się już Docker. W ten sposób uruchomienie dowolnej aplikacji, w tym też tych graficznych (GUI), będzie sprowadzać się do wydania w terminalu tylko jednego polecenia. Zatem do dzieła.

Bawiąc się ostatnio kernelem linux na dystrybucji Debian i opcjami mającymi poprawić jego bezpieczeństwo, włączyłem sobie mechanizm podpisywania modułów. W ten sposób żaden zewnętrzny moduł nie zostanie załadowany przez jądro operacyjne, no chyba, że taki moduł będzie podpisany przez ten sam klucz co i kernel. Zdziwiłem się odrobinę, gdy moim oczom pokazał się hash md4 w wyjściu polecenia modinfo . Jak się okazało później, to niezbyt dokładne zinterpretowanie wiadomości PKCS#7 przez kmod było (i nadal jest) wynikiem błędu obecnego w tym pakiecie od już paru lat. W efekcie modinfo nie jest w stanie zweryfikować tej sygnatury, a w moim umyśle zaistniało pytanie: czy istnieje w ogóle możliwość manualnego sprawdzenia czy ta sygnatura jest w porządku? Kernel co prawda ten cały zabieg przeprowadza automatycznie ale przydałoby się ręcznie zweryfikować poprawność sygnatury modułu i przy okazji obadać sobie co tak naprawdę się dzieje podczas tego procesu.

Domyślnie każdy proces uruchomiony na linux (w tym przypadku Debian) dziedziczy swoją przestrzeń nazw sieciowych (network namespaces) od procesu nadrzędnego, standardowo od procesu init (tego z pid 1). W takim przypadku, wszystkie procesy współdzielą tę samą przestrzeń nazw sieciowych, przez co mają dostęp do tych samych interfejsów sieciowych, tych samych tras routingu, a reguły firewall'a czy ustawienia serwerów DNS w jednakowym stopniu dotyczą wszystkich procesów i zmieniając sieciową konfigurację systemu robimy to globalnie dla wszystkich tych procesów jednocześnie. Czasami tego typu mechanika działania sieci nie jest zbyt pożądana z punktu widzenia bezpieczeństwa lub też prywatności użytkownika. Przykładem mogą być przeglądarki internetowe, np. Firefox, Opera czy Google Chrome/Chromium, które mogą zdradzić nasz lokalny adres IP (w przypadku stosowania NAT). Jako, że też zostawiamy wszędzie nasz namiar w postaci zewnętrznego adresu IP, to oba te adresy mogą nas bez większego problemu zidentyfikować w internecie. Można jednak postarać się, by ten adres lokalny, który zwróci przeglądarka internetowa, różnił się od tego, który przydziela nam nasz operator ISP.

Budując kernel linux'a trzeba zastanowić się nad kwestią modułów, które nie są wbudowane bezpośrednio w samo jądro operacyjne. Nie chodzi tutaj bezpośrednio o funkcjonalność kernela, którą można zbudować jako moduł w procesie jego kompilacji ale raczej o wszystkie zewnętrzne moduły, które przez zespół kernela są traktowane jako out-of-tree . By poprawić nieco bezpieczeństwo związane z takimi modułami, można wdrożyć podpisy cyfrowe, które takie moduły muszą okazać podczas próby załadowania ich w systemie. Gdy moduł nie został podpisany, to kernel go nie załaduje zwracając przy tym błąd modprobe: ERROR: could not insert 'module': Required key not available . W ten sposób można ochronić się przed częścią ataków, w których moduły pochodzenia trzeciego mogą zostać załadowane i poczynić nam ogromne spustoszenie w systemie. Problem w tym, że w dystrybucji Debian wykorzystywany jest mechanizm DKMS (Dynamic Kernel Module Support). Może i mamy dzięki niemu możliwość instalacji w systemie całej masy dodatkowych modułów ale ich również nie będzie można załadować, bo nie zostały podpisane kluczem, którego certyfikat został zaszyty w kernelu. Można jednak zmusić mechanizm DKMS, by wskazane przez nas moduły podpisywał automatycznie przy ich instalacji i aktualizacji.

Każda maszyna działająca pod kontrolą dystrybucji linux ma na swoim pokładzie kernel, czyli jądro operacyjne, które zarządza praktycznie każdym aspektem pracy takiego komputera. W dystrybucji Debian, kernel jest dostarczany w pakietach mających nazwy zaczynające się od linux-image-*. Te pakiety są budowane przez odpowiednie osoby z zespołu Debiana i udostępniane do łatwej instalacji użytkownikowi końcowemu. Niemniej jednak, taki kernel ma za zadanie działać na jak największej ilości komputerów, a przez to posiada całą masę modułów, które na naszej maszynie nigdy nie będą wykorzystane. Ten fakt nie wpływa w jakimś ogromnym stopniu na pracę maszyny, ale gdy później zachodzi potrzeba skonfigurowania kernela w nieco inny sposób, np. włączenie jednej czy dwóch opcji czy też nałożenie patch'a, który nie został zaaplikowany przez dev'ów Debiana, to trzeba taki kernel na nowo skompilować już samodzielnie, a to zajmie nam bardzo dużo czasu. Zamiast tego można pokusić się o przygotowanie kernela pod konkretny hardware wyłączając przy tym całą masę zbędnych rzeczy i ograniczając przy tym czas jaki jest potrzebny na zbudowanie całego jądra operacyjnego. Czy istnieje jakiś prosty sposób, by taki kernel zbudować sobie samemu mając przy tym minimalną wiedzę co do opcji kernela, które mogą nas przysporzyć o ból... głowy? Okazuje się, że tak i w tym artykule prześledzimy sobie cały ten proces.

Użytkownicy internetu mają całą masę różnych sposobów na komunikację miedzy sobą. Kiedyś wszyscy korzystali z komunikatorów typu Gadu-Gadu. Ja byłem jedyną osobą, która od samego początku wolała alternatywne rozwiązania i jechałem na komunikatorze Tlen (ten od O2), a w niedługim czasie przesiadłem się na Jabber'a i tak z niego korzystam do dziś. W zasadzie GG i Tlen są obecnie już chyba na wymarciu, bo większość ludzi (jak nie wszyscy) przerzuciła się na Facebook'a czy Twitter'a. Niemniej jednak, pisanie o sprawach prywatnych w tych serwisach nie jest najlepszym rozwiązaniem. Jeśli chcemy zadbać o poufność przesyłanych przez internet komunikatów, to trzeba to robić na inne sposoby. Jednym z nich jest właśnie korzystanie z protokołu XMPP/Jabber. To co odróżnia Jabber'a od innych technologii na rynku, to fakt zdecentralizowania sieci, czyli mamy całą masę serwerów Jabber'a, na których możemy sobie stworzyć konto. Uwalenie jednego serwera nie wpływa na działanie pozostałych. Google także wykorzystuje protokół XMPP/Jabber i mając konto na gmail'u, mamy również stosowny JID w postaci adresu email, który możemy sobie wklepać do jednego z klientów Jabber'a, np. PSI czy Gajim, i jesteśmy już w stanie rozmawiać z osobami, które mają konta na innych serwerach. Właśnie, inne serwery, a może by tak sobie postawić własny serwer Jabber'a? Tak się składa, że w repozytorium Debiana znajduje się oprogramowanie ejabberd, które jest nam w stanie umożliwić realizację tego przedsięwzięcia.