Primul reflex după ce descoperi un proces necunoscut e să oprești serverul și să „cureți”. Amândouă sunt greșite: oprirea șterge dovezile din memorie, iar curățarea lasă aproape mereu o ușă în urmă. Un incident se tratează în ordine, nu în grabă.
Semnele tipice: un proces cu nume banal care ocupă CPU-ul, conexiuni ieșite către adrese necunoscute, o intrare nouă în crontab sau în authorized_keys, fișiere de sistem modificate recent, un utilizator pe care nu l-ai creat, loguri lipsă. Nu oprești serverul, pentru că memoria conține procesele, conexiunile și, uneori, cheile atacatorului. Izolezi: refuz implicit pe intrare și pe ieșire, cu excepția adresei de la care investighezi.
Faci o copie a discului și îi calculezi suma de control; salvezi ieșirile din ps, ss, last și copiile logurilor. Abia apoi rotești toate secretele, nu doar cel pe care crezi că l-a folosit atacatorul: parole de baze de date, chei API, token-uri de CI, certificate. Aplicația o repui pe un server nou, instalat de la zero, dintr-un backup făcut înaintea primei urme de compromitere, după ce aplici patch-ul pentru vulnerabilitatea folosită. Serverul vechi îl analizezi, apoi îl reinstalezi.
Dacă firma e entitate esențială sau importantă sub OUG 155/2024, transpunerea NIS2 aprobată prin Legea 124/2025, un incident semnificativ se anunță la DNSC cu alertă timpurie în 24 de ore, notificare în 72 de ore și raport final la o lună de la aceasta. Dacă sunt afectate date personale și încălcarea e susceptibilă să genereze un risc pentru drepturile persoanelor, notifici ANSPDCP în 72 de ore de la aflare, conform art. 33 GDPR, și informezi persoanele vizate când riscul e ridicat, conform art. 34. Plângerea penală o depui la poliție sau la parchet: accesul ilegal la un sistem informatic, art. 360 Cod penal, îl instrumentează parchetul de drept comun, nu DIICOT, care preia doar faptele din art. 361–365 sau pe cele ale unui grup infracțional organizat.
| Cine notifică | Către cine | Termen | Temei |
|---|---|---|---|
| Entitate esențială sau importantă | DNSC, alertă timpurie | 24 de ore de la constatare | OUG 155/2024 (NIS2) |
| Entitate esențială sau importantă | DNSC, notificare de incident | 72 de ore | OUG 155/2024 (NIS2) |
| Entitate esențială sau importantă | DNSC, raport final | o lună de la notificarea de 72 h (sau de la gestionarea incidentului) | OUG 155/2024, art. 15 alin. (7) |
| Orice operator de date personale | ANSPDCP | 72 de ore de la aflare | art. 33 GDPR |
| Orice operator, la risc ridicat | Persoanele vizate | fără întârzieri nejustificate | art. 34 GDPR |
| Orice persoană vătămată | Poliție / parchet (DIICOT la art. 361–365) | cât mai repede, pentru probe | Codul penal, art. 360–366 |
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw enable# Dovezile NU se scriu pe mașina compromisă: montează un volum extern
# (mount /dev/sdb1 /mnt/dovezi) sau rulează comenzile de pe stația de investigație,
# cu: ssh root@server 'ps auxf --sort=-%cpu' > ps.txt
mount /dev/sdb1 /mnt/dovezi && cd /mnt/dovezi
ps auxf --sort=-%cpu > ps.txt
ss -tunap > conexiuni.txt
last -aF > logari.txt
for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done > cron.txt
find / -xdev -type f -newermt "$(date -d '-14 days' +%F)" > modificate.txt
find / -xdev -name authorized_keys -exec sh -c 'echo "== $1"; cat "$1"' _ {} \; > chei.txt
sha256sum * > SUME.sha256CPU la 100 % în weekend a arătat un proces pornit dintr-un plugin WordPress vulnerabil. Echipa a izolat serverul, a făcut snapshot, a rotit parolele de bază de date și de plată și a repus magazinul pe un VPS nou din backup-ul de vineri.
Un ransomware a criptat serverul de facturare. Alerta timpurie la DNSC a plecat în aceeași zi, notificarea completă la 72 de ore, raportul final la trei săptămâni. Restaurarea din backup-ul offline a durat o zi.
Practic nu. Un atacator cu acces root poate înlocui binare, module de kernel sau servicii systemd cu variante care par legitime; nu poți ști ce a rămas. Reinstalarea de la zero plus restaurarea datelor e mai rapidă și singura garanție.
Din logurile centralizate, dacă le ai: prima autentificare anormală, prima cerere suspectă în nginx, prima modificare de fișier. Pe serverul afectat, datele fișierelor și intrările din cron dau un indiciu, dar pot fi falsificate. Backup-ul restaurat trebuie să fie dinaintea acestei date.
Dacă datele lor personale au fost accesate și riscul pentru ei e ridicat, GDPR îți cere să îi informezi direct, fără întârziere. Chiar când nu e obligatoriu, o comunicare scurtă și onestă costă mai puțin decât zvonul, fără detalii utile altor atacatori.
Un server de producție e atacat automat din primele minute după ce primește IP public, indiferent cât de mic e proiectul. Ghidul ordonează controalele după impact, de la accesul SSH până la răspunsul la incident, cu legislația din România care se aplică. Fiecare temă are o pagină dedicată, cu răspuns scurt, exemple și configurări.