Pe scurt: Înainte de a reinstala un server compromis, salvați probele în ordinea volatilității lor: mai întâi procesele, conexiunile și utilizatorii autentificați, apoi jurnalele și configurația, apoi o imagine completă a sistemului și datele serviciilor din amonte. Fiecare salvare primește o sumă de control și este depusă în afara serverului. Pentru aceasta serverul este deconectat de la rețea, dar nu este oprit.
Reflexul de a reinstala imediat
Cine descoperă o intruziune vrea să o încheie cât mai repede. Un sistem proaspăt, instalat curat, cu parole noi: aceasta dă senzația de control. Din punct de vedere tehnic, o reconstruire este adesea și calea corectă, mai ales dacă atacatorul a avut drepturi de root.
Problema este momentul. Odată cu sistemul vechi dispar toate răspunsurile la întrebările care vin în zilele următoare. Prin ce vulnerabilitate a intrat atacatorul? De când era în sistem? A avut acces la datele clienților? Este afectat și serverul de baze de date din apropiere? Fără urme rămân doar presupuneri, iar acestea nu ajută nici la protecția datelor, nici la asigurare.
După PHP2Shell se adaugă un aspect special: nu există Indicators of Compromise publicați și confirmați. Dacă și cum a fost afectat un server se poate deduce doar din comportament, deci tocmai din urmele pe care o reconstruire grăbită le șterge. Presa de specialitate recomandă păstrarea jurnalelor serverului începând cu 20.10.2026.
Conservarea probelor pe server: ordinea contează
Urmele sunt volatile în grade diferite. Ce se află în memoria de lucru dispare la următoarea repornire. Jurnalele supraviețuiesc mai mult, dar sunt rotite. Datele de la serviciile din amonte dispar după termenele lor proprii. Rezultă următoarea ordine:
| Urmă | Volatilitate | Cum se salvează |
|---|---|---|
| Procese, conexiuni de rețea, utilizatori autentificați | dispare la repornire | scrieți în fișiere ieșirile comenzilor de sistem |
| Memoria de lucru | dispare la repornire | doar cu unelte speciale, sarcină pentru specialiștii în criminalistică |
Fișiere temporare în /tmp sau /dev/shm |
adesea șterse la repornire | copiați, fără a executa |
| Jurnalele serverului web, ale PHP, ale sistemului | sunt rotite | copiați integral, opriți rotația |
| Sistemul de fișiere și baza de date | stabile până la reinstalare | snapshot sau imagine a suportului de date, export al bazei de date |
| CDN, WAF, firewall, furnizor de hosting | păstrare conform termenelor furnizorului | solicitați exportul, cereți confirmare în scris |
Memoria de lucru o salvați doar dacă este disponibilă o persoană cu uneltele potrivite și cu experiență. La sistemele cu date sensibile sau cu un litigiu previzibil, această sarcină ar trebui preluată de o criminalistică IT.
Datele volatile, fixate în câteva minute
Comenzile următoare nu modifică nimic în sistem. Ele scriu starea curentă în fișiere, care sunt apoi salvate în afara serverului. Creați directorul-țintă pe cât posibil pe un suport de date conectat, separat:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
Cum salvați apoi complet jurnalele și cum le evaluați descrie ghidul Evaluarea jurnalelor serverului web după un atac. La serverele virtuale, un snapshot prin administrarea furnizorului este cea mai simplă cale spre o imagine completă. El surprinde sistemul fără ca dumneavoastră să porniți alte unelte pe serverul compromis.
Pentru ca salvarea să aibă valoare ulterior
O salvare valorează cât dovada ei. Trei reguli o fac credibilă:
- Sume de control: Fiecare fișier salvat primește o sumă de control SHA-256. Astfel se poate arăta ulterior că copia este nemodificată.
- Proces-verbal: Cine a salvat ce, când, cu ce comandă, unde? Fiecare predare către terți se consemnează. Specialiștii numesc aceasta lanțul de custodie.
- Depozitare separată: Copiile aparțin unui sistem la care atacatorul nu a avut acces și se folosesc în continuare doar în citire.
După aceea lucrați doar cu copii. Orice analiză pe original modifică marcajele de timp și poate suprascrie urme. Nu executați niciodată fișierele suspecte și nu le deschideți prin browser.
Solicitați din timp jurnalele de la CDN, WAF și furnizorul de hosting. Aceste date se află în afara serverului dumneavoastră și sunt greu de manipulat de către un atacator, dar sunt adesea păstrate doar pe scurt.
Ce distruge situația probelor
Multe urme nu se pierd din cauza atacatorului, ci din cauza unui prim ajutor bine intenționat. Acești pași ar trebui evitați înainte de salvare:
- Repornirea sau oprirea: Procesele, conexiunile și memoria de lucru dispar după aceasta.
- Antivirus cu ștergere automată: Elimină fișiere înainte ca cineva să le fi salvat și modifică marcajele de timp.
- Curățarea jurnalelor sau a dosarelor temporare: Chiar dacă spațiul se împuținează, mai întâi copiați, apoi ștergeți.
- Instalarea pe server a unor unelte noi din internet: Orice instalare scrie în sistemul de fișiere și poate acoperi urme.
- Autentificarea fără necesitate cu date de acces privilegiate: Dacă pe server mai rulează cod malițios, parolele introduse pot fi citite.
Tocmai asigurătorii întreabă ulterior ce a fost salvat și când. Indicații despre obligațiile tipice găsiți la Asigurarea cyber: ce contează în caz de daună.
Cât timp avem pentru salvare?
Nu orice incident permite o salvare îndelungată. Dacă tocmai se produce o scurgere de date sau sunt atacați vizitatorii, izolarea are prioritate. Deconectarea de la rețea cu sistemul în funcțiune le îmbină pe amândouă: atacatorul pierde accesul, urmele rămân păstrate. Pentru majoritatea serverelor web este apoi suficient un interval rezonabil pentru datele volatile și pentru snapshot.
Luați decizia în mod conștient și consemnați-o: cine a decis când se reinstalează și ce a fost salvat înainte? Această notă va face ulterior parte din cronologia incidentului. Dacă reconstruirea sau curățarea este calea potrivită analizează articolul Reinstalarea sau curățarea serverului?.
Cum ajută PHP SOS concret?
- Salvăm datele volatile, jurnalele și imaginile sistemului în ordinea corectă, cu sume de control și proces-verbal.
- Solicităm datele serviciilor din amonte înainte să expire termenele lor de păstrare.
- La nevoie, preluăm împreună cu parteneri specializați salvarea și evaluarea criminalistică.
- Abia după aceea reconstruim serverul, închidem punctul de intrare și documentăm incidentul, până când este încheiat.
Întrebări frecvente
De ce ar trebui să salvez probe înainte de reinstalare?
Pentru că doar urmele arată cum a intrat atacatorul, cât timp a fost în sistem și la ce date a putut ajunge. Aveți nevoie de aceste răspunsuri pentru protecția datelor, pentru asigurare și pentru întrebarea dacă sunt afectate și alte sisteme. După reconstruire, ele sunt pierdute.
Ce este cel mai urgent la salvare?
Datele volatile, precum procesele în execuție, conexiunile de rețea și utilizatorii autentificați, dispar la oprirea sistemului. Ele se fixează primele. Urmează jurnalele, o imagine a sistemului și datele serviciilor din amonte.
Este suficientă o copie de siguranță obișnuită drept conservare a probelor?
De obicei nu. Multe copii de siguranță nu conțin jurnale, fișiere de sistem și metadate precum marcajele de timp și proprietarii. Pentru conservarea probelor aveți nevoie de o copie completă, nemodificată, cu sumă de control, în mod ideal un snapshot sau o imagine a suportului de date.
Am voie să deconectez serverul de la rețea înainte de salvare?
Da, dacă rămâne în funcțiune. Deconectarea de la rețea oprește scurgerea de date și controlul de la distanță, fără a distruge urme volatile. Repornirea sau oprirea șterge, în schimb, memoria de lucru și procesele în execuție.