Controlul integrității răspunde la o întrebare la care nu răspunde nici antivirusul, nici firewallul: ce s-a schimbat pe acest server de săptămâna trecută? Un scaner bazat pe semnături caută cod rău intenționat cunoscut; AIDE nu știe nimic despre răutate, știe că acest fișier era altfel ieri. Pentru descoperirea unei uși din spate adăugate într-un fișier existent, aceasta este singura abordare care funcționează.

AIDE se instalează din două comenzi. Configurarea lui astfel încât rapoartele să fie citite este partea grea — și tocmai aici eșuează de obicei: primul raport are zece mii de linii, pe al doilea nu îl deschide nimeni, iar peste o lună sarcina este ștearsă.

Instalarea și prima bază

sudo apt install aide aide-common
sudo aideinit

Inițializarea durează de la câteva minute la o jumătate de oră: se calculează sumele de control ale tuturor fișierelor. Rezultatul ajunge lângă baza de lucru cu extensia .new și trebuie pus în funcțiune:

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

Mai departe, verificarea se rulează astfel:

sudo aide --check

Ce să excluzi ca raportul să poată fi citit

Setările se află în /etc/aide/aide.conf și în directorul /etc/aide/aide.conf.d/. Configurația implicită Debian verifică prea multe, iar primul lucru este să scoți ceea ce oricum se schimbă permanent:

  • /var/log — se schimbă în fiecare secundă;
  • tot /var/lib — baze de date, starea pachetelor, starea serviciilor;
  • /var/cache, /tmp, /proc, /sys, /run;
  • directoarele de încărcări și de cache ale site-ului — conținutul lor îl schimbă vizitatorii.

În schimb, cu setările cele mai stricte merită verificată o listă îngustă:

  • /bin, /sbin, /usr/bin, /usr/sbin — fișierele executabile ale sistemului;
  • /lib, /usr/lib — bibliotecile;
  • /etc — configurația;
  • /root/.ssh și directoarele .ssh ale utilizatorilor;
  • codul site-ului, dar fără directoarele de încărcări și de cache.

Reper: un raport zilnic obișnuit trebuie să încapă pe un ecran. Dacă este mai lung, excluderile sunt prea puține, iar citirea se va opri.

Unde se ține baza

Un detaliu esențial care se uită adesea. Dacă un străin are root, înlocuirea unui fișier și actualizarea imediată a bazei AIDE nu îl costă nimic — iar verificarea de după va arăta că totul este în regulă. O bază aflată pe aceeași mașină cu drept de scriere protejează doar împotriva accidentului.

Minimul rezonabil pentru un singur server:

  • copiază baza după fiecare actualizare pe altă mașină, iar verificarea rulează-o cu acea copie;
  • sau, cel puțin, păstrează separat suma de control a bazei și compar-o înainte de verificare:
sha256sum /var/lib/aide/aide.db

Chiar și un procedeu atât de simplu transformă o înlocuire tăcută într-un eveniment vizibil.

Actualizarea bazei este un act conștient

După modificări justificate — o actualizare de sistem, punerea în producție a unei versiuni noi a site-ului — baza se recreează:

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

Momentul contează. Corect: parcurge raportul, asigură-te că fiecare modificare poate fi explicată și abia apoi actualizează. Incorect și foarte răspândit: să rulezi aide --update după program, ca rapoartele să fie curate. În al doilea caz sistemul funcționează, rapoartele sosesc, iar modificările sunt înregistrate ca normă exact în momentul în care se produc — sensul dispare complet.

Programul și încărcarea

Pachetul aide-common creează singur o sarcină zilnică. Verificarea încarcă discul și procesorul pentru câteva minute, așa că merită rulată la o oră liniștită și cu prioritate redusă:

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

Cum se citește raportul

Trei secțiuni: fișiere adăugate, șterse și modificate. La fiecare modificare se vede exact ce diferă: conținutul, drepturile, proprietarul, ora.

La ce reacționezi în primul rând:

  • modificarea oricărui fișier din /bin, /sbin, /usr/bin în afara ferestrei de actualizare;
  • fișiere noi în directoarele de sistem;
  • modificări în authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab și /etc/cron.d;
  • apariția fișierului /etc/ld.so.preload — de la sine nu apare niciodată.

O sută de fișiere modificate imediat după apt upgrade este normal, iar ora raportului o confirmă. Trei fișiere modificate în /usr/bin într-o miercuri fără actualizări sunt motiv să te oprești și să verifici.

AIDE și debsums

Instrumentele rezolvă sarcini înrudite, dar cu modele diferite. AIDE compară cu propriul instantaneu — vede deci modificări în orice fișiere, inclusiv în codul site-ului. debsums compară cu sumele de control din pachetele distribuției — vede deci înlocuirea fișierelor de sistem fără nicio pregătire, dar nu știe nimic despre ce a fost instalat în afara pachetelor. Este rezonabil să le ai pe amândouă; în practică, debsums vine de obicei primul, pentru că nu cere nici configurație, nici bază.

Comună le este și slăbiciunea: raportul vine prin poștă, iar poșta se pierde. Contează deci nu faptul că verificarea a rulat, ci existența unui loc în care se vede ultimul ei rezultat. Cum arată asta arată pagina demonstrativă de mai jos.