Rkhunter tocmai a semnalat jumătate dintre binarele tale după un update: cum separi false positive-urile de situațiile în care chiar ai fost compromis

Dacă rkhunter începe brusc să urle după un update de pachete, o schimbare de kernel, un upgrade de distribuție sau o actualizare de panou de control, primul lucru pe care trebuie să îl înțelegi este acesta: un zid de avertismente nu înseamnă automat că serverul a fost compromis. De obicei înseamnă unul dintre două lucruri. Fie rkhunter compară sistemul actual cu o bază de referință depășită, fie update-ul a modificat suficient de multe fișiere deținute de pachete încât vechea bază de proprietăți nu mai corespunde cu realitatea. Acesta este un scenariu normal după actualizări. Partea periculoasă este că avertismentele reale de compromitere pot fi îngropate în același output, ceea ce explică de ce unii administratori intră în panică din cauza unui zgomot inofensiv, iar alții ignoră ceva grav pentru că „rkhunter plânge mereu degeaba”.

Ținta corectă nu este să faci rkhunter să tacă. Ținta este să îl faci din nou credibil. Asta înseamnă să citești logurile corecte, să validezi ce s-a schimbat cu ajutorul managerului de pachete, să actualizezi baza de proprietăți numai după ce ai decis că starea sistemului este de încredere, să whitelistezi atent excepțiile legitime și să recunoști ce avertismente cer răspuns imediat de tip incident, nu doar tuning de rutină.

Acest articol este pentru situația exactă din spatele căutării rkhunter false positive after update. Ai rulat o scanare, o mulțime de binare apar brusc ca modificate și trebuie să decizi dacă este zgomot obișnuit după update sau începutul unei zile mult mai proaste. Până la final, ar trebui să știi cum se citește corect output-ul rkhunter, când --propupd este mișcarea corectă, cum se face whitelist fără să îți sabotezi singur vizibilitatea și în ce moment interpretarea corectă nu mai este „false positive”, ci „oprește-te și tratează serverul ca potențial compromis”.

Ce compară, de fapt, rkhunter după un update

rkhunter nu este magie. Nu are nicio memorie proprie despre cum „ar trebui” să arate serverul tău dacă tu nu i-ai oferit una. Verificarea care generează cel mai des panică după update este testul de proprietăți al fișierelor. rkhunter stochează proprietăți așteptate pentru fișierele de sistem și, la scanările ulterioare, compară starea curentă cu acel etalon. Dacă un update legitim a schimbat binare, biblioteci, scripturi sau atribute de fișiere, iar tu nu ai actualizat baza după aceea, următoarea scanare îți va spune că acele fișiere s-au modificat. Asta poate fi adevărat fără să însemne compromis.

De aceea, rezultatele unei prime scanări sau ale primei scanări după un upgrade par adesea mult mai grave decât sunt în realitate. rkhunter este foarte bun la a spune „ceva este diferit”. Devine mult mai puțin util dacă nu l-ai calibrat niciodată pe o stare de încredere sau dacă l-ai calibrat o dată și apoi ai uitat că sistemul a continuat să evolueze.

Greșeala practică este să sari direct de la „este diferit” la „sunt compromis”. Greșeala la fel de proastă este să sari de la „probabil are legătură cu update-ul” la „ignor tot”. Treaba ta este să clasifici avertismentele, nu să le dramatizezi și nici să le respingi din reflex.

Triage-ul din primele cinci minute: fă asta înainte să atingi baza de referință

Nu rula --propupd imediat. Așa ajung oamenii să valideze fără să vrea o stare compromisă. Mai întâi uită-te exact la ce a raportat rkhunter și când.

rkhunter --check --sk
grep -n "Warning:" /var/log/rkhunter.log
tail -n 200 /var/log/rkhunter.log

Ceea ce cauți aici nu este doar numărul avertismentelor, ci tiparul lor.

• Dacă multe avertismente au apărut imediat după un update de pachete cunoscut, un update de kernel, un upgrade de distribuție sau o actualizare de panou de control, false positive-urile sunt probabile.
• Dacă avertismentele au apărut pe un server pe care nu a existat nicio fereastră de schimbare autorizată, tratează-le mai serios.
• Dacă avertismentele se concentrează pe binare deținute de pachete care tocmai au fost actualizate, de obicei este vorba despre un etalon depășit.
• Dacă avertismentele ating fișiere de startup neașteptate, căi ascunse, directoare web locale, procese suspecte sau servicii care ascultă pe porturi pe care nu le poți explica, problema este alta.

