bezpieczeństwo

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.

Jak zweryfikować plik APK aplikacji na Androida

Część użytkowników smartfonów z Androidem na pokładzie żyje w głębokim przekonaniu, że instalowanie aplikacji spoza sklepu Google Play nie jest zbyt rozważnym posunięciem. Nie chodzi tutaj tylko o szeroko rozumiane alternatywne źródła aplikacji, np. serwis apkmirror ale również o Yalp/Aurora Store czy też repozytoria F-Droid. Zdaniem tych osób pobieranie aplikacji z zewnętrznych źródeł może skompromitować bezpieczeństwo systemu oraz zagrozić naszej prywatności. No jakby nie patrzeć wgrywanie czegokolwiek bez zastanowienia się co tak naprawdę instalujemy w systemie nie jest zbyt mądre. Dlaczego zatem nie weryfikujemy aplikacji obecnych w oficjalnym sklepie Google? Co chwila przecież można usłyszeć w mediach o syfie, który udało się co prawda z tego sklepu usunąć ale też jakaś większa liczba użytkowników taką aplikację zdążyła już zainstalować i używała jej przez dłuższy lub krótszy okres czasu. Rozumowanie na zasadzie, że aplikacje ze sklepu Google Play są bezpieczne, bo są obecne w sklepie Google Play, daje nam jedynie fałszywe poczucie bezpieczeństwa, które jest gorsze od całkowitego braku bezpieczeństwa, bo w tym drugim przypadku człowiek przynajmniej jest świadom czyhających na niego niebezpieczeństw i włącza myślenie. Jak zatem odróżnić aplikacje, które są w stanie nam wyrządzić krzywdę od tych, które tego nie mają na celu i czy faktycznie pobieranie aplikacji na Androida z innego źródła niż oficjalny sklep Google Play jest takie niebezpieczne?

Ograniczenie su do jednego użytkownika w Debianie

W dzisiejszych czasach dystrybucje linux'a wykorzystują mechanizm sudo do wykonywania operacji jako administrator systemu. Zanika więc potrzeba stosowania polecenia su , by zalogować się na konto root i to z jego poziomu wykonywać wszystkie niezbędne rzeczy. Jednym z argumentów zwolenników sudo za takim sanem rzeczy jest możliwość nadania jedynie konkretnym użytkownikom w systemie uprawnień do wykonywania poleceń jako administrator, podczas gdy inni użytkownicy (niebędący w grupie sudo ) nie mogą w ogóle korzystać z tego mechanizmu . No faktycznie, dostęp do su jest w zasadzie dla każdego użytkownika w systemie i tylko hasło konta admina dzieli ich od uzyskania dość szerokich uprawnień. Niewiele jednak osób wie, że można skonfigurować su w taki sposób, by dostęp do niego mieli tylko ci użytkownicy, którzy powinni, np. ci obecni w grupie wheel .

Factory Reset Protection (FRP) w smartfonach z Androidem

Kupowanie telefonów czy smartfonów z Androidem z innych źródeł niż oficjalne punkty sprzedaży nie zawsze jest bezpieczną opcją. Gdy nabywamy takie urządzenie od znajomego, to raczej nie powinniśmy się martwić o to, że ten telefon może być kradziony. Niemniej jednak, po zakupie takiego urządzenia, poprzedni użytkownik zwykle resetuje jego ustawienia do fabrycznych, by klient miał świeży system i nie był w stanie uzyskać dostępu do prywatnych danych poprzedniego właściciela smartfona. Nie byłoby w tym nic nadzwyczajnego, gdyby nie fakt, że nabywca tak odsprzedanego telefonu może mieć pewne problemy ze skonfigurowaniem Androida, bo ten system zwróci mu komunikat: "Urządzenie zostało zresetowane. Aby kontynuować, zaloguj się na konto Google, które było wcześniej synchronizowane na tym urządzeniu", czyli telefon został zablokowany przez mechanizm Factory Reset Protection Lock (FRP Lock). Jeśli znajomy mieszka blisko nas, to naturalnie możemy się przejść do niego w celu zdjęcia tej blokady. A co w przypadku, gdy nabyliśmy urządzenie na odległość? Czy jest jakiś sposób na obejście tej blokady w przypadku smartfonów Neffos od TP-LINK?

