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 .

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?

Ostatnio próbowałem zaktualizować obraz TWRP recovery dla jednego z moich telefonów. Ja generalnie buduje te obrazy ze źródeł OMNI ROM, a tam jest dostępnych szereg gałęzi, np. 6.0, 7.1, 8.1 , etc, które naturalnie pasują do odpowiadających im wersji Androida. Do tej pory budowałem w oparciu o gałąź 7.1 ale po wydaniu polecenia repo sync , szereg aktualizacji w stosunku do repozytorium bootable/recovery zostało pobranych, w tym też i jedna trefna, która uwalała proces kompilacji. Ostatecznie udało się problem namierzyć i zlikwidować ale w międzyczasie próbowałem zbudować obraz TWRP recovery z gałęzi 8.1. Wygląda na to, że im nowszy Android, tym obrazy recovery rosną w objętość i 16M, które u mnie jest limitem, zostało przekroczone o jakieś 500K i to przy najbardziej okrojonej funkcjonalności trybu recovery. Czy istnieje jakieś rozwiązanie, które by umożliwiło zmniejszenie rozmiaru obrazu ramdisk-recovery.img , co przełożyłoby się również na wagę pliku recovery.img ? Tak, trzeba tylko zmienić rodzaj kompresji z domyślnego gzip na lzma.