debian

Uwierzytelnianie odpowiedzi z serwerów czasu NTP przy pomocy NTS

Przepisując ostatnio stare artykuły dotyczące zabezpieczenia zapytań DNS za sprawą wdrożenia na linux dnsmasq i dnscrypt-proxy, natknąłem się na informację, że nie tylko komunikacja DNS w obecnych czasach w sporej mierze nie jest zaszyfrowana. W zasadzie każda maszyna podłączona do internetu potrzebuje dysponować w miarę dokładnym czasem. By ten czas był dokładny, wymyślono mechanizm synchronizacji czasu przez wysyłanie zapytań do serwerów NTP (Network Time Protocol). Niemniej jednak, odpowiedzi z tych serwerów czasu nie są w żaden sposób zabezpieczone i praktycznie każdy na drodze tych pakietów może nam zmienić ustawienia czasu w systemie (MITM). W taki sposób możemy zostać cofnięci w czasie, co z kolei może oznaczać, że system zaakceptuje certyfikaty SSL/TLS czy też klucze/bilety sesji (używane do wznawiania sesji TLS), które już dawno temu wygasły lub/i zostały w jakiś sposób skompromitowane. Pchnięcie nas do przodu w czasie również oznacza problemy, bo możemy zaakceptować certyfikat, który jeszcze nie zaczął być ważny. To z kolei otwiera drogę do odszyfrowania połączeń z serwisami WWW, a przecie nie po to szyfrujemy ruch, by go ktoś bez większego problemu odszyfrował. Dlatego też powinniśmy zadbać o to, by informacje o aktualnym czasie otrzymywane z sieci docierały do nas z wiarygodnego źródła i były w jakiś sposób uwierzytelnione. Na Debianie standardowo do synchronizacji czasu wykorzystywany jest systemd-timesyncd ale nie wspiera on póki co protokołu NTS. Trzeba będzie zatem się go pozbyć i zastąpić go demonem ntpd z pakietu ntpsec .

Szyfrowany DNS z dnscrypt-proxy i dnsmasq na Debian linux

Ostatnio na forum dug.net.pl jeden z użytkowników miał dość spory problem z ogarnięciem zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem dnscrypt-proxy i dnsmasq. Ładnych parę lat temu opisywałem jak skonfigurować te dwa narzędzia na Debianie (i też na OpenWRT), choć od tamtego czasu w świecie linux'owym trochę rzeczy się pozmieniało. Dla przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak systemd-networkd.service czy systemd-resolved.service są już włączone domyślnie. Zatem sporo informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania dnscrypt-proxy oraz dnsmasq i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.

Systemowy GPG/GnuPG w Thunderbird 78+ na linux

Jakiś już czas temu Mozilla ogłosiła, że Thunderbird od wersji 78 będzie posiadał natywne wsparcie dla szyfrowania wiadomości z wykorzystaniem kluczy GPG/PGP, przez co dodatek Enigmail będzie już zwyczajnie zbędny. Dziś z kolei czytam sobie o zakończeniu wsparcia dla wersji 68 tego klienta pocztowego, które będzie miało miejsce z końcem września 2020, czyli został już niespełna miesiąc i ta starsza wersja Thunderbird'a nie będzie już dostawać łat bezpieczeństwa. Pewne jest zatem, że dystrybucje linux'a w niedługim czasie pchną wersję 78 do głównych repozytoriów. W Debianie, wersja 78 Thunderbird'a od dłuższego czasu jest dostępna w gałęzi eksperymentalnej i można było ją już wcześniej sobie zainstalować, jeśli ktoś wyrażał taką chęć. Gdy ja ostatni raz testowałem wersję 78, to nie była ona zbytnio do użytku ale wygląda na to, że większość niedogodności, których mi się udało doświadczyć, została już wyeliminowana. Pozostał w zasadzie jeden problem, tj. Thunderbird domyślnie używa własnego keyring'a kluczy GPG/PGP, w efekcie czego systemowy GPG/GnuPG nie jest w ogóle wykorzystywany. Taki san rzeczy sprawia, że będziemy mieć dwie różne bazy danych kluczy (jedna dla Thunderbird'a, a druga dla reszty linux'a), co może trochę irytować. Na szczęście jest opcja wymuszenia na TB, by korzystał on z systemowego keyring'a kluczy GPG/PGP i celem tego artykułu jest pokazanie właśnie jak tego typu zabieg przeprowadzić.

Jak zmusić jeden proces do korzystania z VPN na linux (OpenVPN)

