Server hackuit, ce faci? Primii pași și ajutor de urgență

Pe scurt: Sunteți afectat? Sunați-ne. Vă ajutăm. Dacă bănuiți că serverul dumneavoastră a fost hackuit, contează mai întâi un lucru: păstrarea urmelor. De la primul mesaj, preluăm la distanță imaginea situației, salvarea, izolarea, curățarea și documentarea, până când incidentul este încheiat.

Sunteți afectat? Semne că un server a fost hackuit

O bănuială este suficientă pentru a ne contacta. Nu trebuie să dovediți atacul. Indicii tipice sunt:

• Serverul web sau PHP-FPM pornește procese precum sh sau bash. Este un semnal de alarmă puternic, pe care îl explicăm pe pagina Serverul web pornește un shell.
• În dosarele de încărcare, de cache sau temporare se află fișiere PHP noi sau necunoscute.
• Există cronjob-uri pe care nu le-a creat nimeni sau chei SSH pe care nu le poate atribui nimeni.
• Încărcarea este ridicată fără un motiv vizibil sau serverul stabilește conexiuni de ieșire neobișnuite.
• E-mailurile serverului dumneavoastră ajung în spam sau sunt respinse.
• Furnizorul de hosting, un client sau un avertisment din browser semnalează cod malițios.
• În CMS apar conturi de administrator pe care nu le-a creat nimeni.

Alte semne găsiți la Am fost deja compromis?. Dacă se aplică mai multe puncte, tratați serverul ca hackuit până se dovedește contrariul.

Server hackuit: ce faceți imediat

1. Păstrați calmul și nu modificați nimic. Nu ștergeți fișiere, nu faceți „reparații rapide”, nu reinstalați peste starea veche.
2. Notați momentul. Notați ce ați observat și când, și cine a făcut ultimele modificări în sistem.
3. Păstrați logurile. Jurnalele de acces, de erori și de sistem nu au voie să se rotească sau să fie suprascrise. La PHP2Shell, presa de specialitate recomandă păstrarea logurilor serverului începând cu 20.10.2026.
4. Reduceți suprafața de atac. Scoateți serverul din rețeaua publică sau blocați-l prin firewall dacă datele ar putea fi exfiltrate. Nu îl opriți pur și simplu.
5. Adunați accesurile. Cine are acces SSH, la panou, FTP, CMS și baza de date? Schimbați parolele abia după înțelegere și doar de pe un dispozitiv curat.
6. Desemnați o persoană de contact. O persoană cu competență de decizie trebuie să fie disponibilă, inclusiv pentru oprire și reporniri.
7. Contactați-ne acum. Sunați-ne sau scrieți-ne pe WhatsApp. Restul clarificăm cu dumneavoastră pas cu pas.

Scos din rețea sau lăsat să ruleze?

Aceasta este cea mai frecventă întrebare în primele minute și nu are un răspuns general. Dacă rulează un magazin online cu plăți sau un portal cu date ale clienților, protecția datelor primează de obicei. Atunci o izolare temporară este corectă, de exemplu printr-o pagină de mentenanță sau o regulă de firewall care permite doar administratorii dumneavoastră.

O oprire bruscă este, în schimb, rareori cel mai bun prim pas, deoarece în memoria de lucru se află urme pe care o repornire le șterge. Mai bună este o imagine a sistemului, de exemplu un snapshot la furnizorul de hosting, înainte de a modifica ceva. În situația PHP2Shell, BSI recomandă scoaterea temporară din rețea a serverelor web, dacă o actualizare nu este posibilă imediat. Aceasta nu înseamnă că fiecare server oprit a fost hackuit.

Dacă în cazul dumneavoastră izolați, limitați sau lăsați să ruleze, decidem împreună cu dumneavoastră pe baza a ceea ce se află pe sistem.

Reinstalat sau curățat?

Mulți ar vrea cel mai bine să reconstruiască imediat serverul. Nu este greșit, dar abia după salvare. Altfel rămâne neclar cum a intrat atacatorul, iar aceeași cale este deschisă și noului sistem. Cântărirea o descrie pagina Reinstalați serverul sau îl curățați?, iar salvarea înainte de o reconstruire pagina Conservați probele înainte de reinstalare.

