O intruziune arată rareori ca în filme. Nimeni nu scrie nimic în terminal și nu apar cranii pe ecran. Cazul obișnuit e mai plictisitor: serverul încetinește, furnizorul de găzduire trimite o scrisoare despre spam ieșit din server, sau site-ul începe să trimită vizitatorii către o adresă străină.

Mai jos sunt șapte verificări în ordinea în care are sens să fie făcute. Împreună durează în jur de zece minute.

1. Ce consumă procesorul

top -c
ps aux --sort=-%cpu | head -20

Se caută un proces cu nume fără sens care ține procesorul la aproape sută la sută. Minarea de criptomonede este cea mai frecventă consecință a unei intruziuni, pur și simplu pentru că este cel mai rapid mod de a face bani pe serverul altcuiva.

Două lucruri merită o privire mai atentă. Procesele care rulează din /tmp, /dev/shm sau /var/tmp — de acolo nu pornește nimic în mod normal. Și numele care seamănă cu procese de sistem fără să se potrivească întru totul: kswapd0 cu încărcare mare a procesorului rulat din directorul greșit, sau crond cu C mare.

sudo ls -l /proc/<pid>/exe
sudo ls -l /proc/<pid>/cwd

Prima comandă arată calea reală către fișierul executabil, a doua directorul în care lucrează procesul. De obicei este suficient pentru a înțelege despre ce e vorba.

2. Conexiuni ieșite

sudo ss -tupn
sudo ss -tupn state established

Un server web obișnuit se conectează rar spre exterior: la oglinzile managerului de pachete, la procesatorul de plăți, la serviciul de trimitere a e-mailurilor. Conexiunile stabile către adrese necunoscute pe porturi înalte sunt fie un bazin de minare, fie contactul cu un server de comandă.

Ține minte că această verificare este slabă de una singură: codul rău intenționat se conectează adesea doar după un program. Faptul că acum nu vezi nimic nu înseamnă că nu există nimic.

3. Sarcinile cron ale tuturor utilizatorilor

Aici se ancorează pentru ca ceea ce ai curățat să revină.

for u in $(cut -f1 -d: /etc/passwd); do echo "== $u"; sudo crontab -u "$u" -l 2>/dev/null; done
sudo ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
sudo cat /etc/crontab

Ce trebuie să trezească suspiciuni: liniile cu @reboot, comenzile lungi codificate, apelurile curl sau wget trimise către un shell, tot ce pornește din directoare temporare.

4. Chei SSH și utilizatori

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;
sudo awk -F: '$3 == 0 {print $1}' /etc/passwd
sudo lastlog | head -20

Fiecare linie din authorized_keys este accesul permanent al cuiva, care supraviețuiește și schimbării parolei, și repornirii. Dacă nu poți spune a cui e cheia, consider-o străină — comentariul de la sfârșitul liniei este text liber și nu dovedește nimic.

A doua comandă listează toate conturile cu uid 0. Acolo trebuie să fie doar root.

5. Jurnalele de autentificare

sudo grep 'Accepted' /var/log/auth.log | tail -30
sudo last -20
who

Importante sunt autentificările reușite, nu cele eșuate. Încercările eșuate sunt zgomot de fond pe care îl are orice server din internet. O autentificare reușită de la o adresă necunoscută într-un moment în care nu lucra nimeni este un răspuns concret.

Pe Debian 12 și Ubuntu 24.04 fișierul /var/log/auth.log adesea nu există deloc — rsyslog nu mai este instalat implicit. Citește în schimb jurnalul:

sudo journalctl -u ssh --since '7 days ago' | grep Accepted

6. Fișiere de sistem modificate

Pe Debian și Ubuntu există un etalon gata făcut: fiecare pachet poartă cu sine sumele de control ale fișierelor sale.

sudo apt install debsums
sudo debsums -c

Fișierele de configurare modificate din /etc sunt normale — pe acelea le-ai schimbat tu. Fișierele executabile modificate din /usr/bin, /bin sau /usr/sbin sunt exact ceea ce căutai.

7. Fișiere neobișnuite în rădăcina site-ului

sudo find /var/www -name '*.php' -mtime -7 -ls
sudo find /var/www/uploads -name '*.php'

A doua comandă este mai importantă decât prima. Un fișier PHP nu are niciun motiv legitim să fie în directorul fișierelor încărcate, iar acesta este cel mai frecvent loc pentru un webshell.

Dacă chiar se găsește ceva

Primul impuls este să ștergi imediat descoperirea. Este o greșeală: odată cu fișierul dispare informația despre cum a ajuns acolo, iar fără răspuns la această întrebare totul se repetă în câteva zile.

  1. Păstrează o copie a fișierului și ora modificării lui.
  2. Caută în jurnalele serverului web ce s-a întâmplat în același moment — de obicei acolo este intrarea.
  3. Parcurge toate cele șapte puncte, nu doar cel în care ai găsit ceva. Ușile din spate nu se lasă aproape niciodată într-un singur exemplar.
  4. Abia apoi curăță și închide vulnerabilitatea propriu-zisă.

Și o delimitare onestă: dacă atacatorul a obținut root, nicio verificare făcută din interior nu poate fi crezută pe deplin — instrumentele însele pot fi înlocuite. La o intruziune profundă singura cale sigură este un server nou și o restaurare verificată din copia de rezervă.

Ce face verificarea dificilă

Principala dificultate aici nu sunt comenzile, ci faptul că o linie necunoscută nu pare suspectă când nu îți amintești cum arăta lista săptămâna trecută. Pe un server configurat de altcineva este aproape imposibil să distingi ce e al tău de ce e străin.

De aici concluzia practică: fă un instantaneu al stării cât timp serverul este în regulă. Lista proceselor, porturilor, sarcinilor cron și cheilor de pe o mașină sănătoasă este etalonul cu care vei compara ulterior — și atunci orele de căutare se transformă în compararea a două liste. Cum arată totul adunat pe o singură pagină arată demonstrația de mai jos.