Parę dni temu na forum dug.net.pl pojawiło się zapytanie dotyczące skonfigurowania linux'a w taki sposób, by ten umożliwił pojedynczemu procesowi w systemie (i tylko jemu) korzystanie z VPN, podczas gdy wszystkie pozostałe aplikacje korzystają ze standardowego łącza internetowego naszego ISP. Oczywiście to niekoniecznie musi być tylko jeden proces, bo to zagadnienie można rozciągnąć też na większą grupę procesów jednego lub więcej użytkowników. By to zadanie zrealizować, trzeba zdać sobie sprawę z faktu, że każdy proces w linux ma swojego właściciela, a ten właściciel przynależy do co najmniej jednej grupy. Dzięki takiemu rozwiązaniu, każdy proces w systemie ma przypisany m.in. identyfikator użytkownika (UID) oraz identyfikatory grup (GID), z którymi działa i na podstawie których to linux przyznaje uprawienia dostępu do różnych części systemu, np. urządzeń czy plików na dysku. W ten sposób możemy bardzo prosto ograniczyć dostęp do określonych zasobów konkretnym użytkownikom (bardziej ich procesom). Problem się zaczyna w przypadku sieci, gdzie w zasadzie dostęp do internetu ma domyślnie przyznany każdy proces. Naturalnie możemy skonfigurować filtr pakietów i zezwolić tylko części aplikacji na dostęp do sieci ale w dalszym ciągu, gdy tylko odpalimy VPN (w tym przypadku OpenVPN), to każdy proces mający prawo wysyłać pakiety sieciowe będzie je przesyłał z automatu przez VPN, jak tylko to połączenie zostanie zestawione. Istnieje jednak sposób, by nauczyć linux'a aby tylko procesy określonych użytkowników czy grup miały dostęp do VPN i gdy to połączenie zostanie zerwane, to te procesy nie będą mogły korzystać ze standardowego łącza internetowego. Trzeba jednak zaprzęgnąć do pracy iptables / nftables , tablice routingu oraz nieco inaczej skonfigurować klienta OpenVPN.

Zarządzanie Raspberry Pi 4B z LibreELEC przez VNC/SPICE

Do konfiguracji systemu LibreELEC, który jest zainstalowany na moim Raspberry Pi 4B nie potrzebuję żadnego monitora czy wyświetlacza, a wszystkie prace administracyjne związane z tym małym komputerem ogarniam po SSH. Niemniej jednak, są pewne rzeczy, których się po SSH nie da skonfigurować. Chodzi generalnie o konfigurację Kodi i sprawy związane z domowa wideoteką. Ten Raspberry Pi 4B jest podłączony do TV, zatem bez problemu można przez graficzny interfejs Kodi skonfigurować to, co potrzeba. Niemniej jednak konfigurowanie Kodi przez aplikację na Androida (Kore) nie należy do najłatwiejszych zadań. Nie uśmiecha mi się też ciągle latać z myszą i klawiaturą w celu podłączania ich do portów USB maliny. Nie mam też w zasadzie zewnętrznego monitora HDMI, bo od lat używam jedynie laptopów. Pomyślałem zatem, by zrobić użytek z protokołu VNC/SPICE i przesłać obraz z Raspberry Pi 4B przez sieć do mojego laptopa. W ten sposób odpadłoby mi ciągłe przemieszczanie się między pokojami i byłbym w stanie podejrzeć obraz TV na ekranie monitora w moim laptopie przy jednoczesnym zachowaniu możliwości używania myszy i klawiatury, co by mi bardzo zaoszczędziło czas przy konfiguracji Kodi.

Raspberry Pi, LibreELEC, Kodi i zdalne logi via rsyslog

Parę lat temu, gdy pojawił się u mnie w domu bezprzewodowy router WiFi, postanowiłem wgrać na niego linux'a w postaci OpenWRT. Pierwszym kluczowym elementem konfiguracyjnym tego urządzenia było przesłanie jego logów systemowych przez sieć do mojego laptopa, tak by wszystkie zarejestrowane komunikaty zostały wyświetlone na konsoli mojego komputera z zainstalowanym Debianem. W ten sposób nie musiałem się co chwila logować na router po SSH (czy też przez panel webowy), by sprawdzić czy aby na pewno z tym urządzeniem jest wszystko w porządku. Teraz, po nabyciu Raspberry Pi 4B i wgraniu na niego LibreELEC z preinstalowanym Kodi, mam dokładnie to samo zadanie do zrealizowania. Trzeba zatem znaleźć sposób na przesłanie wszystkich logów generowanych przez system LibreELEC do demona rsyslogd , który jest uruchomiony na zdalnej maszynie.

Jak włączyć stabilne adresy prywatne w IPv6 na linux

Jakiś już czas temu opisywałem jak włączyć rozszerzenia prywatności IPv6 na Debianie (IPv6 Privacy Extensions) w przypadku korzystania z mechanizmu automatycznej konfiguracji adresacji hostów SLAAC (StateLess Address AutoConfiguration). Miało to za zadanie poprawić nieco prywatność osób podłączonych do internetu za sprawą protokołu IPv6, bo generowane adresy IP standardowo zawierają adresy MAC kart sieciowych (identyfikator EUI64). Parę dni temu dowiedziałem się, że w linux można również aktywować inny mechanizm zwany stabilnymi adresami prywatnymi (stable-privacy addresses), które to wykorzystują inny system przy generowaniu identyfikatorów interfejsów sieciowych. Ten mechanizm sprawia, że część adresu IPv6 odpowiedzialna za identyfikację hosta ma losowe, choć stabilne wartości, które nie mają nic wspólnego z adresem MAC karty sieciowej naszego komputera. W ten sposób możemy ukrócić śledzenie nas w sieci na podstawie adresu IPv6. Poniższy artykuł ma za zadanie pomóc skonfigurować nam te stabilne adresy prywatne na linux oraz pokazać w jaki sposób są one w stanie pomóc naszej prywatności.

