Sysctl on Morfitronik

Trim/discard przy LUKS/LVM na dysku SSD pod Debian linux

Mikhail Morfikov — Fri, 15 Dec 2023 17:00:00 +0100

Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux'a z włączonymi gałęziami unstable i experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux'a. Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim postawić świeżego Debiana z wykorzystaniem narzędzia debootstrap. Sama instalacja linux'a na dysku SSD nie różni się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu trim/discard. Standardowi użytkownicy linux'a nie muszą zbytnio nic robić, aby ten mechanizm został poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest device-mapper, który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku zaszyfrowanego systemu na bazie LUKS+LVM.

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

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

Mikhail Morfikov — Wed, 19 Aug 2020 19:31:00 +0200

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.

Konfiguracja HugePages pod maszyny wirtualne QEMU/KVM

Mikhail Morfikov — Sun, 09 Aug 2020 11:11:00 +0000

W linux rozmiar stron pamięci operacyjnej RAM ma domyślnie 4096 bajtów (4 KiB). Maszyny wirtualne QEMU/KVM mają to do siebie, że wykorzystują dość spore zasoby pamięci (wile GiB), przez co mały rozmiar strony może niekorzystnie wpływać na wydajność systemów gościa. Chodzi generalnie o to, że rozrostowi ulega tablica stron, której przeszukiwanie jest czasochłonną operacją. By temu zaradzić, wymyślono TLB (Translation Lookaside Buffer), który ulokowany jest albo w CPU albo gdzieś pomiędzy CPU i główną pamięcią operacyjną. TLB to mały ale za to bardzo szybki cache. W przypadku systemów z duża ilością pamięci RAM, niewielki rozmiar TLB sprawia, że odpowiedzi na zapytania nie są brane z cache, tylko system wraca do przeszukiwania normalnej tablicy stron zlokalizowanej w pamięci RAM (TLB miss). Taka sytuacja jest bardzo kosztowna, spowalnia cały system i dlatego trzeba jej unikać. Na szczęście jest mechanizm HugePages, który pozwala na zwiększenie rozmiaru strony pamięci z domyślnych 4 KiB do 2 MiB lub nawet do 1 GiB w zależności od właściwości głównego procesora. W tym artykule postaramy się skonfigurować HugePages na potrzeby maszyn wirtualnych dla systemu Debian Linux.

Unikanie SYN/ICMP/UDP/PING flood w linux z nftables

Mikhail Morfikov — Fri, 12 Apr 2019 20:12:42 +0000

Obecnie nftables cierpi dość mocno z powodu pewnych problemów związanych z wydajnością przy aplikowaniu reguł zapory sieciowej. Niemniej jednak, w stosunku do iptables , nftables posiada tablicę netdev , która jest w stanie nieco zyskać w oczach tych nieco bardziej wybrednych użytkowników linux'a. Chodzi generalnie o fakt, że ta tablica jest umieszczona zaraz na początku drogi pakietów, tuż po odebraniu ich z NIC (interfejsu karty sieciowej), a biorąc pod uwagę fakt, że ruch sieciowy, który nigdy ma nie trafić do naszej maszyny, powinien być zrzucany jak najwcześniej (by nie marnować zasobów procesora i pamięci), to ta tablica wydaje się być idealnym miejscem by zablokować cały niepożądany ruch przychodzący. Przy wykorzystaniu iptables , takie pakiety zrzuca się w tablicy raw . Jeśli zaś chodzi o nftables , to zrzucanie pakietów w tablicy netdev jest ponad dwu lub nawet trzykrotnie bardziej wydajne (szybsze i mniej zasobożerne). Można zatem dość dobrze poradzić sobie z wszelkiego rodzaju atakami DOS/DDOS, np. ICMP/PING flood czy SYN flood. Zastanawiające może być natomiast ogarnięcie ataku UDP flood ale przed tym rodzajem ataku linux również jest w stanie się bez problemu ochronić.

Jak włączyć IPv6 Privacy Extensions w Debianie (SLAAC)

Mikhail Morfikov — Sun, 10 Feb 2019 08:22:55 +0000

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.

packet_write_wait: Connection to IP port 22: Broken pipe

Mikhail Morfikov — Wed, 03 Aug 2016 13:41:52 +0000

Operowanie na VPS nie jest jakoś specjalnie trudne, zwłaszcza w przypadku, gdy mamy dostęp root i możemy logować się na serwer z wykorzystaniem protokołu SSH. Dalej to już zwykła linux'owa mechanika, która może być nieco inna, w zależności od tego, jaki dokładnie system operacyjny na tym VPS stoi. Czasami jednak, w pewnym momencie podczas połączenia możemy zostać rozłączeni z niewiadomych nam przyczyn. Niemniej jednak, zawsze, gdy ten problem występuje, w terminalu można zobaczyć komunikat: packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe . Przydałoby się zatem coś na ten stan rzeczy poradzić.

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?

Równoważenie ruchu łącz kilku ISP (load balancing)

Mikhail Morfikov — Sun, 22 May 2016 13:40:04 +0000

