kernel

Czy brak wsparcia dla SYNPROXY w nftables jest problemem

Przenosząc swoje reguły z iptables na nftables zauważyłem, że jedna z nich (gdyby tylko jedna) nie została przetłumaczona przez ten dedykowany translator do reguł. Chodzi o mechanizm SYNPROXY, który jest zwykle wykorzystywany do ograniczenia skali ataków DDOS z wykorzystaniem pakietów SYN. Co by nie mówić, to ochrona jaką daje SYNPROXY jest jak najbardziej pożądana z perspektywy serwerów. Dlaczego zatem, gdy się zajrzy na stronę wspieranych rzeczy w nftables, to przy SYNPROXY widnieje bliżej nieokreślone sformułowanie consider native interface ? Po rozmowach z deweloperami udało się ustalić, że ten zapis oznacza brak wsparcia dla SYNPROXY w nftables . Jeśli zatem ktoś wykorzystuje ten mechanizm mając dodane stosowne reguły w iptables , to czy powinien się on obawiać przejścia na nftables ?

Jak ręcznie zweryfikować sygnaturę modułu kernela linux

Bawiąc się ostatnio kernelem linux na dystrybucji Debian i opcjami mającymi poprawić jego bezpieczeństwo, włączyłem sobie mechanizm podpisywania modułów. W ten sposób żaden zewnętrzny moduł nie zostanie załadowany przez jądro operacyjne, no chyba, że taki moduł będzie podpisany przez ten sam klucz co i kernel. Zdziwiłem się odrobinę, gdy moim oczom pokazał się hash md4 w wyjściu polecenia modinfo . Jak się okazało później, to niezbyt dokładne zinterpretowanie wiadomości PKCS#7 przez kmod było (i nadal jest) wynikiem błędu obecnego w tym pakiecie od już paru lat. W efekcie modinfo nie jest w stanie zweryfikować tej sygnatury, a w moim umyśle zaistniało pytanie: czy istnieje w ogóle możliwość manualnego sprawdzenia czy ta sygnatura jest w porządku? Kernel co prawda ten cały zabieg przeprowadza automatycznie ale przydałoby się ręcznie zweryfikować poprawność sygnatury modułu i przy okazji obadać sobie co tak naprawdę się dzieje podczas tego procesu.

Automatyczne podpisywanie modułów kernela przez DKMS

Budując kernel linux'a trzeba zastanowić się nad kwestią modułów, które nie są wbudowane bezpośrednio w samo jądro operacyjne. Nie chodzi tutaj bezpośrednio o funkcjonalność kernela, którą można zbudować jako moduł w procesie jego kompilacji ale raczej o wszystkie zewnętrzne moduły, które przez zespół kernela są traktowane jako out-of-tree . By poprawić nieco bezpieczeństwo związane z takimi modułami, można wdrożyć podpisy cyfrowe, które takie moduły muszą okazać podczas próby załadowania ich w systemie. Gdy moduł nie został podpisany, to kernel go nie załaduje zwracając przy tym błąd modprobe: ERROR: could not insert 'module': Required key not available . W ten sposób można ochronić się przed częścią ataków, w których moduły pochodzenia trzeciego mogą zostać załadowane i poczynić nam ogromne spustoszenie w systemie. Problem w tym, że w dystrybucji Debian wykorzystywany jest mechanizm DKMS (Dynamic Kernel Module Support). Może i mamy dzięki niemu możliwość instalacji w systemie całej masy dodatkowych modułów ale ich również nie będzie można załadować, bo nie zostały podpisane kluczem, którego certyfikat został zaszyty w kernelu. Można jednak zmusić mechanizm DKMS, by wskazane przez nas moduły podpisywał automatycznie przy ich instalacji i aktualizacji.

Budowanie kernela linux dla konkretnej maszyny z Debianem

