monitorowanie integralności plików

Monitorowanie integralności plików (ang. file integrity monitoring, FIM) to porównywanie bieżącego stanu plików z zapisanym wzorcem w celu wykrycia plików zmienionych, dodanych albo usuniętych. Integralność w terminologii NIST oznacza ochronę przed niewłaściwą modyfikacją lub zniszczeniem informacji, łącznie z zapewnieniem jej autentyczności ^[1]. Na stronie internetowej wzorcem są zwykle sumy kontrolne oficjalnego wydania oprogramowania albo stan zapisany tuż po czystej instalacji. Monitorowanie nie zapobiega włamaniu. Pozwala je zauważyć i ustalić, co napastnik zostawił na serwerze.

Jak działa

Mechanizm ma dwie fazy. Najpierw powstaje linia bazowa: dla każdego pliku zapisuje się wynik funkcji skrótu (hashowania) oraz atrybuty, takie jak rozmiar, właściciel i uprawnienia. Dokumentacja Wazuh opisuje to jako skan bazowy, który przechowuje sumę kryptograficzną i inne atrybuty monitorowanych plików ^[7]. Przy kolejnym sprawdzeniu moduł porównuje sumę i atrybuty z linią bazową i zgłasza alert, gdy wykryje niezgodność ^[7]. Sekurak, opisując hostowe systemy wykrywania włamań, zwraca uwagę, że sprawdzają one nie tylko widoczne dane, ale również wartości skrótu plików ^[8]. Dzięki temu zmiana jednego bajtu w pliku PHP zmienia skrót i zostaje wykryta, nawet jeśli data modyfikacji pozostała ta sama.

Przebieg pracy narzędzia pokazuje schemat poniżej.

RYS. 1Monitorowanie integralności plików

Monitorowanie integralności jest jedną z funkcji hostowego systemu wykrywania włamań, czyli IDS działającego na samym serwerze. Sekurak wymienia jako klasyczne narzędzia tego typu Tripwire, AIDE i Afick ^[8].

Odmiany

Narzędzia różnią się tym, skąd biorą wzorzec i jak często sprawdzają pliki. Wazuh obsługuje zarówno skany według harmonogramu, jak i monitorowanie w czasie rzeczywistym ^[7].

Porównanie z wydaniem producenta nie wymaga własnej linii bazowej, ale obejmuje tylko pliki, które producent publikuje. Własna linia bazowa obejmuje wszystko, także kod pisany na zamówienie, lecz jest tak wiarygodna, jak stan serwera w chwili jej utworzenia.

W WordPressie

WP-CLI udostępnia polecenie wp core verify-checksums. Według dokumentacji pobiera ono sumy MD5 dla bieżącej wersji z WordPress.org i porównuje je z zainstalowanymi plikami ^[2]. Gdy plik się różni, polecenie wypisuje ostrzeżenie „File doesn't verify against checksum” i kończy się błędem ^[2]. Kod źródłowy polecenia pokazuje, że katalog wp-content jest pomijany, a pliki spoza wydania, których w nim nie ma, są zgłaszane komunikatem „File should not exist”; wyjątkami są między innymi .htaccess i wp-config.php ^[4].

Wtyczki sprawdza wp plugin verify-checksums. Z opcją --all weryfikuje wszystkie zainstalowane wtyczki, a z --strict zgłasza także drobne zmiany, na przykład w pliku readme.txt ^[3]. Polecenie działa tylko dla wtyczek dostępnych w oficjalnym repozytorium WordPress.org ^[3].

wp core verify-checksums
wp plugin verify-checksums --all

Poza zasięgiem tych poleceń zostają więc motywy, wtyczki komercyjne, mu-plugins, katalog przesłanych plików i sam wp-config.php. Dla nich potrzebna jest własna linia bazowa. Szczególną uwagę warto zwrócić na katalog uploads. CERT Polska wskazuje, że podejrzane są pliki PHP zawierające funkcje takie jak system(), exec() czy shell_exec(), zwłaszcza w katalogach /images lub /uploads ^[6]. Tak zwykle wygląda webshell albo tylna furtka (backdoor).

Zmiany w plikach może też wprowadzać sam panel. Stała DISALLOW_FILE_EDIT w wp-config.php działa jak odebranie wszystkim użytkownikom uprawnień edit_themes, edit_plugins i edit_files ^[5], czyli wyłącza edytor plików motywów i wtyczek. Każda zmiana kodu przechodzi wtedy przez wdrożenie albo aktualizację rdzenia, co ułatwia odróżnienie zmian planowanych od podejrzanych.

Znaczenie

Podręcznik utwardzania WordPressa zauważa, że atak zawsze zostawia ślady: w logach albo w systemie plików, w postaci nowych lub zmienionych plików ^[5]. Monitorowanie integralności wychwytuje tę drugą grupę śladów. Wśród wymienianych w podręczniku celów są: wykrycie zmienionych i dodanych plików, zapis zmian, możliwość cofnięcia pojedynczych modyfikacji i automatyczne powiadomienia ^[5]. Wykryty plik jest wskaźnikiem kompromitacji (IoC), który można potem szukać na innych serwerach.

Dokumentacja Wazuh wskazuje też stronę formalną: monitorowanie krytycznych plików to według niej istotny wymóg takich regulacji jak PCI DSS, HIPAA i RODO ^[7].

Dobre praktyki

• Linię bazową tworzyć po czystej instalacji i odnawiać po każdej planowanej aktualizacji. Wzorzec zrobiony na zainfekowanym serwerze utrwala infekcję.
• Uruchamiać narzędzie z uprawnieniami administratora systemu, aby napastnik nie mógł go wyłączyć, i stosować ścisłe uprawnienia plików ^[5].
• Ograniczać szum: podręcznik WordPressa radzi monitorować tylko pliki wykonywalne i wstrzymywać monitorowanie na czas prac serwisowych ^[5]. Nadmiar zgłoszeń prowadzi do zmęczenia alertami (alert fatigue), a każdy fałszywy alarm (false positive) osłabia zaufanie do narzędzia.
• Łączyć monitorowanie z logami serwera i skanerem złośliwego oprogramowania (malware scanner): skaner szuka znanych wzorców, monitorowanie wskazuje każdą zmianę.
• Przechowywać kopię zapasową (backup) plików i bazy poza serwerem hostującym stronę, tak aby atakujący nie miał do niej dostępu ^[6].

Po wykryciu zmiany

Wykrycie nieoczekiwanej zmiany rozpoczyna reagowanie na incydent. CERT Polska zaleca, aby po ustaleniu ram czasowych incydentu na podstawie logów zidentyfikować pliki nowo utworzone lub zmodyfikowane w tym okresie ^[6]. Zastrzega przy tym, że atakujący mogą sfałszować daty modyfikacji, więc sprawdzenie znaczników czasu nie zwalnia z analizy pozostałych plików ^[6]. Właśnie tu przewagę mają skróty: porównanie treści nie zależy od dat. Według CERT Polska weryfikację zmian ułatwia porównanie plików z oficjalnym repozytorium systemu CMS ^[6]. Dalsze kroki to izolacja serwera, zabezpieczenie logów, analiza artefaktów i odbudowa z czystej kopii albo od podstaw ^[6]; opisuje je hasło czyszczenie przejętej strony.