Bezpieczeństwo on Morfitronik

Zablokowanie możliwości ładowania modułów kernela na Debian linux

Mikhail Morfikov — Tue, 13 Dec 2022 13:03:00 +0100

Kernele oferowane przez różne dystrybucje linux'a, np. Debian czy Ubuntu, są tak budowane by możliwie jak największa ilość sprzętu na takim jądrze operacyjnym nam zadziałała bez zbędnego przerabiania systemu. Takie podejście sprawia, że nowo nabyty przez nas sprzęt możemy od razu podłączyć do komputera, a stosowne moduły po rozpoznaniu urządzenia zostaną załadowane do pamięci operacyjnej, przez co my będziemy mogli wejść w interakcję z takim kawałkiem elektroniki. Problem w tym, że kernel ma bardzo dużo tych modłów. Dużo modułów, to więcej kodu, a więcej kodu to więcej błędów, które na poziomie jądra mogą być bardzo opłakane w skutkach. Z zagrożeniem, jakie niosą moduły zewnętrzne (te spoza drzewa kernela linux), można sobie poradzić podpisując kernel kluczami od firmware EFI/UEFI. W takim przypadku załadowanie niepodpisanego modułu już się nie powiedzie. Niemniej jednak, dystrybucyjne kernele mają całą masę modułów do różnorakiego sprzętu, które na etapie budowania kernela są podpisywane, co otwiera im drogę do bycia załadowanymi w naszym systemie nawet jeśli nie posiadamy urządzeń, które by użytek z tych modułów robiły. Przydałoby się zatem zabezpieczyć możliwość ładowania modułów kernela w taki sposób, by jedynie administrator systemu miał możliwość określenia jakie moduły i na którym etapie pracy systemu mogą one zostać załadowane.

Jak wyłączyć mapowanie adresów IPv4 na IPv6 w Debian linux

Mikhail Morfikov — Thu, 14 Oct 2021 23:52:00 +0200

Przeglądając ostatnio połączenia w swoim telefonie z Androidem, natknąłem się na wpisy mające w swoich adresach źródłowych ustawione IP takie, jak ::ffff:192.168.1.188 . Podobnie sprawa wygląda w przypadku adresów docelowych tego samego połączenia, tj. widnieje tam np. ::ffff:216.58.215.1 . Na pierwszy rzut oka taka konstrukcja adresu IP przypomina IPv6, przynajmniej jej pierwsza część, tj. ::ffff: , natomiast drugi kawałek już bardzo przypomina adres IPv4. Okazuje się, że za taki format adresów IP odpowiada mechanizm mapowania adresów IPv4 na adresy IPv6. Nie jest to jednak tożsame z 6to4 czy 6in4, gdzie host ze stałym publicznym adresem IPv4 jest w stanie komunikować się z hostami nadającymi po IPv6. W przypadku mapowania adresów IPv4 na IPv6, połączenia ze zdalnymi hostami mogą odbywać się zarówno po IPv4 jak i IPv6, a to z którego z tych protokołów nasz linux skorzysta zależy od tego czy taka maszyna dysponuje przydzielonym adresem IPv6. Jeśli ISP nie zapewnia nam adresu IPv6, to wtedy pakiety sieciowe będą przesyłane z wykorzystaniem protokołu IPv4. Wciąż jednak te mieszane konstrukcje adresów IP będą widoczne na wykazie połączeń w netstat/ss . Okazuje się jednak, że ten mechanizm mapowania adresów może powodować szereg problemów związanych z bezpieczeństwem systemu. Dlatego też tam gdzie to możliwe przydałoby się go wyłączyć.

Migracja z apt-key w Debian linux

Mikhail Morfikov — Sat, 21 Aug 2021 14:35:00 +0200

Z okazji wypuszczenia parę dni temu nowego Debiana, przeglądałem sobie notki dla wydania stabilnego pod kątem aktualizacji z buster (10) -> bullseye (11). Niby ja i tak korzystam cały czas z unstable/experimental i zwykle jestem na bieżąco ze zmianami wprowadzanymi w tej dystrybucji linux'a ale też zawsze coś może umknąć uwadze z perspektywy wielu miesięcy czy nawet kilku lat (a dokładnie 25 miesięcy). Sporo z tych rzeczy, które w tych podlinkowanych notatkach wyczytałem, miałem już załatwione wcześniej ale zapomniałem rozprawić się z repozytoriami APT. Konkretnie chodzi tutaj o odejście od apt-key , czyli narzędzia, które w Debianie używane jest do dodawania kluczy GPG do systemowego keyring'a APT. Te klucze zwykle wykorzystywane są do weryfikacji sygnatur złożonych pod zewnętrznymi repozytoriami, a że ja mam ich sporo, to musiałem się nieco zagłębić w temat i ustalić w jaki sposób od następnego wydania Debiana (bookworm/12) będzie się te klucze GPG od takich repozytoriów ogarniać. No i właśnie o tym będzie ten poniższy kawałek artykułu.

