Wyobraź sobie, że w piątek po południu ktoś podmienia plik wp-config.php na Twojej stronie firmowej albo dopisuje nową regułę do harmonogramu zadań na serwerze księgowości. Nikt tego nie zauważa do poniedziałku. Do poniedziałku baza klientów jest już gdzieś indziej, a strona rozsyła spam. Właśnie po to istnieje FIM, czyli monitoring integralności plików: mechanizm, który zauważa taką zmianę w ciągu minut, a nie dni.
Czym właściwie jest FIM
File Integrity Monitoring w Wazuh działa na zasadzie prostej, ale skutecznej: agent buduje bazę referencyjną wskazanych plików i katalogów, licząc dla każdego z nich sumę kontrolną (hash) oraz zapisując metadane: rozmiar, uprawnienia, właściciela, datę modyfikacji. Od tego momentu każde skanowanie porównuje aktualny stan ze stanem referencyjnym. Jeśli plik się zmienił, zniknął albo pojawił się nowy tam, gdzie nie powinien, Wazuh generuje alert z konkretną informacją: co się zmieniło, kiedy i (jeśli system to udostępnia) kto był zalogowany w danym momencie.
To zasadnicza różnica względem antywirusa czy firewalla. FIM nie ocenia, czy plik jest „zły”. On po prostu mówi: ten plik jest inny niż wczoraj. Reszta pracy, czyli ocena czy to zmiana legalna (aktualizacja, wdrożenie), czy podejrzana, należy do administratora albo do reguł korelacji w Wazuh, które mogą podnieść priorytet alertu, gdy zmiana dotyczy pliku systemowego albo pojawia się poza godzinami pracy.
Co obejmować nadzorem w małej firmie
Nie ma sensu monitorować całego dysku, bo utopisz się w alertach już pierwszego dnia. W praktyce w firmie zatrudniającej kilkanaście do kilkudziesięciu osób sensowny zakres wygląda tak:
- Katalogi systemowe i /etc: pliki konfiguracyjne systemu, sudoers, cron, ustawienia sieci. To tam najczęściej zostawia ślad każdy, kto próbuje uzyskać trwały dostęp do serwera.
- Pliki konfiguracyjne aplikacji: konfiguracje baz danych, serwerów pocztowych, VPN, kontrolerów domeny. Zmiana w takim pliku często oznacza próbę otwarcia sobie tylnej furtki.
- Katalogi serwisów WWW: pliki PHP, motywy WordPressa, wtyczki, katalogi uploads. Podmiana pliku wykonywalnego albo dopisanie webshella zwykle zaczyna się właśnie tutaj.
- Foldery z danymi księgowymi i dokumentacją firmową: katalogi sieciowe z fakturami, umowami, kadrami. To te dane najczęściej pada łupem ransomware, więc masowa zmiana w tym miejscu jest sygnałem alarmowym.
Zakres nadzoru powinien odzwierciedlać to, co faktycznie jest krytyczne dla firmy, a nie kopiować gotową listę z internetu. Serwer plików księgowości i serwer testowy dla stażysty nie zasługują na ten sam poziom uwagi. W praktyce najlepiej zacząć od jednego, dwóch krytycznych hostów, dopiąć na nich sensowny zakres monitoringu, a dopiero potem rozszerzać konfigurację na kolejne maszyny w firmie. Próba objęcia wszystkiego od razu, pierwszego dnia, zwykle kończy się tym, że nikt nie ma czasu przejrzeć setek alertów i po tygodniu FIM zostaje wyciszony.
Jak czytać alerty i nie utonąć w szumie
Pierwsze tygodnie po włączeniu FIM to zwykle fala alertów o aktualizacjach systemowych, logach rotujących co godzinę i plikach tymczasowych aplikacji. Jeśli tego nie ograniczysz, zespół szybko przestanie czytać powiadomienia, a to najgorsze, co może się stać w monitoringu bezpieczeństwa.
- Wykluczenia (ignore): wyłącz z monitoringu katalogi z logami, cache, plikami tymczasowymi i wszystkim, co zmienia się rutynowo w ramach normalnej pracy aplikacji.
- Częstotliwość skanów: dla większości katalogów wystarczy skan cykliczny, na przykład co 12 godzin. To dobry kompromis między aktualnością danych a obciążeniem serwera.
- Tryb real-time dla ścieżek wrażliwych: katalogi typu /etc, katalog główny strony WWW czy foldery księgowe warto objąć monitoringiem w czasie rzeczywistym (whodata albo realtime w konfiguracji syscheck). Zmiana jest wtedy widoczna niemal natychmiast, a nie po kilku godzinach.
- Priorytetyzacja: skonfiguruj reguły tak, by zmiana w pliku wykonywalnym albo w uprawnieniach generowała alert wyższego poziomu niż zwykła aktualizacja pliku konfiguracyjnego.
Dobrym nawykiem jest też przegląd alertów FIM co tydzień, nawet jeśli nic „czerwonego” się nie pojawiło. Wzorzec zmian, na przykład regularne modyfikacje pliku, którego nikt świadomie nie edytuje, często zdradza problem zanim urośnie do rozmiaru incydentu. Wazuh pozwala też grupować podobne alerty i tworzyć reguły korelacji, na przykład: kilkadziesiąt zmian plików z jednego adresu IP w ciągu minuty to zupełnie inny poziom zagrożenia niż pojedyncza edycja pliku konfiguracyjnego przez administratora.
Rootcheck i wykrywanie rootkitów
Obok FIM Wazuh ma moduł rootcheck, który działa nieco inaczej: skanuje system w poszukiwaniu znanych sygnatur rootkitów, podejrzanych ukrytych procesów, portów nasłuchujących bez powiązanego procesu czy plików binarnych podmienionych przez malware działający na poziomie jądra. To uzupełnienie FIM, bo rootkit często stara się ukryć własne pliki przed standardowym skanowaniem systemu plików. Rootcheck nie zastąpi dedykowanego narzędzia do analizy powłamaniowej, ale jako pierwsza linia ostrzegania w małej firmie, gdzie nikt nie robi forensyki na co dzień, sprawdza się dobrze i nie wymaga dodatkowej licencji.
Scenariusz z życia: fala szyfrowania i wczesne ostrzeżenie
Najbardziej przekonujący argument za FIM to atak ransomware w praktyce. Ransomware, zanim zaszyfruje dane, zwykle najpierw się rozprzestrzenia i modyfikuje setki, potem tysiące plików w krótkim czasie: dopisuje rozszerzenia, tworzy nowe pliki z żądaniem okupu w każdym katalogu, zmienia uprawnienia. Dla FIM to wygląda jak nagła, masowa zmiana w monitorowanych ścieżkach, bardzo różna od normalnego rytmu pracy firmy.
Jeśli katalog z danymi księgowymi jest objęty monitoringiem real-time, Wazuh potrafi wygenerować alert w ciągu pierwszych sekund lub minut szyfrowania, czyli zanim proces obejmie cały zasób. To wystarczająco dużo czasu, żeby administrator odciął zainfekowaną stację od sieci, zatrzymał usługę udostępniania plików albo wyłączył konto, z którego szyfrowanie jest prowadzone. Różnica między wykryciem po 3 minutach a wykryciem po 3 dniach to często różnica między „stracimy dzień na przywracanie z backupu” a „stracimy firmę”.
FIM wykrywa, nie chroni
Trzeba to powiedzieć wprost: FIM niczego nie blokuje. To system detekcji, nie prewencji. Jeśli atakujący zdąży dokończyć szyfrowanie zanim ktokolwiek zareaguje na alert, sama informacja o zmianie pliku nie odzyska danych. Dlatego FIM ma sens wyłącznie w parze z aktualnym, testowanym backupem i z podstawowym utwardzaniem dostępu do infrastruktury: ograniczonymi uprawnieniami, segmentacją sieci, dwuskładnikowym uwierzytelnianiem. FIM daje Ci czas i informację, żeby zareagować szybciej, ale to backup daje gwarancję, że w najgorszym razie odzyskasz dane.
Co dalej w cyklu
W kolejnym wpisie z serii o Wazuh zajmiemy się zbieraniem i retencją logów pod kątem wymogów NIS2, czyli tym, jak Wazuh działa jako centralny dziennik zdarzeń dla całej infrastruktury i jak zaplanować przechowywanie logów tak, żeby spełnić wymagania regulacyjne bez zalewania dysków niepotrzebnymi danymi.
W Zjawa.IT wdrażamy Wazuh z sensownie dobranym zakresem FIM pod klucz: od doboru katalogów krytycznych, przez konfigurację wykluczeń, po ustawienie priorytetów alertów tak, żeby zespół faktycznie je czytał, a nie ignorował. Napisz do nas.