Każda maszyna działająca pod kontrolą dystrybucji linux ma na swoim pokładzie kernel, czyli jądro operacyjne, które zarządza praktycznie każdym aspektem pracy takiego komputera. W dystrybucji Debian, kernel jest dostarczany w pakietach mających nazwy zaczynające się od linux-image-*. Te pakiety są budowane przez odpowiednie osoby z zespołu Debiana i udostępniane do łatwej instalacji użytkownikowi końcowemu. Niemniej jednak, taki kernel ma za zadanie działać na jak największej ilości komputerów, a przez to posiada całą masę modułów, które na naszej maszynie nigdy nie będą wykorzystane. Ten fakt nie wpływa w jakimś ogromnym stopniu na pracę maszyny, ale gdy później zachodzi potrzeba skonfigurowania kernela w nieco inny sposób, np. włączenie jednej czy dwóch opcji czy też nałożenie patch'a, który nie został zaaplikowany przez dev'ów Debiana, to trzeba taki kernel na nowo skompilować już samodzielnie, a to zajmie nam bardzo dużo czasu. Zamiast tego można pokusić się o przygotowanie kernela pod konkretny hardware wyłączając przy tym całą masę zbędnych rzeczy i ograniczając przy tym czas jaki jest potrzebny na zbudowanie całego jądra operacyjnego. Czy istnieje jakiś prosty sposób, by taki kernel zbudować sobie samemu mając przy tym minimalną wiedzę co do opcji kernela, które mogą nas przysporzyć o ból... głowy? Okazuje się, że tak i w tym artykule prześledzimy sobie cały ten proces.

Jak zdiagnozować kernel OOPS

Kernel linux'a, jak każdy inny program, podczas swojego działania może napotkać nieprzewidzianą przez programistów sytuację. W przypadku zwykłych aplikacji, pewne błędy krytyczne mogą doprowadzić do "naruszenia ochrony pamięci", co szerzej jest znane jako segfault. W przypadku wystąpienia tego błędu, proces zwykle jest unicestwiany. Co jednak w przypadku kernela? Odpowiedź jest prosta: kernel panic, czyli panika kernela, która pozostawia system w stanie braku jakichkolwiek oznak życia. Są jednak pewne błędy, z którymi kernel jest w stanie sobie poradzić i odzyskać sprawność w mniejszym lub większym stopniu. Te błędy są nazywane kernel OOPS. W tym wpisie postaramy się przeanalizować przykładowy OOPS i zobaczymy czy uda nam się ustalić przyczynę zaistniałego problemu.

Konfiguracja interfejsów IMQ w linux'ie

W linux'ie, kształtowanie przychodzącego ruchu sieciowego stwarza dość poważne problemy. Na dobrą sprawę, obecnie w kernelu nie ma żadnego mechanizmu, który byłby w stanie to zadanie realizować. Istnieją, co prawda, interfejsy IFB ale za ich pomocą jesteśmy w stanie z powodzeniem kształtować jedynie ruch wychodzący. W przypadku pakietów napływających, możemy jedynie ograniczyć im przepustowość. W tym powyższym linku jest wzmianka, że te interfejsy IFB są następcą interfejsów IMQ. Niemniej jednak, ten drugi projekt zdaje się działać, choć nie jest obecnie wspierany przez kernel linux'a. W tym wpisie postaramy się skonfigurować działające interfejsy IMQ, tak, by za ich pomocą skutecznie kształtować ruch przychodzący.

Aktywacja i konfiguracja klawisza SysRq

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

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.

Reinstalacja kernela i bootloader'a

Wykorzystywanie pełnego szyfrowania dysku twardego ma jedną zasadniczą wadę. O ile nasze dane są należycie zabezpieczone, o tyle trzeba zwracać uwagę na to komu zezwalamy na dostęp do naszego komputera. Nie chodzi tutaj o to, kto będzie używał samego systemu operacyjnego, choć to też jest ważne, ale przede wszystkim chodzi o te osoby, które mają dostęp fizyczny do naszej maszyny. Czasem możemy nabrać podejrzenia, że ktoś mógł nam jakąś pluskwę podłożyć. Wykrycie takiego robala, np. w postaci sprzętowego keylogger'a, nie powinno sprawić problemów. Z kolei już manipulacja boot sektorem dysku twardego, lub też zmiany w initramfs, który znajduje się na niezaszyfrowanej partycji /boot/ mogą przejść niezauważone. Jak zatem odratować system, co do którego mamy jakieś zastrzeżenia?

Zawartość obrazu z modułami kernela (initrd)

Podczas instalowania jądra operacyjnego w jakiejś dystrybucji linux'a, w katalogu /boot/ jest tworzonych kilka plików. Mamy tam między innymi initrd.img i jest to obraz posiadający swój własny system plików, który jest ładowany do pamięci RAM w fazie boot (via bootloader). W tym obrazie znajdują się moduły i narzędzia, przy pomocy których to główny system plików naszego linux'a może zostać zamontowany. Czasem jednak potrzebujemy zajrzeć wgłąb tego obrazu, a to nie jest znowu taka prosta sprawa.