Important: o actualizare PHP singură nu rezolvă problema. Ea închide vulnerabilitatea, dar nu elimină software-ul malițios deja introdus. Cum se găsesc urmele în jurnale este descris la Analiza logurilor serverului web după un atac. Și porniți de la premisa că datele de acces din fișierele de configurare au fost citite: accesurile la baza de date, la e-mail și la API aparțin listei de secrete de înnoit.

Cum ajută PHP SOS concret?

1. Imaginea situației: Clarificăm cu dumneavoastră ce s-a observat, ce sisteme ar putea fi afectate și ce date se află acolo.
2. Salvare și închidere: Salvăm fișierele, baza de date și logurile înainte de a modifica ceva. Apoi izolăm atacul și închidem ușa de intrare, la PHP2Shell cu patch și repornirea tuturor proceselor PHP.
3. Verificare și curățare: Căutăm webshell-uri, uși dosnice, cronjob-uri și accesuri străine și le eliminăm. Detalii găsiți la Eliminarea malware-ului și a webshell-urilor.
4. Securizare și raport: Primiți o documentație cu cronologie, locurile în care s-au găsit urme și recomandări. Dacă incidentul depășește un server, trecem la un Incident Response structurat.

Ce nu ar trebui să faceți

Sub stres se fac greșeli evitabile. Nu ștergeți fișiere „suspecte” din bănuială, fără să le fi salvat înainte. Nu rulați comenzi din forumuri pe care nu le înțelegeți. Și nu instalați plugin-uri de securitate pe un server care poate fi deja compromis: codul malițios poate păcăli scannerele, iar rezultatul vă adoarme într-o falsă siguranță. Prudență și la sfaturile de a bloca toate cererile cu un anumit ID de sesiune; autorii de specialitate resping în mod expres astfel de sfaturi privind PHP2Shell. Versiunea proprie o puteți verifica sigur cu php -v și printr-o privire în changelog-ul pachetului distribuției dumneavoastră, deoarece backporturile lasă adesea numărul versiunii neschimbat.

Ce ar trebui să ne trimiteți

• o scurtă descriere: ce a atras atenția, de când, ce s-a modificat ultima dată
• tipul sistemului: server propriu, vServer, server administrat sau pachet de hosting
• accesul prin SSH sau panou ori permisiunea de a vorbi cu furnizorul dumneavoastră de hosting
• indicii despre copiile de siguranță existente și vechimea lor
• mesajele de avertizare ale furnizorului de hosting, ale browserului sau ale clienților, în formularea exactă

Dacă lipsește ceva din acestea, contactați-ne oricum. Golurile le închidem în discuție.

De ce PHP SOS

Lucrăm Made in Germany și suntem specializați în securitate IT de peste 25 de ani, împreună cu rețeaua noastră de parteneri din profesioniști cyber. Aveți un singur interlocutor, iar noi lucrăm la distanță, fără deplasare, în toată Germania și Europa. Fiecare pas este documentat, iar noi separăm deschis ce este dovedit, probabil și necunoscut. Promisiuni pe care nu le poate ține nimeni nu facem. O privire de ansamblu asupra etapei de după incident găsiți în Lista de verificare după un hack, iar întregul ajutor de urgență la Site hackuit? Ajutor de urgență la distanță. Despre obligația de notificare în caz de incidente cu datele citiți regula celor 72 de ore; evaluarea juridică rămâne la responsabilii cu protecția datelor și la avocați.

Sunteți afectat? Sunați-ne. Vă ajutăm.

Nu așteptați până când bănuiala devine un prejudiciu mai mare. Preluăm cazul de la primul mesaj și rămânem alături până când incidentul este încheiat și documentat. Anunțați acum urgența.

Întrebări frecvente

Surse

• BSI: Oficiul Federal German pentru Securitatea Informațiilor
• RGPD art. 33: notificarea autorității de supraveghere
• OWASP Cheat Sheets