Uwierzytelnianie odpowiedzi z serwerów czasu NTP przy pomocy NTS

Mikhail Morfikov — Sun, 27 Sep 2020 12:29:00 +0200

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

Mikhail Morfikov — Sat, 19 Sep 2020 14:13:00 +0200

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

Mikhail Morfikov — Fri, 13 Dec 2019 19:26:14 +0100

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

Mikhail Morfikov — Fri, 12 Apr 2019 19:40:40 +0000

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 .

Apache2: Konfiguracja OCSP Stapling

Mikhail Morfikov — Sat, 06 Aug 2016 19:16:09 +0000

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

Mikhail Morfikov — Tue, 19 Jul 2016 19:08:40 +0000

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

Mikhail Morfikov — Sat, 16 Jul 2016 18:59:19 +0000

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

Mikhail Morfikov — Tue, 05 Jul 2016 18:05:31 +0000

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

Mikhail Morfikov — Sun, 05 Jun 2016 12:34:55 +0000

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ć.

Rkhunter jako ochrona przed rootkit'ami

Mikhail Morfikov — Tue, 08 Mar 2016 15:42:59 +0000

Rootkit to takie ustrojstwo, które jest w stanie przebywać niepostrzeżenie w naszym systemie przez bardzo długi czas. Dzieje się tak ze względu na uśpioną czujność administratora. Teoretycznie wszystko jest w należytym porządku, nie widać żadnych złowrogich procesów, a szereg narzędzi, które mają przeciwdziałać rootkit'om, nie zwraca żadnych ostrzeżeń o ewentualnych próbach naruszenia bezpieczeństwa systemu operacyjnego. Taki rootkit jest w stanie całkowicie przejąc kontrolę nad linux'em i np. może decydować o tym jakie procesy zostaną nam pokazane, a jakie ukryte. W świetle takiego zagrożenia, linux'y wypracowały sobie pewne mechanizmy obronne. W tym wpisie przebadamy sobie jeden z projektów, tj. rkhunter.

Ukrywanie informacji w plikach (steganografia)

Mikhail Morfikov — Thu, 21 Jan 2016 21:49:23 +0000

Jak możemy wyczytać na wikipedii, steganografia to nauka, która ma na celu ukrycie faktu prowadzenia komunikacji. Odróżnia ją to nieco od kryptografii, gdzie wiadomość jest wprawdzie nieczytelna ale wiadome jest, że dokonywana jest wymiana informacji między dwoma punktami. W przypadku steganografii możemy ukryć pewną informację, np. w pliku graficznym maskując tym samym cały proces przekazywania danych. W taki sposób osoba, która nie ma pojęcia o fakcie ukrycia informacji, zobaczymy jedynie zwykły obrazek. Poniższy wpis ma na celu sprawdzenie jak skuteczna jest ta metoda i czy nadaje się do zastosowania dla przeciętnego zjadacza chleba.

Nagłówek kontenera LUKS trzymany na pendrive

Mikhail Morfikov — Fri, 15 Jan 2016 20:28:24 +0100

Jeśli kiedyś rozważaliśmy umieszczenie pliku klucza (keyfile) do zaszyfrowanego kontenera LUKS na pendrive, to ciekawszą alternatywą może okazać się umieszczenie całego nagłówka takiego kontenera na zewnętrznym nośniku. Ma to tę przewagę nad keyfile, że wszystkie informacje zapewniające dostęp do kontenera, wliczając w to klucz główny, są oddzielone od zaszyfrowanych danych. W ten sposób nawet jeśli kontener wpadnie w niepowołane ręce, to nie ma żadnego sposobu na to, by ten ktoś te dane odzyskał, no bo przecie nie ma klucza szyfrującego. Przechwycenie hasła również nic to nie zmieni, no chyba, że ten ktoś zdobędzie również pendrive z nagłówkiem kontenera. Z ludzkiego punktu widzenia, to na takim dysku będą znajdować się jedynie losowe dane i do tego w formie kompletnie nieczytelnej dla człowieka (brak systemu plików). Niemniej jednak, jest kilka rzeczy, o których warto pamiętać, gdy w grę wchodzi nagłówek LUKS i to o nich porozmawiamy sobie w tym wpisie.

Odszyfrowanie kontenerów LUKS w systemd

Mikhail Morfikov — Fri, 01 Jan 2016 17:18:03 +0000

