Serverul a fost spart sau este atacat: ce faceți

Dacă bănuiți că cineva a intrat pe serverul dvs. sau că serverul este atacat din exterior, urmați pașii de mai jos în ordine: securizați contul blackbox.md, securizați accesul la server din panoul app.blackbox.md (pagina „Serverele mele”, app.blackbox.md/my-servers, meniul „Infrastructură” → „Serverele mele”), verificați serverul și refaceți-l de la zero. Comenzile se rulează pe server prin SSH, ca root (Conectarea la server prin SSH (Windows, macOS, Linux)).

Disponibil pentru: titularul contului blackbox.md care a comandat serverul. Comenzile de verificare: oricine are acces root prin SSH la server. Pe cardurile marcate „Administrat” butoanele panoului nu apar; pentru aceste servere scrieți-ne direct.

Semnele unui server spart

Înainte să căutați chei străine, identificați cele două chei puse de BLACKBOX pe serverele noi: „Cheie de administrare (blackbox.md)” și cheia agentului AI, cu comentariul blackbox-agent-…. Ele nu sunt semne de intruziune: Cheile BLACKBOX de pe serverul dvs.. Atenție: comentariul unei chei îl alege cine o adaugă, deci un atacator își poate numi cheia la fel. Dacă vedeți mai multe rânduri blackbox-agent-… sau aveți dubii, ștergeți-le (pasul 2): panoul nu depinde de cheia agentului.

Ce faceți întâi

Dacă serverul atacă alte sisteme sau trimite spam chiar acum (sesizare de la BLACKBOX, coadă de emailuri în creștere, trafic de ieșire mare):

1. În „Serverele mele”, pe cardul serverului, apăsați „Oprește” și confirmați „Opriți NUME_SERVER?”.
2. Scrieți imediat suportului (secțiunea „Ce trimiteți suportului” de mai jos).

Cât timp serverul este oprit, facturarea continuă, iar „Resetează parola”, lista „Chei instalate” și ștergerea cheilor nu funcționează: au nevoie de serverul pornit. Porniți-l din nou cu „Pornește” abia când sunteți gata să faceți pașii de mai jos; la pornire pot reporni și programele atacatorului (Repornirea, oprirea și pornirea serverului).

Altfel, nu opriți serverul: faceți întâi pașii 1 și 2, cât serverul este pornit și răspunde prin SSH.

Pasul 1. Securizați contul blackbox.md

1. Schimbați parola contului: „Contul meu” → „Profil” → secțiunea „Securitatea contului” → „Parolă” → „Schimbă parola”. Completați „Parola curentă” și „Parolă nouă”, apoi apăsați „Salvează parola”. Apare „Parola a fost schimbată. Vă rugăm autentificați-vă din nou.” și sunteți deconectat. Se încheie toate sesiunile de pe blackbox.md și se opresc toate token-urile API create înainte de schimbare (Schimbarea parolei contului).
2. Autentificați-vă cu parola nouă și deschideți „Token-uri API”. Dacă în coloana „Ultima utilizare” apare o dată recentă, dar nu ați folosit dvs. token-ul, acesta a ajuns la altcineva. Apăsați „Revocă” la fiecare token vechi (lista nu arată că schimbarea parolei le-a oprit) și confirmați „Revocați acest token? Orice client AI care îl folosește va pierde accesul imediat.” Creați token-uri noi doar pentru clienții AI pe care îi folosiți (Token-uri API: creare, copiere și revocare).
3. În „Chei SSH”, ștergeți cu „Șterge” cheile pe care nu le recunoașteți. Ștergerea de aici nu scoate cheia de pe servere (pasul 2).
4. În „Comenzi” și „Sold”, verificați că nu există comenzi sau plăți pe care nu le-ați făcut.
5. Deschideți panoul cu „Deschide panoul” (sau „Panou de administrare” din meniul contului). În panou mergeți la „Setări” → „Sesiuni”, apăsați „Deconectare de peste tot” și confirmați „Deconectați toate sesiunile acestui cont, inclusiv aceasta? Va trebui să vă autentificați din nou.” Se încheie toate sesiunile din panou, iar dispozitivele reținute pentru 2FA sunt uitate. Apoi deschideți din nou panoul din cont (Setările panoului: profil, parolă și sesiuni).

