Pisząc ostatnio artykuł o tym jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed zmapowaniem i umieszczeniem jego fizycznej lokalizacji w serwisach pokroju Wigle.net czy też w usługach Google/Mozilla, poruszony został temat ewentualnego usuwania wpisów z takich baz danych AP za sprawą dopisywania do nazwy sieci (ESSID) sufiksu _nomap . Nie wszystkie organizacje/firmy respektują naszą prywatność i raczej też nie będą tej końcówki w nazwie sieci honorować. Jako, że jednym z dwóch parametrów, na podstawie których takie mapowanie punktów dostępowych się odbywa, jest adres MAC interfejsu bezprzewodowego danego AP (BSSID), to możemy od czasu do czasu pokusić się o zmianę tego adresu. Jest to mniej więcej to samo rozwiązanie, co zastosowane przy klonowaniu adresu MAC dla portu WAN routera, które z reguły użytkownicy wykorzystują do obchodzenia zabezpieczeń tych bardziej wrednych ISP. Jako, że temat zmiany BSSID trochę się różni od zmiany adresu MAC dla portu WAN, to w niniejszym artykule postanowiłem opisać jak w routerze z wgranym firmware OpenWRT podejść do tego zadania.

Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w bazie danych serwisu Wigle.net oraz, że lepiej nie zdradzać nazw swoich WiFi osobom trzecim, bo ktoś w oparciu o te dane może poznać nasze fizyczne położenie. Jak najbardziej istnieje taka możliwość, a sam serwis Wigle.net nie jest jedynym, który zbiera informacje o położeniach geograficznych punktów dostępowych WiFi, bo od lat robi to też Google i Mozilla. Niemniej jednak, podchodziłbym z pewną dozą ostrożności do danych zgromadzonych w serwisie Wigle.net (i tych pozostałych dwóch też), bo nie zawsze muszą one być akuratne. W zasadzie to nie zdziwiłem się zbytnio, że nazwa mojej sieci WiFi figuruje w bazie danych Wigle.net, bo sam ją tam umieściłem świadomie jakiś czas temu w ramach testów wykorzystując do tego celu aplikację WiGLE WiFi Wardriving, którą można wgrać przez F-Droid na każdy telefon z Androidem. Jako, że nadarzyła się okazja, to postanowiłem napisać parę słów na temat unikania bycia zmapowanym, tak by jakiś nieznany nam bliżej osobnik przez przypadek nie wrzucił lokalizacji naszych domowych/firmowych AP do bazy danych Google/Mozilla czy też wspomnianego wyżej serwisu Wigle.net, o ile oczywiście sobie tego nie życzymy.

Właściciele smartfonów mają zwykle podpisane umowy ze swoimi operatorami GSM na świadczenie usług telefonicznych. Pakiety rozmów oferowane przez tych operatorów już od dłuższego czasu są nielimitowane, co z kolei zachęca abonentów do głosowego komunikowania się przy pomocy tych małych lecz przy tym bardzo zaawansowanych technologicznie komputerów. Nie ma obecnie chyba sprawy, której nie można załatwić telefonicznie, a że coraz dłużej wisimy na słuchawce, to też sporo informacji z takich rozmów nam bezpowrotnie ucieka, np. imię i nazwisko osoby, z którą rozmawialiśmy, nie wspominając o całej masie innych rzeczy, które mogą paść podczas choćby negocjowania/przedłużania jakiegoś kontraktu. Gdy w późniejszym czasie zorientujemy się, że coś jest nie tak, to możemy mieć poważny problem z udowodnieniem swoich racji, np. że zostaliśmy celowo wprowadzeni w błąd. Gdybyśmy dysponowali nagraniem z takiej rozmowy, to bez problemu można by się do niego odnieść i nikt by nie miał wątpliwości po czyjej stronie byłaby racja. Niemniej jednak, smartfony z Androidem mają ogromny problem z nagrywaniem dźwięku audio podczas tego typu konwersacji, czego efektem jest brak możliwości niezależnego rejestrowania rozmów telefonicznych. Jeśli jednak posiadamy ukorzenionego Androida (dostęp do praw administratora root), to możemy te obostrzenia obejść zaprzęgając do pracy aplikację Call Recorder.

Od już dłuższego czasu (będzie parę lat) korzystam z internetu LTE zamiast tradycyjnego połączenia przewodowego. Głównie ze względu na fakt, że w mojej okolicy nie ma praktycznie żadnych szanujących się ISP, z którymi warto by wejść w interakcję i podpisać z nimi jakąś sensową umowę. Poza tym, dla osób mojego pokroju, które cenią sobie mobilność, internet stacjonarny i tak jest mało praktyczny. Dlatego w moim domowym routerze mam wgrany firmware OpenWRT umożliwiający zainstalowanie na tym urządzeniu odpowiedniego oprogramowania obsługującego modemy LTE podłączane przez port USB. Połączenie sieciowe ze światem zwykle działa prawidłowo ale z jakiegoś powodu jest ono zrywane. Zwykle taka sytuacja ma miejsce w środku nocy (czasami parokrotnie), zwłaszcza gdy przekroczę limit danych i do końca okresu rozliczeniowego muszę przemęczyć się z lejkiem 1 mbit/s. Gdy ten lejek jest aplikowany, to zwykle odpalam sobie torrent'a, tak by pobrać najnowsze obrazy ISO tej czy innej dystrybucji linux'a. Niemniej jednak, jak mi net rozłączą, to nie załączy się on ponownie sam z siebie. Modem Huawei E3372s-153 w wersji NON-HiLink zdaje się pracować poprawnie, bo świeci się na nim dioda sugerująca, że połączenie z internetem jest nawiązane. Dlatego też postanowiłem w końcu ten problem rozwiązać raz na zawsze i mieć przy tym nieco spokojniejszy sen.

