Pe scurt: Dacă reinstalați un server după un atac sau îl curățați depinde de cât de sigur cunoașteți amploarea intruziunii. Dacă atacatorul a avut posibil drepturi de root, momentul intruziunii este neclar sau lipsesc jurnalele, o reconstruire din surse de încredere este alegerea mai fiabilă. O curățare vine în discuție doar la o infectare strict delimitată și bine dovedită. În ambele cazuri se aplică: mai întâi securizați probele și închideți breșa, apoi faceți ordine.
De ce se pune această întrebare atât de des după PHP2Shell
PHP2Shell permite, potrivit php.net, executarea de cod malițios de la distanță, fără autentificare. Cine a operat un server neactualizat trebuie să se întrebe de aceea dacă s-a întâmplat ceva în perioada de la 17.10.2026, prima tentativă de atac observată potrivit presei. Patchul nu răspunde la această întrebare și nu există indicatori de compromitere publicați și confirmați.
Dacă apoi se găsește un fișier suspect, un proces necunoscut sau un cronjob străin, se impune decizia. Impulsul este adesea să ștergeți repede sau să reinstalați imediat. Ambele pot fi corecte, dar nu ca prim pas.
Ordinea dinaintea deciziei
Înainte de a alege între curățare și reinstalare, trei lucruri trebuie făcute. Ele se aplică ambelor căi.
- Izolați: Scoateți serverul din rețea sau limitați accesul la strictul necesar, fără a-l opri, dacă memoria de lucru mai trebuie securizată.
- Securizați probele: Salvați jurnalele, fișierele, baza de date și, pe cât posibil, o imagine a sistemului, cu dată și sumă de control. De ce este necesar acest lucru înainte de orice reinstalare explică Securizați probele înainte de a reinstala.
- Implicați asigurătorul și protecția datelor: Multe polițe cibernetice așteaptă ca pașii esențiali să fie coordonați. Indicații se află la Asigurarea cibernetică: ce contează în caz de daună. Dacă există o obligație de notificare conform RGPD evaluează responsabilul cu protecția datelor sau avocatul.
Abia după aceea merită cântărirea propriu-zisă.
Reinstalarea serverului după atac sau curățarea: criteriile
| Criteriu | Curățare | Reinstalare |
|---|---|---|
| Amploarea intruziunii | Strict delimitată, dovedită, de exemplu un fișier în dosarul de upload fără alte urme | Neclară sau cu indicii de acces la sistem |
| Posibile drepturi de root ale atacatorului | Exclus, cu dovezi bune | Nu poate fi exclus |
| Disponibilitatea jurnalelor | Complete pentru perioada relevantă | Lacunare, suprascrise sau manipulabile |
| Efort | Mai mic, dacă constatarea este clară | Mai mare, dar mai bine planificabil |
| Incertitudine rămasă | Mai mare, ușile dosnice ascunse sunt greu de exclus | Mai mică, dacă reconstruirea se face curat din surse de încredere |
| Timp de indisponibilitate | De obicei mai scurt | De obicei mai lung, bine controlabil cu pregătire |
| Potrivire pentru sisteme vechi | Problematică, dacă sistemul este oricum învechit | Bună ocazie de a trece la o versiune PHP suportată |
Ca regulă generală: cu cât știți mai puțin, cu atât mai mult pledează totul pentru reconstruire. La o breșă în interpretorul PHP care execută cod în contextul utilizatorului serverului web, un atacator poate folosi alte vulnerabilități pentru a obține mai multe drepturi. Acest lucru abia poate fi exclus fără o investigație amănunțită.
Ambele căi în practică
Ce înseamnă cu adevărat „reinstalare”
Reinstalarea nu înseamnă copierea vechii copii de rezervă pe un server nou. O reconstruire începe cu un sistem de operare curat din sursă oficială, pachete actuale și o versiune PHP actualizată. Aplicația este instalată din originalul producătorului, la fel pluginurile și temele.
Abia apoi se adaugă propriul conținut, și anume verificat. Fișierele încărcate nu au voie să conțină scripturi executabile, baza de date poate conține conținut introdus, de exemplu conturi de administrator ascunse sau scripturi în articole. Fișierele de configurare se rescriu în loc să fie copiate. Toate datele de acces se reînnoiesc: baza de date, administratorii CMS, cheile SSH, cheile API, panoul de hosting.
Copiile de rezervă joacă aici un rol important, dar doar dacă starea lor este anterioară intruziunii și ele însele nu au fost modificate. Mai multe generații în locuri separate fac acest lucru verificabil; mai multe la Copii de siguranță după regula 3-2-1.
Când curățarea este justificabilă
O curățare poate fi sensibilă dacă infectarea a fost descoperită devreme, există jurnale complete, iar investigația nu indică alte accese. Atunci fișierele găsite sunt eliminate după securizare, cronjob-urile, conturile de utilizator și cheile SSH sunt verificate, iar fișierele nucleului sunt comparate cu originalul producătorului.
Importantă este o evaluare realistă: webshell-urile sunt adesea discrete și ascunse în mai multe locuri. Cum se găsesc descrie Recunoașterea și eliminarea webshell-urilor. După o curățare, serverul ar trebui observat îndeaproape, pentru ca o ușă dosnică trecută cu vederea să iasă la iveală.
Nu ștergeți nimic înainte ca jurnalele și fișierele să fie securizate și închideți breșa înainte ca serverul să revină în rețea. Altfel pierdeți urmele și invitați următoarea intruziune.
Când nu aveți nevoie de un furnizor de servicii
La un site simplu pe hosting partajat, unde furnizorul de hosting administrează sistemul și confirmă patchul PHP, decizia nici nu vă aparține adesea. Puteți reinstala aplicația din original, verifica conținutul și reînnoi datele de acces, sprijinit de furnizorul de hosting. Și o echipă internă experimentată poate duce singură o reconstruire, dacă securizarea probelor și documentarea sunt la punct.
Ajutorul extern merită atunci când drepturile de root nu pot fi excluse, ar putea fi afectate date cu caracter personal, este implicată asigurarea sau mai multe sisteme sunt interconectate.
Cum ajută PHP SOS concret?
- Securizăm jurnalele, fișierele și baza de date în mod probatoriu, înainte de a se modifica ceva.
- Evaluăm amploarea intruziunii și recomandăm curățarea sau reconstruirea, cu motivare, separat pe dovedit, probabil și necunoscut.
- La nevoie, reconstruim serverul din surse de încredere, cu versiune PHP actualizată și accese reînnoite.
- Preluăm eliminarea malware acolo unde o curățare este justificabilă și documentăm fiecare pas.
Concluzie
Întrebarea „reinstalăm sau curățăm?” își găsește răspunsul în cunoașterea intruziunii. Cine nu cunoaște sigur amploarea reconstruiește. Cine o poate delimita bine, cu dovezi, are voie să curețe. În ambele cazuri se aplică aceeași ordine: izolați, securizați, închideți breșa, apoi faceți ordine.
Întrebări frecvente
Este reinstalarea întotdeauna mai bună după un atac?
Nu întotdeauna, dar adesea. Dacă nu este clar cât de departe a ajuns atacatorul, o reconstruire din surse de încredere este de obicei alegerea mai fiabilă. La o infectare strict delimitată și bine dovedită, o curățare poate fi suficientă.
Pot pur și simplu să restaurez o copie de rezervă veche?
Doar dacă este sigur că copia a fost creată înainte de intruziune și nu conține nicio ușă dosnică. În plus, breșa trebuie să fie închisă în prealabil, altfel serverul poate fi atacat imediat din nou. Datele mai recente trebuie verificate separat.
Ce trebuie să securizez înainte de reinstalare?
Jurnalele, o copie a fișierelor și a bazei de date și, dacă este posibil, o imagine a sistemului. Aveți nevoie de aceste probe pentru analiza cauzelor, asigurare și o eventuală notificare. După ștergere, ele dispar.
Este suficient să șterg webshell-ul găsit?
Rareori. Atacatorii instalează adesea mai multe uși dosnice, de exemplu cronjoburi, conturi de utilizator sau chei SSH. Cine șterge doar fișierul vizibil lasă celelalte accese deschise.