Contul creat cu Google sau GitLab

Contul nu are parolă pe blackbox.md, iar secțiunea „Parolă” nu apare. Schimbați parola contului Google sau GitLab, activați acolo autentificarea în doi pași și închideți sesiunile active. Token-urile API nu se opresc automat: revocați-le unul câte unul cu „Revocă”. Ceilalți pași rămân la fel (Autentificarea cu Google sau GitLab).

Pasul 2. Securizați accesul la server din panou

Lucrați pe cardul serverului din „Serverele mele”. Dacă și contul ar fi putut fi folosit de altcineva, repetați pașii pentru fiecare server.

1. Apăsați „Resetează parola” și confirmați „Resetați parola pentru NUME_SERVER? Parola curentă încetează să funcționeze imediat.” Noua parolă root apare pe card, în rândurile „Utilizator” și „Parolă”; păstrați-o într-un manager de parole. Dacă apare reset_failed, parola nu s-a schimbat: de regulă panoul nu s-a putut conecta la server. Vedeți Resetarea parolei root și scrieți-ne.
2. Apăsați „Adaugă cheie SSH” și verificați fiecare rând din „Chei instalate”. Lăsați „Cheie de administrare (blackbox.md)” (nu are buton „Șterge”) și cheile dvs. Pentru orice altă cheie pe care nu o recunoașteți, notați amprenta și comentariul, apoi apăsați „Șterge” și confirmați „Ștergeți cheia SHA256:… de pe acest server?”. Apare „Cheie ștearsă.”
3. Ștergeți la fel și cheia agentului AI (blackbox-agent-…) dacă nu folosiți acces SSH prin AI sau dacă token-urile API ar fi putut ajunge la altcineva: un asistent AI cu permisiunea „Vizualizează parolele/accesul serverelor” poate primi această cheie. Dacă folosiți în continuare acces SSH prin AI, după ștergere cereți o cheie nouă cu regenerate=true; fără acest parametru revine cheia veche (Acces SSH și chei SSH prin asistentul AI).
4. Dacă nu aveți încă o cheie a dvs. pe server, adăugați-o din același loc („Folosește o cheie salvată” sau „Lipește o cheie nouă” → „Adaugă cheia”). Conectați-vă cu ea într-o fereastră nouă de terminal și lăsați sesiunea deschisă (Adăugarea și ștergerea cheilor SSH pe server).
5. După ce cheia dvs. funcționează, apăsați „Dezactivează login cu parolă” și confirmați. Cardul arată „Doar cheie” (Activarea și dezactivarea autentificării SSH cu parolă).

Important Nu ștergeți din authorized_keys cheia de administrare (în panou: „Cheie de administrare (blackbox.md)”) și nu setați PermitRootLogin no: oricare dintre ele blochează resetarea parolei și gestionarea cheilor din panou. Clienții nu au consolă web sau VNC. Înainte să schimbați setările SSH sau firewall-ul, păstrați deschisă o a doua sesiune SSH; dacă pierdeți accesul, scrieți suportului.

Pasul 3. Verificați serverul

Comenzile de mai jos doar citesc informații. Copiați rezultatele pe calculatorul dvs. și notați ce găsiți: procese, adrese IP, date, căi de fișiere. Nu ștergeți fișiere și nu opriți procese la întâmplare: atacatorii lasă de regulă mai multe căi de revenire, iar ce ștergeți nu mai poate fi analizat.

Ubuntu și Debian

who
last -n 30
lastb -n 30
journalctl -u ssh --since "7 days ago" | grep -E "Accepted|Failed password|Invalid user"
ls -la /var/spool/cron/crontabs