Podłączenie pojedynczego komputera do sieci raczej nie stanowi żadnego problemu dla przeciętnego użytkownika linux'a. Wystarczy jedynie skonfigurować kilka parametrów i możemy oglądać swoje ulubione serwisy www. Co jednak w przypadku, gdy mamy do dyspozycji kilka łącz internetowych? Jedną z opcji jest używanie łącza tego ISP, które jest lepsze gabarytowo, a pozostałe łącza trzymać na wypadek awarii tego pierwszego. Nie jest to zbytnio satysfakcjonujące rozwiązanie, zwłaszcza w przypadku, gdy tym providerom płacimy za świadczone nam usługi. W taki sposób płacimy, np. za dwa łącza, a korzystamy z jednego w danej chwili. W linux'ie obsługa wielu łącz różnych ISP jest dość skomplikowana. By taki mechanizm zaimplementować sobie, trzeba stworzyć kilka tablic routingu. Następnie ruch sieciowy musi zostać oznaczony w iptables i przekierowany do tych tablic przez kernel. Przy odrobienie wysiłku jesteśmy jednak w stanie zaprojektować sobie load balancer, który będzie równoważył obciążenie łącza między kilku ISP. Dodatkowo, jeśli jedno z łączy nam nawali, to automatycznie zostaniemy przełączeni na drugie łącze (failover). W tym artykule postaramy się zaprojektować taki właśnie mechanizm.

Implementacja protokołu IPv6 za pomocą tunelu 6to4

Mikhail Morfikov — Thu, 04 Feb 2016 16:57:37 +0000

Ogromna cześć lokalnych ISP zdaje się nie nadążać za ciągle zmieniającą się rzeczywistością. Problem dotyczy implementacji protokołu IPv6, który jest już z nami od bardzo wielu lat. W przypadku mojego obecnego ISP raczej nie mam co liczyć na to, by w bliżej nieokreślonej przyszłości dodał on obsługę tego protokołu. Istnieje jednak mechanizm zwany tunelowaniem pakietów protokołu IPv6 wewnątrz pakietów protokołu IPv4 (w skrócie 6to4), którym warto się zainteresować. W ogromnym skrócie, część puli adresowej IPv6 jest zarezerwowana i zmapowana na adresy protokołu IPv4. Dzięki takiemu podejściu, każdy kto posiada stały zewnętrzny adres IPv4 ma również adres w puli IPv6. Mając zatem zarezerwowany adres, możemy pokusić się o utworzenie tunelu 6to4, co aktywuje w naszej infrastrukturze ten nowszy protokół obchodząc jednocześnie ograniczenia ISP. Trzeba jednak mieć na względzie, że nie jest to natywne wsparcie dla protokołu IPv6 i jest niemal pewne, że wystąpią mniejsze lub większe problemy z wydajnością.

Aktywacja i konfiguracja klawisza SysRq

Mikhail Morfikov — Thu, 29 Oct 2015 01:57:30 +0000

SysRq (System Request) to klawisz na klawiaturze, po którego przyciśnięciu można wysłać niskopoziomowe zapytana bezpośrednio do kernela linux'a. Te komendy działają nawet w przypadku pozornego braku kontaktu z systemem operacyjnym, tj. zacięcia dźwięku, nieruchomy kursor myszy, a nawet w przypadku braku możliwości wpisywania znaków z klawiatury. Zwykle po opisanych wyżej symptomach, człowiek jest skłonny przycisnąć przycisk reset na obudowie swojego komputera, no bo jak inaczej odwiesić taki system? Problem z twardym resetem (za pomocą przycisku) jest taki, że praktycznie zawsze po nim występuje uszkodzenie struktury systemu plików na dysku, a czasami uszkodzeniu ulega cała partycja. To niesie ze sobą ryzyko utraty danych. Dlatego też powinniśmy zaprzestać resetowania komputerów przy pomocy przycisków i zacząć korzystać z klawisza SysRq .

Automatyczny restart maszyny po kernel panic

Mikhail Morfikov — Wed, 28 Oct 2015 23:56:51 +0000

Gdy nasz linux napotka z jakiegoś powodu błąd wewnątrz swojej struktury, to istnieją sytuacje, w których obsługa tego błędu czasem nie jest możliwa. Wobec czego, zostaje wyrzucony komunikat systemowy oznajmiający nam, że kernel spanikował (kernel panic), bo nie wie co w takim przypadku zrobić. Gdy tego typu sytuacja się nam przytrafia, nie ma innego wyjścia jak tylko uruchomić system ponownie. Co jednak w przypadku gdy pracujemy zdalnie i nie jesteśmy w stanie zresetować takiej maszyny fizycznie? Na szczęście kernel ma kilka opcji, które mogą zainicjować automatyczny restart w przypadku wystąpienia kernel panic.

Mechanizm SYN cookies w protokole TCP

Mikhail Morfikov — Sat, 24 Oct 2015 20:22:02 +0000