Osoby, które wykorzystują pełne szyfrowanie dysku, wiedzą, że nie zawsze da radę tak skonfigurować swój system, by upchnąć go na jednej partycji. Nawet jeśli korzystamy z LVM wewnątrz kontenera LUKS, to i tak zwykle możemy posiadać inne zaszyfrowane partycje, które są odrębną całością i montowane osobno przy starcie systemu. W takim przypadku zwykle jesteśmy zmuszeni do podawania hasła do każdego z tych dysków z osobna, co zajmuje czas. Ten problem opisałem po części przy okazji implementacji kontenera LUKS na potrzeby Dropbox'a, jak i we wpisie poświęconym przejściu z kontenerów TrueCrypt'a na te linux'owe, które są wspierane natywnie przez sam kernel. Niemniej jednak, tamto rozwiązanie było oparte głównie o starszy init (sysvinit), co wymagało dodatkowej konfiguracji, tak by system otworzył się po podaniu tylko jednego hasła. W tym wpisie postaramy się wdrożyć mechanizm, który jest oferowany przez systemd.

Profil AppArmor'a i jego dokładna budowa

Mikhail Morfikov — Tue, 01 Dec 2015 17:57:39 +0000

Budowanie samych profili dla AppArmor'a nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w pakiecie apparmor-utils . Dobrze jest jednak prześledzić sobie manual AppArmor'a oraz to, co twórcy piszą na swojej stronie w oficjalnej dokumentacji projektu. Poniższy wpis powstał w celu zrozumienia składni profili AppArmor'a, tak by jeszcze bardziej uprościć proces ich budowania.

Opis składni znajdujący się poniżej został zaczerpnięty z wiki AppArmor'a. Część z poniższych informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor'a.

Programowe i sprzętowe zerowanie dysku

Mikhail Morfikov — Tue, 24 Nov 2015 17:54:17 +0000

Zerowanie dysku twardego ma na celu usunięcie wszystkich znajdujących się na nim danych. Generalnie chodzi o zapisanie całej powierzchni danego nośnika samymi zerami. Ten proces różni się znacząco of formatowania dysku, czyli utworzenia nowego systemu plików, gdzie praktycznie wszystkie dane można bez większego problemu odzyskać. Zerowanie dysku (czy też pendrive) może w pewnych przypadkach naprawić logiczne błędy sektorów na dysku. Niemniej jednak, nie usuniemy za jego pomocą fizycznych bad'ów. Generalnie rzecz biorąc, mamy do wyboru dwie techniki zerowania. Jedna jest dokonywana na poziomie programowym, np. przy pomocy dd , druga zaś na poziomie sprzętowym, np. w hdparm . W tym wpisie postaramy się wyzerować przykładowy dysk.

Integralność plików passwd, group, shadow, gshadow

Mikhail Morfikov — Tue, 24 Nov 2015 12:30:34 +0000

W pliku /etc/passwd jest przechowywana baza danych kont użytkowników w systemie linux. Z kolei w /etc/group mamy wypisane wszystkie grupy oraz powiązanych z nimi użytkowników. Generalnie rzecz biorąc, to te dwa pliki odpowiadają za konfigurację kont. Problem jednak zaczyna się w momencie gdy w grę wchodzą hasła, zarówno do kont jak i do grup. Gdyby były one trzymane w tych plikach, nie byłyby one w żaden sposób szyfrowane. Dlatego też powstał inny mechanizm, który ma na celu przeniesienie zahashowanych haseł do plików /etc/shadow i /etc/gshadow . W debianie użytkownikami i grupami możemy zarządzać przy pomocy odpowiednich narzędzi, które automatycznie dostosują wszystkie powyższe pliki. Nic jednak nie stoi na przeszkodzie aby edytować każdy z nich ręcznie. Problemy mogą się pojawić w momencie, gdy te pliki będą zawierać różne wpisy, np. w pliku passwd będzie określony użytkownik, który jednocześnie nie będzie istniał w pliku shadow , podobnie z grupami. W tym wpisie postaramy się sprawdzić te pliki i upewnimy się czy aby na pewno jest z nimi wszystko w porządku.

Czy zmiana nazwy użytkownika root ma sens?

Mikhail Morfikov — Sat, 21 Nov 2015 19:52:58 +0000

Wielu ludzi potrafi się rozpisywać na temat bezpieczeństwa systemu linux jednocześnie nie zauważając jednego bardzo poważnego problemu. Wszyscy wiemy, że linux'y są bezpieczne min. przez fakt rozgraniczenia konta administratora od konta zwykłego użytkownika i nadaniu im różnych praw dostępu do poszczególnych części systemu operacyjnego. O ile konta użytkowników mają różne nazwy, o tyle administrator w praktycznie każdym linux'ie kryje się pod nazwą root . Znając nazwę konta, można próbować złamać hasło. To trochę dziwne, że nie można sobie arbitralnie ustalić nazwy dla tego konta tak by uniknąć wszelkich ataków, które związane są z logowaniem się na określonego użytkownika w systemie. W tym wpisie postaramy się prześledzić całą procedurę zmiany nazwy konta root na jakąś dowolną i zobaczymy czy wpłynie to w jakimś stopniu na pracę naszego systemu.