Kontrola integralności odpowiada na pytanie, na które nie odpowiada ani antywirus, ani zapora: co zmieniło się na tym serwerze od zeszłego tygodnia? Skaner sygnaturowy szuka znanego szkodliwego kodu; AIDE nic nie wie o szkodliwości, wie, że ten plik wczoraj był inny. Do wykrycia furtki dopisanej do istniejącego pliku to jedyne działające podejście.

AIDE instaluje się dwoma poleceniami. Skonfigurować go tak, żeby jego raporty były czytane, to część trudniejsza — i właśnie na tym zwykle ginie: pierwszy raport przychodzi na dziesięć tysięcy wierszy, drugiego nikt nie otwiera, a miesiąc później zadanie zostaje usunięte.

Instalacja i pierwsza baza

sudo apt install aide aide-common
sudo aideinit

Inicjalizacja zajmuje od kilku minut do pół godziny: liczone są skróty wszystkich plików. Wynik trafia obok bazy roboczej z przyrostkiem .new i trzeba go wprowadzić do użytku:

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Dalej sprawdzenie uruchamia się tak:

sudo aide --check

Co wykluczyć, żeby raport dało się czytać

Ustawienia leżą w /etc/aide/aide.conf i w katalogu /etc/aide/aide.conf.d/. Domyślna konfiguracja Debiana sprawdza za dużo i pierwszą rzeczą jest usunięcie tego, co i tak zmienia się bez przerwy:

  • /var/log — zmienia się co sekundę;
  • całe /var/lib — bazy danych, stan pakietów, stan usług;
  • /var/cache, /tmp, /proc, /sys, /run;
  • katalogi przesyłanych plików i pamięci podręcznej witryny — ich zawartość zmieniają odwiedzający.

Sprawdzać z najsurowszymi ustawieniami warto natomiast wąską listę:

  • /bin, /sbin, /usr/bin, /usr/sbin — pliki wykonywalne systemu;
  • /lib, /usr/lib — biblioteki;
  • /etc — konfiguracja;
  • /root/.ssh i katalogi .ssh użytkowników;
  • kod witryny, ale bez katalogów przesyłanych plików i pamięci podręcznej.

Punkt odniesienia: zwykły raport dzienny powinien mieścić się na ekranie. Jeśli jest dłuższy, wykluczeń jest za mało i czytanie się urwie.

Gdzie trzymać bazę

Istotny szczegół, o którym często się zapomina. Jeśli obca osoba ma roota, podmiana pliku i natychmiastowa aktualizacja bazy AIDE nic ją nie kosztuje — a sprawdzenie po tym pokaże, że wszystko w porządku. Baza leżąca na tej samej maszynie z prawem zapisu chroni tylko przed przypadkiem.

Rozsądne minimum dla jednego serwera:

  • kopiować bazę po każdej aktualizacji na inną maszynę, a sprawdzenie uruchamiać, podkładając tę kopię;
  • albo przynajmniej przechowywać osobno sumę kontrolną bazy i porównywać ją przed sprawdzeniem:
sha256sum /var/lib/aide/aide.db

Nawet tak prosty zabieg zamienia cichą podmianę w zauważalne zdarzenie.

Aktualizacja bazy to działanie świadome

Po zmianach uzasadnionych — aktualizacji systemu, wgraniu nowej wersji witryny — bazę tworzy się na nowo:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Moment ma znaczenie. Poprawnie: przejrzeć raport, upewnić się, że każda zmiana daje się wyjaśnić, i dopiero potem aktualizować. Niepoprawnie i bardzo powszechnie: uruchamiać aide --update według harmonogramu, żeby raporty były czyste. W drugim przypadku system działa, raporty przychodzą, a zmiany zapisywane są jako norma dokładnie w chwili, gdy zachodzą — sens znika całkowicie.

Harmonogram i obciążenie

Pakiet aide-common sam zakłada zadanie dzienne. Sprawdzenie obciąża dysk i procesor na kilka minut, więc warto uruchamiać je o spokojnej porze i z obniżonym priorytetem:

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Jak czytać raport

Trzy sekcje: pliki dodane, usunięte i zmienione. Przy każdej zmianie widać, co dokładnie się różni: treść, prawa, właściciel, czas.

Na co reagować w pierwszej kolejności:

  • zmiana dowolnego pliku w /bin, /sbin, /usr/bin poza oknem aktualizacji;
  • nowe pliki w katalogach systemowych;
  • zmiany w authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab i /etc/cron.d;
  • pojawienie się pliku /etc/ld.so.preload — sam z siebie nie powstaje nigdy.

Sto zmienionych plików zaraz po apt upgrade to norma i czas raportu to potwierdza. Trzy zmienione pliki w /usr/bin w środę, gdy aktualizacji nie było, to powód, żeby się zatrzymać i sprawdzić.

AIDE i debsums

Narzędzia rozwiązują pokrewne zadania, ale ich wzorzec jest różny. AIDE porównuje z własną migawką — widzi więc zmiany w dowolnych plikach, łącznie z kodem witryny. debsums porównuje z sumami kontrolnymi z pakietów dystrybucji — widzi więc podmianę plików systemowych bez żadnego przygotowania, ale nic nie wie o tym, co zainstalowano poza pakietami. Rozsądnie jest mieć oba; w praktyce debsums zwykle idzie pierwszy, bo nie wymaga ani konfiguracji, ani bazy.

Wspólna jest też ich słabość: raport przychodzi pocztą, a poczta ginie. Liczy się więc nie sam fakt uruchomienia sprawdzenia, lecz miejsce, w którym widać jego ostatni wynik. Jak to wygląda, pokazuje strona demonstracyjna poniżej.