Atak SYN flood to rodzaj ataku DoS, którego celem jest wyczerpanie zasobów serwera uniemożliwiając mu tym samym poprawne realizowanie danej usługi, do której został oddelegowany. Jest to dość popularne zjawisko i w przypadku, gdy mamy postawioną jakąś maszynę na publicznym adresie IP, przydałoby się nieco zainteresować tym problem, który może wystąpić w najmniej oczekiwanym momencie. W tym wpisie rzucimy okiem na mechanizm SYN cookies.

Unikanie ataków DDoS z SYNproxy

Mikhail Morfikov — Sat, 24 Oct 2015 17:39:24 +0000

Internet nie jest zbyt przyjaznym miejscem i jest wielce prawdopodobne, że prędzej czy później ktoś zaatakuje jedną z naszych maszyn, która świadczy w nim jakieś usługi. Są różne typy ataków, w tym przypadku chodzi o ataki DDoS z wykorzystaniem pakietów wchodzących w proces potrójnego witania (three way handshake) przy nawiązywaniu połączenia w protokole TCP, tj. pakiety SYN , SYN-ACK i ACK . Istnieje szereg mechanizmów, które adresują problem SYN flooding'u ale żaden z nich nie jest doskonały. Jakiś czas temu, do kernela linux'owego trafił patch implementujący mechanizm SYNproxy i w tym wpisie obadamy go sobie nieco dokładniej.

Retransmisja i duplikaty pakietów w TCP

Mikhail Morfikov — Wed, 23 Sep 2015 19:31:27 +0000

Retransmisja pakietu w przypadku sieci opartych na protokołach TCP/IP nie jest niczym niezwykłym. Oczywiście, pozostaje kwestia samego realizowania tego przedsięwzięcia ale generalnie rzecz biorąc, systemy linux'owe mają szereg opcji w kernelu, które możemy sobie dostosować konfigurując tym samym, to w jaki sposób nasz system reaguje na zjawisko utraty pakietów podczas ich przesyłu między dwoma punktami sieciowymi.

Aplikowanie zmiennych sysctl przy pomocy udev'a

Mikhail Morfikov — Sun, 06 Sep 2015 11:08:42 +0000

Kernele linux'owe mają dość sporo opcji, które możemy zmienić przy pomocy pliku /etc/sysctl.conf . Niby nic nadzwyczajnego ale co w przypadku tych zmiennych, które muszą być ustawione, z tym, że moduł, który stworzy odpowiednie ścieżki w katalogu /proc/sys/ , nie został załadowany z jakichś względów przy starcie systemu? Zmienne te nie zostaną ustawione, a w logu pojawi się komunikat informujący nas o nieodnalezieniu określonego pliku. Okazuje się, że jesteśmy w stanie aplikować określone ustawienia sysctl w momencie ładowania określonych modułów i temu mechanizmowi się przyjrzymy bliżej w tym wpisie.

Wolny start połączeń w protokole TCP

Mikhail Morfikov — Tue, 07 Jul 2015 19:33:16 +0000

Wolny start jest wynikiem braku zaufania maszyny nadawczej do utworzonego kanału przesyłowego -- połączenia. Nie wie ona czy to łącze jest bowiem w stanie obsłużyć taką porcję danych, którą ma zamiar przesłać bez czekania na pakiet ACK . W przypadku bufora odbiorczego, wszystko jest proste, bo dane dotyczące wielkości okien są zdefiniowane w nagłówku pakietów, do których ma wgląd druga ze stron. W przypadku gdy nadawca przesyła dane, prędkość z jaką to robi zależy głównie od niego.

Bufor połączeń w protokole TCP

Mikhail Morfikov — Wed, 01 Jul 2015 10:20:16 +0000

Wraz ze zwiększaniem zapotrzebowania na szybsze łącza internetowe, ograniczenia wynikające z protokółu TCP zaczęły powoli dawać się ludziom we znaki. Problemem była bariera prędkości, którą ciężko było pokonać mając do dyspozycji domyślną formę nagłówka protokołu TCP. Było w nim zwyczajnie za mało miejsca, co zapoczątkowało jego rozbudowę kosztem ilości danych, które można było przesłać w pojedynczym segmencie. W tym wpisie skupię się głównie na dwóch opcjach jakie zostały dodane do nagłówka TCP, tj. dynamiczne skalowanie okien oraz znaczniki czasu, bo te dwa parametry nie mogą wręcz bez siebie istnieć, zwłaszcza gdy rozmawiamy o łączach pokroju 1 czy 10 gbit/s.

SACK, czyli selektywne potwierdzenia pakietów

Mikhail Morfikov — Wed, 01 Jul 2015 06:04:18 +0000

Protokół TCP jest tak zbudowany by zapewnić rzetelny transfer danych między dwoma komunikującymi się punktami. Z początku jednak, ta cecha tego protokołu powodowała marnowanie dość sporych ilości zasobów jeśli chodzi o przepustowość łącza. Stało się to widoczne przy większych prędkościach połączeń, gdzie skalowany był bufor (okno) TCP, co umożliwiło przesyłanie szeregu segmentów bez potrzeby czekania na ich potwierdzenie przez odbiorcę. To zwiększyło, co prawda, transfer danych ale pojawił się problem z zagubionymi pakietami.