Salt la conținut

Setări cookie-uri

Alegeți pentru fiecare tip ce cookie-uri permiteți. Puteți modifica oricând alegerea prin Setări cookie-uri, în partea de jos a fiecărei pagini. Declarație de confidențialitate

Necesare

Mereu active

Necesare pentru autentificare, pentru păstrarea coșului și pentru a vă reține alegerile. Acestea sunt mereu active.

Ce cookie-uri?
  • weboke_sessie, weboke_klant, weboke_remember: sesiunea și menținerea autentificării
  • weboke_basket: coșul de cumpărături
  • wkBtwIncl: afișarea prețurilor cu sau fără TVA
  • wok_cookies: alegerea privind cookie-urile, 12 luni

Măsoară ce reclamă duce la o vizită sau o comandă, ca să nu plătim pentru reclame care nu aduc nimic.

Ce cookie-uri?
  • Google Ads prin Google Tag Manager (_gcl_au, _gcl_aw), până la 90 de zile
  • OpenAI Ads, reclame în ChatGPT
  • wok_aff: prin ce partener ați ajuns la noi (program de afiliere), 60 de zile

4,6

Țară și limbă

Fiecare țară are propriul site, cu prețurile și TVA-ul pentru țara respectivă.

Vedeți

Când lucrurile merg prost

Modulul 10: Rămâneți în siguranță · Timp de citire: 11 minute

Obiectivul lecției: După această lecție veți recunoaște semnele unui server compromis, veți face primii pași fără a distruge dovezi sau backupuri, veți alege între curățare și reinstalare și veți ști când trebuie să notificați o încălcare a securității datelor.

Noțiuni cheie: incident, semnale, izolare, snapshot ca dovadă, jurnalul incidentului, reinstalare, înlocuirea cheilor și parolelor, backup curat, obligația de notificare a încălcărilor securității datelor (72 de ore), Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP), plan de urgență

Recunoașterea unui incident

O intruziune se anunță rareori. De cele mai multe ori observați ceva "ciudat". Semnale pe care trebuie să le luați în serios:

  • Încărcare mare fără motiv: procesorul este permanent la 100%, de exemplu din cauza unui cryptominer. Verificați cu top sau htop despre ce proces este vorba și sub ce utilizator rulează.
  • Procese sau servicii necunoscute: un program cu un nume ciudat, adesea în /tmp, /dev/shm sau /var/tmp, ori un serviciu sau un timer systemd pe care nu l-ați creat dumneavoastră.
  • Trafic de ieșire care nu se explică: furnizorul vă anunță că serverul dumneavoastră trimite spam sau atacă alte servere, ori graficele de rețea din panou arată vârfuri.
  • Utilizatori sau chei noi: o linie în ~/.ssh/authorized_keys pe care nu o recunoașteți, un utilizator în /etc/passwd cu UID 0, o linie nouă în /etc/sudoers.d/.
  • Fișiere modificate: fișiere PHP necunoscute în site-ul dumneavoastră, un crontab modificat.
  • Jurnale dispărute sau goale: atacatorilor le place să își șteargă urmele.

Câteva comenzi pentru o verificare rapidă:

