Kontynuując rozwój projektu GuardX 2.0, skupiłem się tym razem na monitorowaniu warstwy buforowania (Caching Layer) w środowiskach opartych o system FreeBSD, pule ZFS oraz izolowane klatki Bastille.
Standardowe rozwiązania do monitorowania Redis czy Valkey wymagają instalowania zewnętrznych agentów wewnątrz klastrów, ręcznej konfiguracji haseł lub otwierania dodatkowych portów sieciowych. W nowym module cacheredis_program podszedłem do tematu całkowicie niskopoziomowo, opierając całą logikę na bezpośrednich odpytaniach jądra systemowego w języku C++.
Oto szczegółowy przegląd techniczny nowego modułu oraz mechanizmów, które w nim zaimplementowałem.
Automatyczne wykrywanie instancji na Hoście i w Klatkach
Moduł automatycznie skanuje system w poszukiwaniu uruchomionych procesów redis-server oraz valkey-server, rozróżniając, czy działają one bezpośrednio na hoście, czy w konkretnych klatkach (Jails).
Jak to działa pod maską?
Zamiast tradycyjnego, wolnego skanowania portów sieciowych z zewnątrz, program odpytuje jądro FreeBSD za pomocą wywołania systemowego sysctl (KERN_PROC_PROC). Pozwala to na natychmiastowe uzyskanie listy procesów z zerowym narzutem na procesor.
Następnie moduł koreluje numery PID procesów z tablicami nasłuchujących gniazd sieciowych za pomocą narzędzia sockstat. W przypadku klatek korzystających z wirtualizacji sieci (VNET) lub shared ip, program dynamicznie odpytuje demona systemowego o przypisany do klatki interfejs (jls / jexec), dzięki czemu zawsze trafia pod właściwy adres IP, pomijając ograniczenia pętli zwrotnej (127.0.0.1).
Dynamiczna ekstrakcja haseł bez konfiguracji
Problem:
W nowoczesnych konfiguracjach każda klatka kliencka posiada własne, unikalne i silne hasło autoryzacji (requirepass). Trzymanie wszystkich tych haseł w centralnym pliku konfiguracyjnym GuardX byłoby uciążliwe i nietrwałe, czy wręcz niewykonalne.
Rozwiązanie:
Ponieważ demon GuardX wykonuje się z uprawnieniami roota na hoście, nowy moduł realizuje tzw. audyt lokalny. Gdy program zlokalizuje instancję bazy w klatce, odczytuje ścieżkę punktu montowania datasetu tej klatki (jls path). Następnie analizuje argumenty startowe procesu, znajduje plik konfiguracyjny (np. redis.conf lub valkey.conf) mieszczący się wewnątrz struktury klatki i w locie wyciąga z niego linię requirepass.
Dzięki temu moduł automatycznie autoryzuje się do każdej bazy danych, całkowicie zdejmując z administratora obowiązek ręcznego wpisywania haseł w plikach konfiguracyjnych monitora.
Pamięć RAM i wskaźnik wydajności (Hit Ratio)
Moduł zbiera i sumuje całkowite zużycie pamięci operacyjnej przez wszystkie instancje bufora oraz wylicza uśredniony wskaźnik trafień (Hit Ratio).
Jak to działa pod maską?
Zużycie pamięci nie opiera się na zawodnych zapytaniach tekstowych, lecz jest odczytywane bezpośrednio z jądra FreeBSD na podstawie wskaźnika rezydentnego RAM-u (ki_rssize) dla każdego PID-u. Daje to stuprocentowo precyzyjny odczyt fizycznego obciążenia pamięci (RAM OS), niezależnie od tego, czy baza odrzuci zapytanie ze względu na uprawnienia.
Z kolei statystyki operacyjne (Hit Ratio) pobierane są za pomocą lekkich, nieblokujących gniazd POSIX przy użyciu surowego protokołu RESP (INFO STATS). Całość zabezpieczono przed przerwaniami sieciowymi przez ignorowanie sygnałów SIGPIPE oraz zastosowano zapasowe bufory dynamiczne dla struktury sysctl, co całkowicie eliminuję błędy wyścigu (race conditions) przy nagłej rotacji procesów w systemie.
Analiza formatów danych PHP (ZSTD i Igbinary)
Moduł weryfikuje, czy aplikacje PHP uruchomione w klatkach wykorzystują zaawansowane mechanizmy kompresji danych i serializatory.
Jak to działa pod maską?
Ponieważ serwery Redis i Valkey traktują dane jako surowe ciągi bajtów, program wykonuje krótką procedurę heurystyczną: pobiera losowy klucz z bazy (RANDOMKEY), a następnie odczytuje jego payload (GET).
W oparciu o analizę binarną tzw. Magic Bytes na początku bufora, moduł weryfikuje nagłówki. Dla kompresji zstd wykrywana jest charakterystyczna sekwencja bajtów Little Endian (0x28 0xB5 0x2F 0xFD), co pozwala potwierdzić, że potok optymalizacji danych w aplikacjach webowych działa prawidłowo.
Podsumowanie
Wprowadzenie cacheredis_program domyka architekturę monitorowania warstwy danych w GuardX 2.0. Zyskaliśmy precyzyjny, w pełni bezinwazyjny podgląd na kondycję baz Redis i Valkey w rozproszonym środowisku klatek FreeBSD. Brak konieczności instalowania agentów, automatyczne wyciąganie haseł z konfiguracji klatek oraz mikrosekundowy czas wykonania sprawiają, że moduł idealnie wpisuje się w założenia wydajnościowe całego demona.