W poprzednim artykule, który traktował o odszyfrowaniu kontenera LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi, została poruszona kwestia adresacji IP, która w opisanym tam rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane jedynie przez przewodowy interfejs sieciowy eth0 . Trzeba było zatem się zastanowić nad rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj. wlan0 . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego minikomputera z zainstalowanym system RasPiOS/Raspbian.

Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian. O ile samo zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS nie było jakoś specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza, bez którego system się nie uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear, pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd. Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i uruchomiony.

Ostatnio udało mi się zaszyfrować swojego Raspberry Pi 4B przez wdrożenie kontenera LUKS i upchnięcie w nim wszystkich danych z partycji / zainstalowanego w tym urządzeniu systemu RasPiOS/Raspbian. To jednak nie był koniec pracy, bo taki zaszyfrowany system na RPI ma szereg wad. Tym główniejszym uniedogodnieniem jest wpisywanie hasła na początku fazy boot, by pełny start systemu był w ogóle możliwy. Sytuacja się komplikuje, gdy do naszego minikomputera nie mamy podłączonego monitora i/lub klawiatury. Ten zaistniały problem można rozwiązać na kilka sposobów, np. przez zaprzęgnięcie do pracy dodatkowego nośnika USB w celu umieszczenia na nim pliku klucza (keyfile). Niemniej jednak, można pójść o krok dalej i wykorzystać samo urządzenie jako klucz i gdy takiego pendrive nie podłączymy do portu USB naszej maliny, to system nam się nie uruchomi. Te dwa rozwiązania są bardzo podobne do siebie ale to drugie jest nieco bardziej odporne na ewentualne problemy ze skasowaniem pliku klucza, co może nam się przytrafić, gdy taki pendrive jest wykorzystywany w roli regularnego nośnika danych przechowującego dla niepoznaki jakieś pliki. Tak czy inaczej oba te sposoby zostaną opisane w niniejszym artykule.

Ostatnio napisał do mnie pewien osobnik, który miał dość spory problem z zaszyfrowaniem swojego Raspberry Pi. Po wymianie kilku maili zacząłem tracić rozeznanie w całej tej sytuacji i doszedłem do wniosku, że najwyraźniej zaszyfrowanie systemu maliny nie jest rzeczą trywialną. Postanowiłem zatem rzucić okiem na swojego RPI i sprawdzić czy są tutaj faktycznie jakieś odstępstwa od tradycyjnego szyfrowania na bazie LUKS w stosunku do szyfrowania spotykanego w pierwszej lepszej dystrybucji linux'a, takiej jak Debian czy Ubuntu. Pobrałem więc ze strony Raspberry Pi najnowszy obraz systemu RasPiOS/Raspbian, wrzuciłem go na kartę SD przy pomocy dd i okazało się, że w zasadzie większych problemów z zaszyfrowaniem mojej maliny nie było. Przyznać trzeba, że informacje na temat szyfrowania RPI, które można spotkać na internetach, są w przeważającej większości bardzo słabej jakości i mam wrażenie, że pisane przez osoby, które nie do końca się zainteresowały poruszanym przez siebie zagadnieniem. Postanowiłem zatem na przykładzie mojego Raspberry Pi 4B opisać w miarę dokładny sposób od początku do końca jak przeprowadzić cały ten proces szyfrowania danych na karcie SD, którą podpinamy do naszego minikomputera.

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.

Posiadacze monochromatycznych (czarnobiałych) drukarek laserowych zapewne spotkali się z problemem drukowania kolorowych dokumentów na tego typu urządzeniach. Nie chodzi tutaj o drukowanie obrazków czy innych elementów graficznych ale o wydrukowanie, np. zeskanowanej książki. Ostatnio przyszło mi wydrukować dokumentację techniczną dość starego urządzenia. Problem w tym, że nie był to zwykły kawałek książki, a jedynie jej skany, z których ktoś postanowił zrobić plik PDF . Takiego dokumentu "tekstowego" za bardzo nie da się wydrukować na drukarce laserowej, przynajmniej nie bez pchania się w ogromne koszty. Dla przykładu, w miejsce pożółkniętej kartki ze skanu, taka drukarka wstawi jakiś odcień szarości i w ten sposób zadrukuje tą szarością całą stronę marnując przy tym niesamowite ilości toneru, za który my będziemy musieli później zapłacić, co czyni cały proces drukowania zeskanowanych dokumentów bardzo kosztownym. Postanowiłem jednak znaleźć jakiś sposób, by tę dokumentację wydrukować, choć trzeba było pierw zająć się samymi skanami, tj. doprowadzić je do stanu, w którym można by mówić o ewentualnym ich wydrukowaniu. Okazało się, że nie jest to jakoś specjalnie trudne zadanie, zwłaszcza, gdy na linux zaprzęgnie się do tego celu ImageMagick.