Od dość dawna używam prostego skryptu, który identyfikuje:
- nowe pliki;
- usunięte pliki;
- zmodyfikowane pliki.
Głównie chodzi mi o wykrycie sytuacji, w której pliki na moim serwerze zmieniają się w sposób "nieoczekiwany" (malware, włamanie, dostęp z konta innych użytkowników hostingu). Samo porównanie wykonywane jest w sqlite.
Skrypt napisałem, sprawdziłem, że działa i potem po prostu używałem. Raz na jakiś czas wpadał mi jednak do głowy pomysł, by zrobić jego optymalizację. Nie jakąś dużą, po prostu zrobić indeksy na tabelach. I tak przez długi czas pomysł pozostawał w koszyku "może kiedyś", aż w końcu...
Przed:
_find_new_files: 24.0540001392 _find_deleted_files: 21.9730000496 _find_modified_files: 31.5250000954
Po:
_find_new_files: 0.0569999217987 _find_deleted_files: 0.050999879837 _find_modified_files: 0.0410001277924
Ups :)
Co ile odpalasz taki skrypt?
Istnieją fajne systemy plików (ZFS) w których możesz zrobić snapshot całego fs i zrobić diffa pomiędzy dwoma snapshotami. ZFS wypiszę Ci konkretnie który pliki zostały zmodyfikowane.
Podejście jest bardzo proste - po stronie serwera jest skrypt, który liczy sha256 dla każdego pliku w drzewie katalogów. Skrypt ten jest wywoływany przez klienta uruchamianego u mnie na stacji (ręcznie, jak mi się chce). Klient parsuje otrzymany plik (XML) i ładuje do bazy (sqlite). W bazie danych idą trzy proste zapytania:
1. Do znalezienia plików nowych (nie było, a są);
2. Do znalezienia plików usuniętych (były a nie ma);
3. Do znalezienia plików zmodyfikowanych (były, ale obecny hash jest inny niż poprzedni).
Te zapytania były robione przez JOIN po nazwie i dlatego założenie indeksów spowodowało taką dużą różnicę w czasie wykonania.
Tak, całość jest dość prosta do oszukania, ale celem tego ćwiczenia nie jest wykrycie jakiegoś APT, który próbuje się ukryć