AlmaLinux și CentOS Stream

who
last -n 30
lastb -n 30
journalctl -u sshd --since "7 days ago" | grep -E "Accepted|Failed password|Invalid user"
ls -la /var/spool/cron

who arată cine este conectat acum, last autentificările reușite, iar lastb încercările eșuate (multe încercări eșuate sunt normale). În jurnal, liniile Accepted sunt autentificări reușite, cu metoda (password sau publickey) și adresa IP; la publickey, la sfârșitul liniei apare și amprenta cheii folosite (SHA256:…), pe care o puteți compara cu lista „Chei instalate”. Dacă last lipsește, folosiți doar journalctl. Ultima comandă arată ce utilizatori au sarcini cron: fiecare fișier poartă numele unui utilizator.

Procese și conexiuni

ps aux --sort=-%cpu | head -n 15
ls -l /proc/PID/exe
ss -tunap
ls -la /tmp /var/tmp /dev/shm

Înlocuiți PID cu numărul din coloana a doua a unui proces suspect: linkul exe arată programul real. O cale în /tmp sau /dev/shm ori mențiunea (deleted) sunt semne rele. În ss, căutați conexiunile ESTAB spre adrese și porturi necunoscute și numele programului din users:((…)).

Sarcini programate, servicii, utilizatori și chei