Jak odszyfrować linux'a przy pomocy telefonu z Androidem

Zaszyfrowane systemy (desktopy/laptopy) mają jeden poważny problem, gdy chodzi o zapewnianie bezpieczeństwa chronionym plikom przechowywanym na dyskach twardych. Gdy siedzimy obok naszej maszyny, możemy czuć się bezpiecznie, bo przecież nikt nie może się włamać do jej systemu bez naszej wiedzy. Nawet jeśli ktoś będzie próbował się dostać do naszego PC, to istnieje spora szansa, że takie działanie zostałoby natychmiast przez nas wykryte, przez co moglibyśmy w odpowiedni sposób zareagować na zaistniałe zagrożenie. Co jednak w przypadku, gdy zostawiamy przykładowo naszego laptopa samego? Nawet jeśli zablokujemy mu ekran, wyłączymy go albo zahibernujemy, to ta maszyna wciąż nie jest odpowiednio zabezpieczona, by uniemożliwić osobom postronnym dostęp do naszych wrażliwych danych. Problem leży w fizycznym dostępie do sprzętu, który ludzie mogą uzyskać, gdy nas nie ma w pobliżu naszego komputera. W taki sposób osoby trzecie mogą wykorzystać fakt, że tracimy maszynę z oczu i być w stanie zastawić na nas różne pułapki. By uniknąć zagrożenia związanego z zostawieniem laptopa/desktopa bez nadzoru, nie możemy w zasadzie pozostawiać tego urządzenia samego, co jest zadaniem praktycznie nie do wykonania. Komputery stacjonarne czy nawet laptopy nie są urządzeniami o małych gabarytach i zwykle nie możemy ich wszędzie zabrać ze sobą, w przeciwieństwie do smartfonów. Postanowiłem zatem tak skonfigurować swojego linux'a, by jego zaszyfrowany dysk (LUKS + LVM) można było odszyfrować jedynie przy pomocy mojego telefonu z Androidem, z którym w zasadzie się nie rozstaję.

Migracja bloga z Jekyll na Hugo i jego publikacja w GitHub Pages

Prawdopodobnie zauważyliście drobne zmiany w wyglądzie tego bloga oraz pewnie też cześć osób miała w ostatnim czasie problemy z uzyskaniem do niego dostępu. Odpowiedzialne za zaistniałą sytuację są limity narzucone przez GitHub Pages. Zakładają one maksymalny rozmiar repozytorium pod stronę WWW w granicach 1 GiB oraz czas budowania takiego serwisu krótszy niż 10 minut. Limit miejsca na pliki przekroczony został w zasadzie w chwili przeniesienia bloga WordPress na GitHub Pages. Natomiast parę dni temu został przekroczony limit czasu budowania tego projektu. Do momentu transformacji, niniejszy blog działał w oparciu o Jekyll, który generował w zasadzie statyczny kod HTML ze zwykłych plików tekstowych (np. artykuły pisane w MarkDown). GitHub Pages posiada wsparcie dla Jekyll, przez co taką stronę WWW można bardzo prosto wdrożyć. Niemniej jednak, cały ten mechanizm generowania projektu w obrębie infrastruktury GitHub'a zajmuje bardzo dużo czasu. Po rozmowie z supportem okazało się, że gdyby chodziło o miejsce na pliki, to mogli by nagiąć reguły i nie było by problemu ale nie dadzą rady tego zrobić w przypadku przekroczenia czasu generowania projektu. Dlatego też trzeba było zrezygnować z Jekyll'a i poszukać dla niego jakiejś alternatywy. Padło na Hugo, który w odróżnieniu od Jekyll'a nie jest jako tako wspierany przez GitHub i by stronę wygenerowaną przez Hugo podpiąć pod GitHub Pages trzeba się trochę wysilić, bo ten proces nie jest automatyczny i właśnie o tym jak dokonać migracji z Jekyll na Hugo w kontekście GitHub Pages będzie ten poniższy artykuł.

Jak włączyć w Firefox ESNI (Encrypted SNI)

Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (DNS over HTTPS) lub DoT (DNS over TLS). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia), poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy https:// ) z wykorzystaniem protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (Server Name Indication), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może szyfrować ruch niezależnie od siebie na linii serwer<->klient (używać innych kluczy szyfrujących). Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (Encrypted Client Hello) oraz ESNI (Encrypted SNI), które mają zaadresować problemy związane z prywatnością przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie. Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i wdrożyć na swoim linux'ie to rozszerzenie ESNI dla przeglądarki Firefox.