Pe scurt: Fișierele de backup din webroot, adică dump-urile de baze de date (.sql), arhivele (.zip, .tar.gz) și copiile de siguranță (.bak, .old, ~), le poate descărca oricine cunoaște sau ghicește numele fișierului. Căutați regulat asemenea fișiere cu find, mutați copiile de siguranță în afara directorului public, blocați în serverul web extensiile tipice și verificați în jurnalele de acces dacă au fost deja accesate.
Backup-ul care devine scurgere
Chiar înainte de o actualizare, cineva face repede o copie de siguranță: backup.zip în directorul principal, alături datenbank.sql. Actualizarea reușește, fișierele rămân acolo. Luni mai târziu sunt tot acolo, cu întregul cod, toate datele clienților și datele de acces ale site-ului.
Acest tipar se numără printre cele mai frecvente constatări la verificările serverelor web. Nu are nevoie de un exploit și nici de o vulnerabilitate în PHP. Un server web livrează din webroot ce se află acolo, iar arhivele sau fișierele SQL nu le execută, ci le oferă la descărcare.
O arhivă a site-ului conține nu doar date, ci și codul împreună cu configurarea. Cine o descarcă poate căuta în liniște vulnerabilități și cunoaște datele de acces la baza de date.
Scannerele automate caută țintit nume tipice precum backup.zip, site.tar.gz sau dump.sql, adesea combinate cu numele domeniului sau cu o dată. Cine crede că un nume de fișier neobișnuit protejează subestimează cât de sistematic decurge această căutare.
Ce fișiere sunt vizate
Fișierele de backup din webroot apar în mai multe forme:
| Tip | Extensii tipice | Ce conțin |
|---|---|---|
| Dump-uri de baze de date | .sql, .sql.gz, .dump |
Date ale clienților, comenzi, hash-uri de parole, setări |
| Arhive ale site-ului | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
Întreg codul, configurarea, upload-uri |
| Copii ale unor fișiere individuale | .bak, .old, .orig, .save, .php~, .copy |
Adesea fișiere de configurare cu date de acces |
| Resturi de editor | .swp, .swo, ~ la sfârșit |
Părți din fișiere editate chiar atunci |
| Copii de siguranță ale pluginurilor | Subdirectoare proprii în CMS | Copii de siguranță complete, uneori cu nume ghicibile |
Deosebit de delicate sunt copiile fișierelor de configurare. Fișierul original config.php este executat de server, iar conținutul său rămâne ascuns. Copia config.php.bak este livrată ca text, împreună cu parola bazei de date.
Găsirea backup-urilor din webroot: căutarea pe server
Căutarea următoare listează fișierele suspecte de sub webroot-uri, cu dată și dimensiune. Adaptați căile la serverul dumneavoastră:
find /var/www /srv/www -type f \( \
-iname '*.sql' -o -iname '*.sql.gz' -o -iname '*.dump' -o \
-iname '*.zip' -o -iname '*.tar' -o -iname '*.tar.gz' -o -iname '*.tgz' -o \
-iname '*.rar' -o -iname '*.7z' -o \
-iname '*.bak' -o -iname '*.old' -o -iname '*.orig' -o -iname '*.save' -o \
-iname '*~' -o -iname '*.swp' \) \
-printf '%TY-%Tm-%Td %10s %p\n' 2>/dev/null | sort
Nu fiecare rezultat este o problemă. Unele arhive sunt puse intenționat la dispoziție pentru descărcare, de exemplu manuale. Fiecare fișier merită însă o decizie conștientă. Fiți atenți în special la fișierele mari și la directoarele pluginurilor de backup. La shared hosting fără acces shell ajută prezentarea fișierelor din panoul de hosting sau o interogare prin SFTP.
Dacă găsiți în webroot un dump de bază de date cu date ale clienților, mutați-l imediat din directorul public și salvați jurnalele de acces înainte ca acestea să fie rotite. Abia apoi clarificați dacă fișierul a fost accesat.
A fost fișierul deja descărcat?
Răspunsul se află în jurnalele de acces ale serverului web. Se caută accesările reușite, adică status 200, la fișierele găsite:
# Accesări reușite ale extensiilor tipice de backup (format de jurnal Combined)
zgrep -hE '\.(sql|sql\.gz|zip|tar|tgz|gz|bak|old|7z|rar)[ ?]' /var/log/nginx/access.log* \
| awk '$9 == 200 {print $4, $1, $7, $10}'
Ieșirea arată momentul, adresa, calea și dimensiunea răspunsului. Dacă dimensiunea transferată corespunde dimensiunii fișierului, fișierul a fost încărcat integral. Cât de departe în timp ajung jurnalele depinde de rotație. Dacă nu ajung până la data creării fișierului, o accesare anterioară nu poate fi exclusă. Detaliat descrie acest lucru Analiza jurnalelor serverului web după un atac. Fără acces la jurnalele brute, de exemplu la shared hosting, cereți furnizorului de hosting jurnalele pentru perioada respectivă.
Dacă a fost accesat un dump cu date cu caracter personal sau acest lucru nu poate fi exclus, începe verificarea unei obligații de notificare. Bazele le rezumă Obligația de notificare RGPD: 72 de ore după incident; evaluarea în cazul individual aparține responsabilului dumneavoastră cu protecția datelor. Datele de acces din fișierele accesate le înlocuiți în orice caz.
Pluginuri de backup, panouri și mutări
Multe descoperiri provin de la pluginuri de backup ale CMS-urilor și magazinelor. Ele depun adesea copiile într-un subdirector al webroot-ului, uneori cu nume formate din dată și domeniu, care pot fi ghicite. Verificați în fiecare plugin trei setări: Unde se face copia? Sunt șterse copiile locale după încărcarea către o țintă externă? Este directorul local protejat împotriva accesului direct?
Copiile de siguranță din panourile de hosting se află de regulă în afara webroot-ului, de exemplu în directorul home. Devine problematic când cineva copiază o asemenea copie în webroot, pentru că descărcarea în browser este mai comodă decât prin SFTP. Pentru mutări se aplică de aceea: transfer prin SFTP sau direct între servere, niciodată printr-un link public.
Dacă agenții sau furnizori de servicii se ocupă de site-urile dumneavoastră, această regulă ar trebui să figureze și în contract, împreună cu obligația de a face ordine după lucrările de mentenanță. Indicații oferă Contracte cu furnizorii IT: reglementarea clară a obligațiilor de securitate.
Prevenire durabilă: loc de stocare și blocări
Pentru ca problema să nu se repete, sunt necesare două niveluri. Primul este organizatoric: copiile de siguranță au un loc fix în afara webroot-ului și, în plus, în afara serverului. Cum arată o copie de siguranță rezistentă descrie ghidul Backup-uri după regula 3-2-1.
Al doilea nivel este tehnic: serverul web refuză în principiu extensiile tipice de backup, chiar dacă totuși rămâne un fișier acolo.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Arhivele precum .zip le blocați doar dacă site-ul dumneavoastră nu oferă descărcări în acest format, sau țintit în directoarele în care nu se află descărcări. Ajută complementar o căutare automată regulată cu notificare și o scurtă regulă în echipă: fără copii de siguranță și copii în webroot, nici pentru cinci minute. Cazuri înrudite, precum fișierele de configurare ascunse, tratează Protejarea corectă a datelor de acces și a fișierelor .env.
Cum ajută PHP SOS concret?
- Căutăm în webroot-urile dumneavoastră dump-uri, arhive, copii și copii de siguranță ale pluginurilor și evaluăm fiecare descoperire.
- Verificăm pe baza jurnalelor de acces dacă fișierele au fost accesate și documentăm rezultatul pentru evaluarea dumneavoastră privind protecția datelor.
- Configurăm blocări în serverul web și o căutare automată regulată.
- Mutăm copiile de siguranță într-un loc protejat, în afara webroot-ului.
Aceste lucrări fac parte din întărirea serverului pentru servere web PHP oferită de noi.
Întrebări frecvente
De ce ajung backup-urile, de fapt, în webroot?
De obicei din comoditate: un dump este generat pentru o mutare, un plugin depune copii de siguranță în propriul director sau, înainte de o modificare, se face repede o copie a unui fișier cu extensia .bak. Apoi fișierul este uitat.
Cât de periculos este un fișier precum config.php.bak?
Foarte. Un fișier cu extensia .php este executat de server, iar conținutul său rămâne ascuns. O copie cu altă extensie este livrată în schimb de server, de regulă, ca text, împreună cu parola bazei de date și cheile.
Este un dump de bază de date accesibil public o breșă de date?
Dacă conține date cu caracter personal și a fost accesat sau o accesare nu poate fi exclusă, intră în discuție o obligație de notificare conform RGPD. Evaluarea în cazul individual o preiau responsabilul dumneavoastră cu protecția datelor sau consilierea juridică.
Unde ar trebui să se afle backup-urile în schimb?
În afara webroot-ului și, în plus, în afara serverului, conform regulii 3-2-1. Cel puțin o copie ar trebui stocată astfel încât serverul web însuși să nu o poată șterge sau modifica.