Apache2: Konfiguracja OCSP Stapling

Serwery udostępniające nam różnego rodzaju strony www na protokole SSL/TLS posiadają certyfikaty, które są ważne przez pewien okres czasu. Z reguły jest to rok albo, jak w przypadku letsencrypt, są to 3 miesiące. Taki certyfikat może zostać unieważniony z różnych przyczyn ale informacja o tym fakcie musi trafić do wszystkich klientów odwiedzających taki serwis www. Do tego celu mogą posłużyć dwa mechanizmy. Pierwszym z nich są listy Certificate Revocation Lists (CRL). Drugim zaś jest Online Certificate Status Protocol (OCSP). W tym wpisie postaramy się zaimplementować to drugie rozwiązanie na serwerze Apache2.

HTTP Strict Transport Security (HSTS) w Apache2

Ostatnio na niebezpieczniku czytałem taki oto post. Historia jak historia, nieco długa ale mniej więcej w połowie pojawiła się informacja na temat nagłówków HSTS (HTTP Strict Transport Security), który jest przesyłany w zapytaniach HTTP/HTTPS. Postanowiłem nieco się zainteresować tym tematem i zbadać czym są te nagłówki HSTS i w jaki sposób są one w stanie poprawić bezpieczeństwo protokołów SSL/TLS wykorzystywanych podczas szyfrowania zawartości stron internetowych.

nf_conntrack: automatic helper assignment is deprecated

Jeśli ktoś uważnie śledzi logi systemowe, to od czasu do czasu można w nich znaleźć komunikat, którzy brzmi mniej więcej tak: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead . Ta wiadomość odnosi się do jednego z modułów linux'owego filtra pakietów iptables . Moduł, o którym mowa to nf_conntrack , który odpowiada za śledzenie połączeń nawiązywanych przez system. Sam komunikat zaś dotyczy mechanizmów pomocniczych, których sposób aktywacji jest już nieco przestarzały i zostanie wkrótce usunięty. Co to oznacza dla przeciętnego użytkownika linux'a i czym są w istocie te mechanizmy pomocnicze, które znajdują zastosowane na zaporze sieciowej?

Konfiguracja DMZ w OpenWRT

Strefa zdemilitaryzowana (DMZ, demilitarized zone) to taki mechanizm, który ma na celu poprawę bezpieczeństwa usług w sieci lokalnej. Generalnie chodzi o podział sieci na kilka mniejszych podsieci i oddzielenie ich od siebie fizycznie lub logicznie. W OpenWRT możemy wydzielić taką strefę DMZ przy pomocy VLAN'ów. Z kolei odpowiednio skonfigurowany firewall odseparuje nam tę strefę od pozostałych maszyn pracujących w sieci LAN. W taki sposób nawet w przypadku włamania mającego miejsce w strefie DMZ, maszyny w pozostałych segmentach sieci będą bezpieczne. W tym wpisie postaramy się skonfigurować strefę zdemilitaryzowaną na routerze wyposażonym w firmware OpenWRT.

Jak wyczyścić tablicę conntrack'a w debianie

Sporo użytkowników lunux'a, zwłaszcza dystrybucji debian, korzysta z własnych skryptów firewall'a aplikujących reguły iptables . Tego typu rozwiązanie ma jednak swoje wady i zalety. Niewątpliwie do zalet można zaliczyć brak dodatkowego oprogramowania obsługującego zaporę sieciową. Jeśli chodzi zaś o wady, to niestety cały skrypt trzeba sobie dobrze przemyśleć przed zaaplikowaniem. Ludzie często zapominają tutaj o śledzeniu połączeń przez kernel. To właśnie na podstawie wpisów w /proc/net/ip_conntrack lub /proc/net/nf_conntrack system wie, które pakiety należy na zaporze przepuścić, a które zablokować. Jeśli teraz dodajemy reguły do filtra iptables , to nowa polityka zapory nie będzie odnosić się do tych nawiązanych już połączeń, które są określone w tablicy conntrack'a. By się upewnić, że tego typu scenariusz nigdy nas nie spotka, musimy tę tablicę opróżnić.