anna@web1:~$ top -o %CPU
anna@web1:~$ sudo ss -tunap | grep ESTAB
anna@web1:~$ sudo last -n 20
anna@web1:~$ awk -F: '$3 == 0 {print $1}' /etc/passwd
anna@web1:~$ sudo find /etc/systemd/system /etc/cron* -newer /etc/hostname -type f
anna@web1:~$ for u in /root /home/*; do sudo cat $u/.ssh/authorized_keys 2>/dev/null; done

last arată cine s-a autentificat și când, linia cu awk afișează toate conturile cu UID 0 (ar trebui să fie doar root), iar linia cu find caută unități și fișiere cron mai noi decât un fișier creat la instalare.

Atenție: pe un server cu adevărat compromis, chiar și aceste comenzi pot fi falsificate. Ele vă ajută să bănuiți ceva, nu să dovediți că totul este curat.

Primii pași: calm, izolare, documentare

Cel mai important lucru în primele minute este să nu ștergeți lucruri în panică. Lucrați în această ordine.

1. Începeți un jurnal. Notați pe hârtie sau pe laptop (nu pe server) ce observați, când și ce faceți. Veți avea nevoie de aceste note mai târziu pentru a găsi cauza, pentru o notificare, o plângere sau pentru asigurare. NCSC-ul olandez recomandă și el acest lucru.

2. Izolați serverul. Împiedicați-l să facă mai multe pagube (spam, atacuri, trimiterea de date în afară) fără a-l opri:

  • în firewall-ul furnizorului dumneavoastră (dacă există), blocați totul, cu excepția SSH de la propria dumneavoastră adresă; sau
  • faceți același lucru pe serverul însuși, prin consolă;
  • dacă nu există altă cale: opriți serverul din panou. În acest caz pierdeți însă conținutul memoriei.

3. Faceți un snapshot. Un snapshot în panou înregistrează starea serverului așa cum este acum. Acesta este dovada dumneavoastră și sursa din care puteți afla mai târziu cum a intrat atacatorul, chiar dacă reinstalați serverul după aceea.

4. Puneți backupurile la adăpost. Verificați dacă backupurile din afara serverului sunt încă intacte și asigurați-vă că serverul compromis nu mai are acces la ele (de exemplu, revocați cheia de acces a serverului la spațiul de stocare pentru backupuri). Atacatorii încearcă să șteargă sau să cripteze și backupurile.

Curățare sau reinstalare?

Răspunsul tentant este: ștergeți fișierul suspect, opriți cryptominerul și gata. Dar nu știți ce altceva a mai făcut atacatorul: o a doua ușă din spate, un program modificat, o cheie în plus, un timer care readuce totul la loc. Unui server pe care cineva a avut drepturi de root nu mai puteți să îi acordați încredere.

De aceea, sfatul administratorilor și al NCSC-ului olandez este: reinstalați sistemele afectate și restaurați datele dintr-un backup care nu este el însuși infectat. Concret:

  1. O instalare nouă (reinstalare din panou sau un server nou).
  2. Imediat, baza din acest curs: actualizări, un utilizator obișnuit cu sudo, SSH cu chei noi, firewall (modulele 2 până la 5).
  3. Reinstalați aplicațiile din surse oficiale, de preferință cu fișierele compose sau notițele dumneavoastră (lecția 10.4).
  4. Restaurați datele (baza de date, fișierele încărcate) dintr-un backup de dinaintea incidentului. Nu restaurați orbește cod sau configurație: acestea pot conține ușa din spate. Examinați critic și datele restaurate; un atacator poate fi în sistem de mai mult timp decât credeți.
  5. Închideți breșa prin care a intrat atacatorul. Altfel, se va întâmpla din nou. Snapshotul de la pasul 3 vă ajută în investigație.

Înlocuiți tot ce ar fi putut fi divulgat

Porniți de la premisa că tot ce se afla pe server este în mâinile atacatorului:

  • Chei SSH: eliminați de peste tot cheile publice care se aflau pe server și creați perechi noi de chei dacă pe server existau chei private.
  • Parolele bazelor de date, ale panourilor de administrare și ale utilizatorilor aplicației dumneavoastră.
  • Chei API și tokenuri (e-mail, plăți, stocare în cloud, stocare pentru backupuri) din fișierele .env și din configurație: revocați-le la serviciul respectiv și înlocuiți-le.
  • Certificate: cheia privată a certificatului dumneavoastră se afla pe server. Solicitați revocarea certificatului și cereți unul nou (cu Let's Encrypt durează puțin, lecția 7.3).

Notificarea: GDPR și alții

Dacă pe server existau date cu caracter personal (date ale clienților, conturi, adrese de e-mail), este posibil să fie vorba de o încălcare a securității datelor. GDPR (articolul 33) prevede că operatorul notifică încălcarea securității datelor autorității de supraveghere fără întârzieri nejustificate și, dacă este posibil, în termen de 72 de ore de la data la care a luat cunoștință de ea. În România, aceasta este Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP). Câteva puncte esențiale privind notificarea:

  • nu este necesară notificarea dacă este puțin probabil ca încălcarea să genereze un risc pentru persoanele vizate; dacă aveți dubii, notificați;
  • dacă nu aveți încă toate informațiile, notificați totuși în termen de 72 de ore și completați ulterior;
  • persoanele ale căror date au fost divulgate trebuie informate dacă există un risc ridicat pentru ele;
  • orice încălcare a securității datelor se înregistrează într-un registru propriu, chiar dacă nu trebuie notificată.

Dacă administrați serverul pentru un client, de obicei sunteți persoană împuternicită: în acest caz trebuie să informați clientul (operatorul) fără întârzieri nejustificate, astfel încât acesta să poată face notificarea. Această lecție nu constituie consultanță juridică; în caz de dubiu, consultați site-ul ANSPDCP.

În plus: raportați furnizorului abuzurile comise de pe serverul dumneavoastră (adesea le-a observat deja) și, în cazul unui atac grav, depuneți plângere la poliție. Dacă organizația dumneavoastră intră sub incidența Ordonanței de urgență a Guvernului nr. 155/2024 (transpunerea NIS2), aprobată prin Legea nr. 124/2025, se aplică termene de notificare separate și mai scurte.

Pregătirea: planul de urgență

Un incident se produce întotdeauna într-un moment nepotrivit. Ceea ce ați pregătit dinainte vă economisește ore întregi:

  • Să știți cum ajungeți la consola și la butonul de snapshot al furnizorului și să aveți datele de autentificare în panou (cu verificare în doi pași) păstrate undeva în afara serverului.
  • Să știți unde se află backupurile, cum le restaurați și că funcționează (lecția 8.2).
  • Să păstrați o listă cu toate secretele de pe server, ca să știți ce trebuie înlocuit.
  • Să păstrați o listă de contacte: furnizorul, cine altcineva trebuie să afle despre server (client, coleg) și datele de contact pentru notificarea unei încălcări a securității datelor.

În practică

În ecranul VPS din WebOké găsiți consola, snapshoturile, backupurile și butonul de reinstalare; la alți furnizori acestea au denumiri asemănătoare (consolă sau VNC, snapshot, rescue, reinstall). Acest curs este unul de autoinstruire: nimeni nu vă supraveghează serverul și nimeni nu rezolvă un incident în locul dumneavoastră. Tocmai de aceea este atât de important un plan de urgență pe care îl puteți pune în aplicare singur.

Rezumat

  • Semnale: încărcare inexplicabilă, procese, servicii sau chei necunoscute, trafic de ieșire neobișnuit, fișiere și jurnale modificate sau dispărute.
  • Primii pași: țineți un jurnal, izolați serverul, faceți un snapshot ca dovadă, puneți backupurile la adăpost.
  • Un server pe care cineva a avut root nu se curăță, ci se reinstalează; datele se restaurează dintr-un backup curat, iar breșa se închide.
  • Înlocuiți toate cheile, parolele, tokenurile și certificatele care se aflau pe server.
  • Au fost afectate date cu caracter personal? Notificați încălcarea securității datelor către ANSPDCP, dacă este posibil în termen de 72 de ore, și înregistrați fiecare încălcare.

Test (quiz)

1. Descoperiți un proces necunoscut, pornit din /tmp, care folosește de ore întregi 100% din procesor. Ce faceți mai întâi?



2. De ce este reinstalarea mai bună decât curățarea după o intruziune cu drepturi de root?



3. După o intruziune restaurați un backup. Ce anume restaurați?



4. Pe serverul dumneavoastră compromis se aflau datele clienților magazinului online. Ce prevede GDPR privind notificarea?



5. Ce secrete trebuie să înlocuiți după o intruziune?



Exercițiu

Exercițiul O10.3: Planul dvs. de urgență pe o singură pagină. Redactați pentru propriul server un plan de urgență de cel mult o pagină A4: cum ajungeți în panou, la consolă și la snapshoturi; unde se află backupurile și cum le restaurați; ce secrete se află pe server; pe cine trebuie să informați (și dacă trebuie să notificați o încălcare a securității datelor); și care sunt primii cinci pași pe care îi faceți atunci când bănuiți o intruziune. Păstrați planul în afara serverului.

Exercițiul O10.3: Planul dvs. de urgență pe o singură pagină

Acest exercițiu îl faceți singur; nimeni nu îl verifică. Bifați ce ați făcut și marcați exercițiul ca finalizat.





Bifele și notițele dumneavoastră rămân doar în acest browser; nu le trimitem nicăieri. Dacă sunteți autentificat, păstrăm în Cursurile mele doar faptul că ați finalizat exercițiul.

Lecturi suplimentare

Un moment…

Configurați domeniile

Stabiliți pentru fiecare domeniu nameserverele, legătura cu hostingul și cine devine titularul.

Se încarcă domeniile…