crontab -l
cat /etc/crontab
ls -la /etc/cron.*
systemctl list-timers --all
systemctl list-units --type=service --state=running
awk -F: '$3 == 0 || $3 >= 1000 {print $1, $3, $6, $7}' /etc/passwd
getent group sudo wheel
cat /root/.ssh/authorized_keys
ls -la /home/*/.ssh/authorized_keys

Doar root trebuie să aibă UID 0. Conturile cu UID de la 1000 în sus sunt conturi obișnuite de utilizator (nobody, cu UID 65534, este normal): verificați că le cunoașteți pe toate, la fel ca membrii grupurilor sudo și wheel. În cron și în servicii, liniile care descarcă și rulează scripturi (curl, wget) sunt suspecte.

Fișierele site-ului

find /var/www -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -n 50
find /var/www -path "*uploads*" -name "*.php"

Înlocuiți /var/www cu directorul site-ului dacă este altul; pentru o perioadă mai lungă, măriți 7 (zile). Fișierele PHP din directoarele de încărcări (de exemplu wp-content/uploads la WordPress) sunt foarte suspecte: verificați-le pe fiecare.

Pasul 4. Refaceți serverul de la zero

Risc Un server compromis nu mai poate fi considerat sigur, chiar dacă ați șters tot ce ați găsit: pot rămâne chei, utilizatori, sarcini programate sau programe modificate pe care nu le-ați observat. Calea sigură este un server instalat de la zero.

Panoul nu are buton de reinstalare a sistemului de operare. Pașii:

1. Comandați un server nou (Plasarea unei comenzi pas cu pas). La pasul „Cheie SSH pentru server” atașați cheia dvs. și lăsați bifată caseta „Dezactivează autentificarea prin parolă (doar cheie SSH)”: serverul va accepta prin SSH doar autentificarea cu cheie (Cheia SSH la comandă și serverele „doar cu cheie”).
2. Securizați-l și instalați pachetele din sursele oficiale ale distribuției (Securizarea unui server nou: lista de verificare).
3. Instalați aplicația din sursa oficială: CMS-ul, modulele și temele de la producător, codul dvs. din depozitul git. Nu copiați programe, scripturi, sarcini cron sau configurații de pe serverul vechi.
4. Restaurați doar datele (baze de date, fișiere încărcate, conținut) dintr-un backup făcut înainte de compromitere. BLACKBOX nu face copii automate ale serverului; dacă nu aveți un backup mai vechi, copiați datele de pe serverul vechi și verificați-le înainte (Strategia de backup pentru serverul dvs., Mutarea unui site pe serverul BLACKBOX).
5. Schimbați toate secretele aplicației: parolele bazelor de date, cheile API, datele SMTP, cheile secrete din configurație, parolele administratorilor site-ului. Înlocuiți și cheile private păstrate pe serverul vechi (de exemplu pentru deploy).
6. Îndreptați domeniul spre noul server (Cum îndreptați domeniul către server). Dacă ați conectat Cloudflare sau GoDaddy, o puteți face din pagina „DNS” a panoului (Gestionarea înregistrărilor DNS din panou).
7. Copiați ce mai aveți nevoie de pe serverul vechi, inclusiv jurnalele, apoi ștergeți-l cu „Șterge definitiv”. Ștergerea se execută după o perioadă de grație de 24 de ore și nu returnează bani pentru perioada începută; până atunci serverul se facturează. Comparația cu anularea comenzii: Ștergerea definitivă a unui server.

Dacă nu vreți un server nou, întrebați suportul dacă sistemul de operare poate fi reinstalat pe același server. La reinstalare se pierd toate datele de pe server, așa că salvați-le înainte; apoi urmați pașii 2–5 din lista de mai sus.

Pasul 5. Închideți calea de intrare

Înainte să puneți serverul nou în funcțiune, eliminați cauza, altfel atacul se repetă:

• CMS, module și teme neactualizate. Actualizați-le, ștergeți-le pe cele nefolosite și activați actualizările automate de securitate (Actualizări de sistem și actualizări automate de securitate).
• Parole slabe sau refolosite. Folosiți parole unice, generate de un manager de parole, pentru root, administrarea site-ului și bazele de date; pentru SSH folosiți chei.
• Servicii accesibile din internet. Legați bazele de date de 127.0.0.1 și restricționați panourile de administrare (de exemplu phpMyAdmin). Filtrul de rețea administrat de BLACKBOX nu înlocuiește aceste măsuri (Firewall: filtrarea din rețea și ufw/firewalld pe server).
• Panoul. Activați autentificarea în doi pași în panou (Autentificarea în doi pași (2FA) în panou).
• Accesul BLACKBOX. Pentru root folosiți PermitRootLogin prohibit-password, nu PermitRootLogin no, și nu ștergeți „Cheie de administrare (blackbox.md)”.

Apoi parcurgeți toată lista: Securizarea unui server nou: lista de verificare.

Responsabilitatea dvs.

• Conform Termenilor și condițiilor, capitolul 3, răspundeți integral pentru activitatea proprie și a tuturor celor cărora le dați acces la servicii. Tot dvs. răspundeți de protejarea parolelor, a cheilor SSH și a token-urilor API. BLACKBOX nu răspunde pentru folosirea conturilor dvs. de către terți, dacă nu există o breșă demonstrată a sistemelor BLACKBOX.
• Capitolul 2 al Termenilor interzice, printre altele, spamul și participarea, „voluntar sau prin neglijență gravă”, la atacuri DoS și DDoS (Politica de utilizare acceptabilă: ce nu este permis).
• La o încălcare detectată, de exemplu printr-o sesizare externă, BLACKBOX poate suspenda sau înceta serviciile, integral sau parțial, cu sau fără notificare prealabilă, în funcție de gravitate. Răspundeți repede suportului și spuneți ce ați făcut.
• Dacă pe server erau date personale ale utilizatorilor dvs. (de exemplu, clienții unui magazin online), dvs. sunteți operatorul acestor date și răspundeți de respectarea legii (Termeni, capitolul 8). Evaluați dacă trebuie să notificați Centrul Național pentru Protecția Datelor cu Caracter Personal și persoanele afectate (art. 33–34 din Legea nr. 195/2024). BLACKBOX, ca persoană împuternicită de operator, vă oferă asistență rezonabilă, în măsura în care este posibil tehnic la nivelul infrastructurii de găzduire: Acordul privind prelucrarea datelor (DPA) pentru companii.

Atac din exterior: serverul nu este spart

Dacă la pasul 3 nu ați găsit autentificări reușite străine, procese sau chei necunoscute, serverul este probabil doar ținta unui atac din exterior.

Încercări de ghicire a parolei SSH

Mii de linii Failed password sau Invalid user în jurnal și o listă lungă la lastb sunt obișnuite pentru orice server cu adresă IP publică: roboți scanează permanent internetul. Protejați-vă cu fail2ban (Protecție împotriva încercărilor de ghicire a parolei cu fail2ban) și cu autentificarea doar cu cheie („Dezactivează login cu parolă”, pasul 2).

Trafic HTTP excesiv spre site

1. Treceți domeniul prin proxy-ul Cloudflare (norul portocaliu). Dacă ați conectat Cloudflare în panou, bifați „Proxy” la înregistrările A, AAAA și CNAME ale site-ului, în pagina „DNS” (Gestionarea înregistrărilor DNS din panou); altfel, activați proxy-ul direct în contul Cloudflare. Traficul web trece apoi prin Cloudflare, care poate filtra cererile.

2. Limitați numărul de cereri pe adresă IP în nginx. Creați fișierul /etc/nginx/conf.d/ratelimit.conf:

   limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
   limit_req_status 429;

   Adăugați în blocul server { } al site-ului:

   limit_req zone=perip burst=20 nodelay;

   Verificați configurația și reîncărcați nginx:

   nginx -t
   systemctl reload nginx

   Fiecare adresă IP poate face 10 cereri pe secundă, cu o rezervă de 20; cererile în plus primesc eroarea 429. Ajustați valorile după site. În spatele Cloudflare, nginx vede adresele Cloudflare: configurați întâi adresele reale ale vizitatorilor (documentația Cloudflare).

3. Dacă atacul continuă sau vine direct pe adresa IP a serverului, scrieți suportului.

Ce trimiteți suportului

Scrieți la support@blackbox.md, deschideți un tichet din „Contul meu” → „Ajutor și suport” (Deschiderea unui tichet de suport) sau, pentru urgențe, sunați la +373 78 003948 (luni–vineri, 09:00–18:00, ora Moldovei). Includeți:

• adresa IP a serverului;
• numărul comenzii (BBX-…);
• când ați observat problema (data, ora și fusul orar);
• ce ați făcut deja (server oprit, parolă resetată, chei șterse, server nou comandat);
• ce ați găsit la pasul 3, ca text: procese, adrese IP, rânduri din jurnale, amprentele cheilor șterse.

Securitate Nu trimiteți niciodată parole, chei private sau token-uri API, nici suportului BLACKBOX. Amprenta unei chei și cheia publică se pot trimite fără risc.

Întrebări frecvente

Pot curăța serverul fără să-l reinstalez? Puteți încerca, dar nu veți ști sigur că ați găsit tot. Pentru un server cu un site sau cu date importante, recomandăm un server nou (pasul 4).

Poate BLACKBOX să curețe serverul în locul meu? BLACKBOX nu accesează și nu citește conținutul aplicației dvs., cu excepția suportului tehnic la cererea dvs. explicită sau a cazurilor în care legea ne obligă (Acordul privind prelucrarea datelor (DPA) pentru companii). Pentru ajutor la curățare sau la mutarea pe un server nou, întrebați suportul: Servicii profesionale la cerere: administrare, DevOps, migrare.

Am primit o sesizare de abuz, dar nu găsesc nimic pe server. Ce fac? Răspundeți-ne oricum cât mai repede: spuneți ce ați verificat la pasul 3 și ce ați găsit. Uneori sursa este o aplicație de pe server, de exemplu un formular de contact folosit pentru spam.

Pot primi altă adresă IP? Adresa IP nu se schimbă din panou. Un server nou comandat primește propria adresă IP; pentru alte variante, scrieți-ne.