Projekt Openwalla wydanie modułu jądra (Linux Kernel Runtime Guard), przeznaczony do wykrywania i blokowania ataków oraz naruszeń integralności struktur jądra. Moduł może na przykład chronić przed nieautoryzowanymi zmianami w działającym jądrze i próbami zmiany uprawnień procesów użytkownika (wykrywając wykorzystanie exploitów). Moduł nadaje się zarówno do organizacji ochrony przed znanymi już exploitami dla jądra Linuksa (na przykład w sytuacjach, gdy trudno jest zaktualizować jądro w systemie), jak i do przeciwdziałania exploitom dla jeszcze nieznanych luk. Kod projektu licencjonowany na licencji GPLv2.
Wśród zmian w nowej wersji:
- Zmieniło się pozycjonowanie projektu LKRG, który nie jest już podzielony na osobne podsystemy sprawdzania integralności i określania wykorzystania exploitów, ale jest prezentowany jako kompletny produkt do identyfikacji ataków i różnych naruszeń integralności;
- Zapewniona jest kompatybilność z jądrami Linuksa od 5.3 do 5.7, a także z jądrami skompilowanymi z agresywnymi optymalizacjami GCC, bez opcji CONFIG_USB i CONFIG_STACKTRACE lub z opcją CONFIG_UNWINDER_ORC, a także z jądrami, które nie mają funkcji podłączonych do LKRG, jeśli to możliwe zrezygnować z;
- Podczas budowania sprawdzane są niektóre obowiązkowe ustawienia jądra CONFIG_*, aby wygenerować znaczące komunikaty o błędach zamiast niejasnych awarii;
- Dodano obsługę trybów gotowości (ACPI S3, zawieszenie do RAM) i uśpienia (S4, zawieszenie do dysku);
- Dodano obsługę DKMS do Makefile;
- Zaimplementowano eksperymentalne wsparcie dla 32-bitowych platform ARM (testowane na Raspberry Pi 3 Model B). Dostępna wcześniej obsługa AArch64 (ARM64) została rozszerzona, aby zapewnić kompatybilność z płytą Raspberry Pi 4;
- Dodano nowe zaczepy, w tym procedurę obsługi wywołań zdolną(), aby lepiej identyfikować exploity manipulujące „", a nie identyfikatory procesów ();
- Zaproponowano nową logikę wykrywania prób ominięcia ograniczeń przestrzeni nazw (na przykład z kontenerów Docker);
- W systemach x86-64 sprawdzany i stosowany jest bit SMAP (Zapobieganie dostępowi w trybie nadzorcy), którego zadaniem jest blokowanie dostępu do danych przestrzeni użytkownika z uprzywilejowanego kodu działającego na poziomie jądra. Zabezpieczenie SMEP (Zapobieganie wykonywaniu trybu nadzorcy) zostało wdrożone wcześniej;
- Podczas pracy ustawienia LKRG są umieszczane na stronie pamięci, która jest zwykle tylko do odczytu;
- Rejestrowanie informacji, które mogą być najbardziej przydatne w przypadku ataków (na przykład informacje o adresach w jądrze) ogranicza się do trybu debugowania (log_level=4 i wyższy), który jest domyślnie wyłączony.
- Zwiększono skalowalność bazy danych śledzenia procesów - zamiast jednego drzewa RB chronionego jedną blokadą spinlock, zastosowano tablicę mieszającą składającą się z 512 drzew RB chronionych 512 blokadami odczytu i zapisu;
- Domyślnie zaimplementowano i udostępniono tryb, w którym często sprawdzana jest integralność identyfikatorów procesów tylko dla bieżącego zadania, a opcjonalnie także dla zadań aktywowanych (budzących). W przypadku innych zadań, które są w stanie uśpienia lub działają bez dostępu do API jądra kontrolowanego przez LKRG, sprawdzenie jest wykonywane rzadziej.
- Dodano nowe parametry sysctl i modułu do dostrajania LKRG, a także dwa sysctl do uproszczonej konfiguracji poprzez wybór z zestawów ustawień dostrajających (profili) przygotowanych przez programistów;
- Ustawienia domyślne zostały zmienione, aby osiągnąć bardziej zrównoważoną równowagę pomiędzy szybkością wykrywania naruszeń i skutecznością reakcji z jednej strony, a wpływem na wydajność i ryzykiem fałszywych alarmów z drugiej;
- Plik jednostki systemowej został przeprojektowany, aby ładować moduł LKRG na początku rozruchu (do wyłączenia modułu można użyć opcji wiersza poleceń jądra);
Biorąc pod uwagę optymalizacje zaproponowane w nowej wersji, zmniejszenie wydajności podczas korzystania z LKRG 0.8 szacuje się na 2.5% w trybie domyślnym („ciężkim”) i 2% w trybie lekkim („lekkim”).
W niedawno odbytym skuteczność pakietów do wykrywania rootkitów LKRG najlepsze wyniki, identyfikując 8 z 9 przetestowanych rootkitów działających na poziomie jądra bez fałszywych alarmów (rootkity Diamorphine, Honey Pot Bears, LilyOfTheValley, Nuk3 Gh0st, Puszek, Reptile, Rootfoo Linux Rootkit i Sutekh zostały zidentyfikowane, ale Keysniffer, który jest jądrem moduł został pominięty przez keylogger, a nie rootkit w dosłownym tego słowa znaczeniu). Dla porównania pakiety AIDE, OSSEC i Rootkit Hunter wykryły 2 z 9 rootkitów, podczas gdy Chkrootkit nie wykrył żadnego. Jednocześnie LKRG nie obsługuje wykrywania rootkitów znajdujących się w przestrzeni użytkownika, dlatego największą skuteczność osiąga się przy zastosowaniu kombinacji AIDE i LKRG, co umożliwiło zidentyfikowanie 14 z 15 rootkitów wszystkich typów.
Dodatkowo można zauważyć, że deweloper dystrybucji zaczął gotowe pakiety z DKMS dla Debiana, Whonix, Qubes i Kicksecure oraz pakiet dla już zaktualizowany do wersji 0.8. Pakiety z LKRG dostępne są także w języku rosyjskim и .
Sprawdzanie integralności w LKRG odbywa się poprzez porównanie rzeczywistego kodu i danych jądra i modułów, niektórych ważnych struktur danych i ustawień procesora z przechowywanymi skrótami lub kopiami odpowiednich obszarów pamięci, struktur danych lub rejestrów. Kontrole są aktywowane zarówno okresowo przez timer, jak i po wystąpieniu różnych zdarzeń.
Określenie możliwości wykorzystania exploitów i zablokowanie ataków odbywa się na etapie zanim jądro udostępni zasoby (np. przed otwarciem pliku), ale po uzyskaniu przez proces nieautoryzowanych uprawnień (np. zmiany UID). W przypadku wykrycia nieautoryzowanego zachowania procesy są domyślnie zmuszane do zakończenia, co wystarcza do zablokowania wielu exploitów.
Źródło: opennet.ru