Notează și cronologia schimbărilor din sistem înainte să începi să „repari” ceva:

uname -a
uptime
last -x | head
journalctl --since "3 days ago" | tail -n 200

Pe Debian și Ubuntu, verifică și istoricul managerului de pachete:

grep -E "upgrade|install " /var/log/apt/history.log
zgrep -E "upgrade|install " /var/log/apt/history.log.*.gz 2>/dev/null | tail -n 100

Pe distribuții bazate pe RPM:

dnf history
rpm -qa --last | head -n 50

Dacă timestamp-urile se aliniază cu avertismentele, ai deja o ipoteză de lucru rezonabilă: rkhunter reacționează la schimbări de încredere. Asta nu înseamnă că ai terminat. Înseamnă doar că nu pornești complet orb.

Citește fișierul corect în loc să te uiți fix la rezumat

Rezumatul din terminal este prea comprimat ca să iei decizii bune doar din el. Sursa reală este fișierul de log.

less /var/log/rkhunter.log
grep -nE "Warning:|Info:" /var/log/rkhunter.log

Avertismentele rkhunter după update intră, de obicei, în câteva categorii practice:

• schimbări de proprietăți pe binare deținute de pachete
• avertismente despre scripturi pe fișiere care sunt în mod legitim scripturi pe distribuția ta
• fișiere sau directoare ascunse create de software legitim
• modificări în fișiere de startup după actualizarea unor servicii
• procese sau porturi deschise care sunt reale, dar așteptate pe acel host

Ce contează nu este simplul fapt că există un avertisment. Ce contează este dacă îl poți explica printr-o schimbare legitimă. Dacă poți, probabil este rutină. Dacă nu poți, nu este rutină până când nu demonstrezi contrariul.

Validează binarele modificate cu managerul de pachete înainte să ai încredere în orice

Aici dau greș multe tutoriale scurte, iar aici se face diferența dintre gestionare reală de incident și superstiție. Dacă rkhunter spune că un binar s-a schimbat, următoarea ta întrebare nu este „ar trebui să rulez propupd?”. Următoarea întrebare este „managerul de pachete confirmă că acest fișier aparține unui pachet legitim și că starea lui corespunde cu ce se așteaptă sistemul de pachete?”.

Pe Debian și Ubuntu, începe cu apartenența fișierului la pachet:

dpkg -S /usr/bin/awk
dpkg -S /bin/egrep
dpkg -S /usr/bin/file

Apoi verifică efectiv conținutul pachetului. Dacă folosești deja debsums, acesta este unul dintre cele mai curate drumuri pentru fișierele gestionate de pachete:

apt install -y debsums
debsums -s coreutils grep util-linux

Poți folosi și:

dpkg -V

Pe RHEL, Rocky, AlmaLinux, Fedora și sisteme similare, verificarea RPM este de obicei cea mai rapidă sursă de adevăr:

rpm -qf /usr/bin/awk
rpm -qf /usr/bin/file
rpm -V $(rpm -qf /usr/bin/file)
rpm -Va

Nu rula rpm -Va pe un server de producție aglomerat și apoi nu intra în panică la fiecare linie. Folosește-l cu un scop clar. Un update legitim poate produce diferențe așteptate, mai ales la fișiere de configurare și la anumite metadate. Întrebarea pe care vrei să o clarifici este mai îngustă: managerul de pachete vede acest binar ca aparținând unui pachet legitim instalat, iar schimbarea se potrivește cu o fereastră de mentenanță autorizată?

Dacă rkhunter raportează zeci de binare schimbate, dar managerul de pachete confirmă că modificările sunt cele așteptate după update, atunci este foarte probabil că ai de-a face cu o bază de referință depășită, nu cu un compromis. Dacă rkhunter semnalează fișiere pe care managerul de pachete nu le recunoaște ca legitime, situația devine mult mai serioasă.

Când rkhunter --propupd este corect și când este o imprudență

