Kort sagt: Backupfiler i webroot, altså database-dumps (.sql), arkiver (.zip, .tar.gz) og sikkerhedskopier (.bak, .old, ~), kan enhver downloade, der kender eller gætter filnavnet. Søg jævnligt efter sådanne filer med find, flyt sikkerhedskopier ud af den offentlige mappe, spær typiske endelser i webserveren, og kontrollér i adgangsloggene, om de allerede er blevet hentet.
Backuppen, der bliver til et læk
Lige før en opdatering laver nogen hurtigt en sikkerhedskopi: backup.zip i hovedmappen, ved siden af datenbank.sql. Opdateringen lykkes, filerne bliver liggende. Måneder senere er de der stadig, med hele koden, alle kundedata og websitets adgangsdata.
Dette mønster hører til de hyppigste fund ved kontrol af webservere. Det kræver ingen exploit og ingen sårbarhed i PHP. En webserver leverer fra webroot det, der ligger dér, og arkiver eller SQL-filer udfører den ikke, men tilbyder dem til download.
Et arkiv af websitet indeholder dertil ikke kun data, men også koden inklusive konfiguration. Den, der downloader det, kan i ro og mag søge efter sårbarheder og kender adgangsdata til databasen.
Automatiserede scannere søger målrettet efter typiske navne som backup.zip, site.tar.gz eller dump.sql, ofte kombineret med domænenavnet eller en dato. Den, der tror, at et usædvanligt filnavn beskytter, undervurderer, hvor systematisk denne søgning kører.
Hvilke filer der er tale om
Backupfiler i webroot optræder i flere former:
| Art | Typiske endelser | Hvad der gemmer sig i dem |
|---|---|---|
| Database-dumps | .sql, .sql.gz, .dump |
Kundedata, ordrer, adgangskode-hashes, indstillinger |
| Arkiver af websitet | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
hele koden, konfiguration, uploads |
| Kopier af enkelte filer | .bak, .old, .orig, .save, .php~, .copy |
ofte konfigurationsfiler med adgangsdata |
| Editor-rester | .swp, .swo, ~ til sidst |
dele af filer, der netop redigeres |
| Plugin-sikkerhedskopier | egne undermapper i CMS'et | fuldstændige sikkerhedskopier, til dels med navne, der kan gættes |
Særligt kildent er kopier af konfigurationsfiler. Originalfilen config.php udfører serveren, dens indhold forbliver skjult. Kopien config.php.bak leverer den som tekst, inklusive databaseadgangskode.
Find backup i webroot: Søgning på serveren
Følgende søgning lister mistænkelige filer under webroots med dato og størrelse. Tilpas stierne til jeres server:
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
Ikke ethvert fund er et problem. Nogle arkiver er bevidst stillet til rådighed til download, f.eks. manualer. Hver fil fortjener dog en bevidst beslutning. Vær især opmærksom på store filer og på mapper fra backup-plugins. Ved shared hosting uden shell-adgang hjælper filoversigten i hostingpanelet eller en hentning via SFTP.
Finder I en database-dump med kundedata i webroot, flytter I den straks ud af den offentlige mappe og sikrer adgangsloggene, før de roteres. Først derefter afklarer I, om filen blev hentet.
Er filen allerede blevet downloadet?
Svaret står i webserverens adgangslogge. Der søges efter vellykkede hentninger, altså status 200, af de fundne filer:
# Vellykkede hentninger af typiske backup-endelser (Combined-logformat)
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}'
Outputtet viser tidspunkt, adresse, sti og svarets størrelse. Svarer den overførte størrelse til filstørrelsen, blev filen hentet fuldstændigt. Hvor langt logge rækker tilbage, afhænger af rotationen. Rækker de ikke tilbage til filens oprettelsesdato, kan en tidligere hentning ikke udelukkes. Udførligt beskriver det Analysér webserver-logs efter et angreb. Uden adgang til de rå logge, f.eks. ved shared hosting, spørger I hos hostingudbyderen efter logge for det pågældende tidsrum.
Blev en dump med personoplysninger hentet, eller kan det ikke udelukkes, begynder vurderingen af en anmeldelsespligt. Grundlaget sammenfatter GDPR-anmeldelsespligt: 72 timer efter hændelsen; vurderingen i det enkelte tilfælde hører til hos jeres databeskyttelsesrådgiver. Adgangsdata fra hentede filer udskifter I under alle omstændigheder.
Backup-plugins, paneler og flytninger
Mange fund skyldes backup-plugins til CMS'er og shops. De lægger ofte sikkerhedskopier i en undermappe i webroot, til dels med navne bestående af dato og domæne, som kan gættes. Kontrollér i hvert plugin tre indstillinger: Hvortil sikres der? Slettes lokale kopier efter upload til et eksternt mål? Er den lokale mappe beskyttet mod direkte hentning?
Sikkerhedskopier fra hostingpaneler ligger som regel uden for webroot, f.eks. i hjemmemappen. Det bliver problematisk, når nogen kopierer en sådan sikkerhedskopi ind i webroot, fordi download i browseren er mere bekvem end via SFTP. Ved flytninger gælder derfor: Overførsel via SFTP eller direkte mellem serverne, aldrig via et offentligt link.
Betjener bureauer eller tjenesteudbydere jeres websites, bør denne regel også stå i kontrakten, sammen med pligten til at rydde op efter vedligeholdelsesarbejde. Henvisninger giver IT-tjenesteudbyderkontrakter: Fastlæg sikkerhedspligter klart.
Forebyg varigt: Opbevaringssted og spærringer
For at problemet ikke gentager sig, kræves to niveauer. Det første er organisatorisk: Sikkerhedskopier har et fast sted uden for webroot og desuden uden for serveren. Hvordan en holdbar sikkerhedskopi ser ud, beskriver vejledningen Backups efter 3-2-1-reglen.
Det andet niveau er teknisk: Webserveren nægter som udgangspunkt typiske backup-endelser, selv om der alligevel engang bliver en fil liggende.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Arkiver som .zip spærrer I kun, hvis jeres website ikke tilbyder downloads i dette format, eller målrettet i de mapper, hvor der ikke ligger downloads. Supplerende hjælper en regelmæssig automatisk søgning med underretning og en kort regel i teamet: Ingen sikkerhedskopier og kopier i webroot, heller ikke i fem minutter. Beslægtede tilfælde som skjulte konfigurationsfiler behandler Beskyt adgangsdata og .env-filer rigtigt.
Hvordan hjælper PHP SOS konkret?
- Vi gennemsøger jeres webroots efter dumps, arkiver, kopier og plugin-sikkerhedskopier og vurderer hvert fund.
- Vi kontrollerer ud fra adgangsloggene, om filer blev hentet, og dokumenterer resultatet til jeres databeskyttelsesvurdering.
- Vi indretter spærringer i webserveren og en regelmæssig automatisk søgning.
- Vi flytter sikkerhedskopier til et beskyttet sted uden for webroot.
Disse arbejder er en del af vores serverhærdning til PHP-webservere.
Ofte stillede spørgsmål
Hvorfor havner backups overhovedet i webroot?
Oftest af bekvemmelighed: En dump oprettes til en flytning, et plugin lægger sikkerhedskopier i sin egen mappe, eller der laves hurtigt en kopi af en fil med endelsen .bak før en ændring. Bagefter glemmes filen.
Hvor farlig er en fil som config.php.bak?
Meget. En fil med endelsen .php udføres af serveren, og dens indhold forbliver skjult. En kopi med en anden endelse leverer serveren derimod som regel som tekst, inklusive databaseadgangskode og nøgler.
Er en offentligt tilgængelig database-dump et databrud?
Hvis den indeholder personoplysninger og blev hentet, eller hvis en hentning ikke kan udelukkes, kommer en anmeldelsespligt efter GDPR i betragtning. Vurderingen i det enkelte tilfælde overtager jeres databeskyttelsesrådgiver eller juridiske rådgiver.
Hvor bør backups ligge i stedet?
Uden for webroot og desuden uden for serveren, efter 3-2-1-reglen. Mindst én kopi bør være gemt, så webserveren selv hverken kan slette eller ændre den.