--propupd nu este o comandă de curățare. Nu este un buton de tipul „confirm și fac să dispară”. El actualizează etalonul intern al proprietăților fișierelor. Asta este corect doar după ce ai decis că schimbările sunt legitime.

Folosești --propupd atunci când toate condițiile de mai jos sunt adevărate:

• avertismentele au apărut după un update sau o reconfigurare cunoscută și de încredere
• fișierele schimbate aparțin unor pachete legitime sau unor modificări locale așteptate
• nu vezi anomalii neexplicate legate de startup, procese, directoare ascunse sau servicii care ascultă
• celelalte loguri ale serverului nu indică semne de intruziune

Abia atunci actualizezi etalonul:

rkhunter --propupd

Și rulezi din nou verificarea:

rkhunter --check --sk

Dacă numărul de avertismente se prăbușește după aceea și ceea ce rămâne poate fi explicat ca excepții legitime, tocmai ai demonstrat că problema era, în principal, o bază de referință depășită.

Nu rula --propupd cât timp încă te întrebi dacă serverul este compromis. Asta înseamnă, practic, că validezi o stare pe care nu o înțelegi încă.

Cum faci whitelist corect, fără să transformi rkhunter într-un teatru

Unele avertismente sunt legitime și recurente pe sisteme moderne. Dacă le-ai validat, whitelistează-le chirurgical. Nu modifica aiurea fișierul principal de configurare dacă pachetul îți oferă un mecanism local de override. Ține excepțiile tale într-o zonă separată, ca să rămână ușor de urmărit și după update-uri viitoare.

În funcție de modul în care distribuția ți-a împachetat rkhunter, asta înseamnă de obicei una dintre variantele:

• /etc/rkhunter.conf.local
• un fișier drop-in sub /etc/rkhunter.d/, de exemplu /etc/rkhunter.d/local.conf

Exemple tipice:

SCRIPTWHITELIST=/bin/egrep
ATTRWHITELIST=/usr/bin/date
WRITEWHITELIST=/usr/bin/date
ALLOWHIDDENDIR=/etc/.java
ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz

Folosește cea mai îngustă excepție care rezolvă problema concretă. Dacă un fișier este un script legitim și rkhunter se plânge din motivul ăsta, folosește SCRIPTWHITELIST. Dacă o cale ascunsă este legitimă, folosește ALLOWHIDDENDIR. Nu începe să arunci wildcarduri largi peste tot doar pentru că te-ai săturat de text roșu în terminal.

Whitelist-ul este corect atunci când condiția este:

• cunoscută
• stabilă
• înțeleasă
• specifică

Whitelist-ul este greșit atunci când condiția este:

• nouă
• slab înțeleasă
• prea largă
• în afara comportamentului normal al sistemului tău

Avertismentele care sunt de obicei de rutină după update-uri

Acestea sunt tipurile de rezultate care sunt adesea benigne după o mentenanță autorizată, cu condiția să se alinieze cu modificările de pachete și cu restul contextului din sistem:

• schimbări multiple de proprietăți pe binare deținute de pachete imediat după un update mare
• avertismente despre scripturi pe unelte livrate de distribuție care sunt, în mod legitim, scripturi
• avertismente că versiunea sistemului de operare s-a schimbat după un upgrade de distribuție
• directoare sau fișiere ascunse cunoscute, create de software legitim
• modificări ale fișierelor de startup care corespund unor servicii proaspăt actualizate sau recent activate

Și acestea trebuie totuși validate. Devine „de rutină” doar după ce îl poți explica. „De rutină fiindcă sunt obosit” nu este o categorie tehnică.

Avertismentele care ar trebui să te facă să încetezi să le mai numești false positive

Aici mulți devin leneși și apoi regretă. Unele constatări nu sunt „probabil zgomot după update” decât dacă le poți explica cu dovezi concrete.

• binare modificate fără o explicație validă din partea managerului de pachete
• fișiere din căi de startup pe care nu le recunoști
• directoare ascunse apărute în locații neobișnuite
• servicii noi care ascultă pe porturi și pe care nu le poți justifica
• procese care șterg fișiere sau ascultă pe interfețe neașteptate
• servere expuse public unde binare suspecte, căi de upload sau cron jobs s-au schimbat în afara unei ferestre de mentenanță

Dacă rkhunter spune că un binar s-a schimbat, managerul de pachete nu confirmă schimbarea ca fiind legitimă, iar logurile tale nu arată nicio fereastră de update autorizată, încetează să mai vorbești despre false positive și tratează sistemul ca potențial compromis.

Asta înseamnă colectare de dovezi, păstrarea logurilor, verificarea istoriei de autentificare, revizuirea cron-urilor, controlul fișierelor de startup și examinarea listenerelor de rețea. Pe un server care chiar contează, exact aici Administrarea Linux încetează să mai fie o comoditate și devine control real al riscului.

Un flux practic post-update care chiar funcționează

1. Rulează rkhunter --check --sk și citește /var/log/rkhunter.log.
2. Verifică dacă avertismentele se aliniază cu o fereastră cunoscută de update sau reconfigurare.
3. Validează fișierele modificate cu managerul de pachete.
4. Inspectează separat orice avertisment care nu este clar legat de pachete.
5. Abia după validare, rulează rkhunter --propupd.
6. Adaugă whitelist local și îngust doar pentru zgomotul legitim care reapare.
7. Rulează din nou scanarea și confirmă că setul de avertismente este acum mai mic și mai relevant.

Așa păstrezi rkhunter util. Nu încercând să ajungi la zero avertismente cu orice preț și nici pretinzând că fiecare avertisment este o compromitere. Ai nevoie de un semnal calibrat, nu de unul teatral.

Cum eviți alert fatigue pe Debian și Ubuntu după update-uri de pachete

Pe sistemele din familia Debian, integrarea cu update-urile de pachete contează, pentru că reduce distanța dintre mentenanța legitimă și modul în care rkhunter vede host-ul. Debian încă documentează APT_AUTOGEN="true" în /etc/default/rkhunter exact din motivul acesta. Nu înlocuiește judecata tehnică, dar reduce numărul de situații în care uiți să actualizezi starea după un update normal.

Verifică setarea:

grep '^APT_AUTOGEN' /etc/default/rkhunter

Dacă nu este activată și mediul tău folosește mentenanță obișnuită bazată pe apt, activarea ei poate reduce zgomotul după update-uri normale de pachete. Totuși, nu transforma automatizarea într-un substitut pentru înțelegerea schimbărilor de pe host. Este un strat de comoditate, nu o strategie de răspuns la incident.

Când scannerul nu mai este, de fapt, problema principală

Dacă avertismentele rkhunter sunt greu de clasificat pentru că host-ul însuși este dezordonat, atunci problema reală nu mai este „cum tunez rkhunter?”. Problema este că nu ai suficientă încredere în mediul de operare încât să poți interpreta rezultatele cu siguranță.

Asta se întâmplă frecvent pe:

• instanțe VPS vechi, cu schimbări nedocumentate
• servere cu panouri de control și ani întregi de churn în pachete
• servere administrate de mai multe persoane, fără disciplină reală de change management
• distribuții care au fost upgrade-uite in-place peste mai multe versiuni majore, fără recalibrare curată a etaloanelor

În astfel de situații, răspunsul corect este adesea să încetezi să tratezi scannerul ca problemă și să începi să tratezi serverul ca problemă. Dacă host-ul contează, mută-l către un model operațional mai curat. Pentru un punct de plecare mai sănătos al workload-urilor critice, Serverele Virtuale ServerSpan îți oferă un început mai curat decât ani întregi de drift nedocumentat. Iar dacă host-ul este deja suficient de important încât o interpretare greșită a unei posibile compromiteri te poate costa bani sau încredere, adu ajutor hands-on de Administrare Linux în loc să ghicești.

Concluzia practică

Un raport masiv rkhunter după un update înseamnă de obicei unul dintre două lucruri: o bază de referință depășită sau o problemă reală ascunsă într-o mare de zgomot legitim. Treaba ta este să separi cele două fără să distrugi dovezile. Citește logul. Verifică fișierele modificate cu managerul de pachete. Folosește --propupd numai după ce ai încredere în setul de schimbări. Whitelistează îngust excepțiile legitime. Și dacă avertismentele nu se aliniază cu o mentenanță autorizată, încetează să le mai numești false positive doar pentru că sunt incomode.

Așa păstrezi rkhunter util. Nu tăcut. Util.