Kort sagt: Backupfiler i webbroten, alltså databasdumpar (.sql), arkiv (.zip, .tar.gz) och säkerhetskopior (.bak, .old, ~), kan vem som helst ladda ned som känner till eller gissar filnamnet. Sök regelbundet efter sådana filer med find, flytta säkerhetskopior utanför den offentliga katalogen, spärra typiska ändelser i webbservern och kontrollera i åtkomstloggarna om de redan har hämtats.
Backupen som blir ett läckage
Strax före en uppdatering skapar någon snabbt en säkerhetskopia: backup.zip i huvudkatalogen, bredvid datenbank.sql. Uppdateringen lyckas, filerna blir liggande. Månader senare finns de kvar, med hela koden, alla kunddata och webbplatsens inloggningsuppgifter.
Det här mönstret hör till de vanligaste fynden vid granskning av webbservrar. Det behövs ingen exploit och ingen sårbarhet i PHP. En webbserver levererar ur webbroten det som ligger där, och arkiv eller SQL-filer kör den inte utan erbjuder dem för nedladdning.
Ett arkiv av webbplatsen innehåller dessutom inte bara data utan också koden inklusive konfiguration. Den som laddar ned det kan i lugn och ro söka efter svagheter och känner till inloggningsuppgifterna till databasen.
Automatiserade skannrar söker målinriktat efter typiska namn som backup.zip, site.tar.gz eller dump.sql, ofta kombinerade med domännamnet eller ett datum. Den som tror att ett ovanligt filnamn skyddar underskattar hur systematiskt den sökningen sker.
Vilka filer som avses
Backupfiler i webbroten förekommer i flera former:
| Typ | Typiska ändelser | Vad som döljer sig i dem |
|---|---|---|
| Databasdumpar | .sql, .sql.gz, .dump |
Kunddata, beställningar, lösenordshashar, inställningar |
| Arkiv av webbplatsen | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
hela koden, konfiguration, uppladdningar |
| Kopior av enskilda filer | .bak, .old, .orig, .save, .php~, .copy |
ofta konfigurationsfiler med inloggningsuppgifter |
| Editorrester | .swp, .swo, ~ i slutet |
delar av filer som just redigeras |
| Tilläggs-säkerhetskopior | egna undermappar i CMS:et | kompletta säkerhetskopior, delvis med gissningsbara namn |
Särskilt känsliga är kopior av konfigurationsfiler. Originalfilen config.php kör servern, och dess innehåll förblir dolt. Kopian config.php.bak levererar den som text, med databaslösenord.
Hitta backuper i webbroten: sökning på servern
Följande sökning listar misstänkta filer under webbrötterna med datum och storlek. Anpassa sökvägarna till er 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
Inte varje träff är ett problem. Vissa arkiv är medvetet tillgängliga för nedladdning, till exempel handböcker. Men varje fil förtjänar ett medvetet beslut. Se särskilt upp med stora filer och med mappar för backuptillägg. På delat webbhotell utan skalåtkomst hjälper filöversikten i webbhotellspanelen eller ett anrop via SFTP.
Hittar ni en databasdump med kunddata i webbroten, flytta den omedelbart ut ur den offentliga katalogen och säkra åtkomstloggarna innan de roteras. Först därefter klargör ni om filen har hämtats.
Har filen redan laddats ned?
Svaret står i webbserverns åtkomstloggar. Det som eftersöks är lyckade hämtningar, alltså status 200, av de funna filerna:
# Lyckade hämtningar av typiska backupändelser (Combined-loggformat)
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}'
Utdata visar tidpunkt, adress, sökväg och svarets storlek. Motsvarar den överförda storleken filstorleken har filen laddats ned fullständigt. Hur långt tillbaka loggarna räcker beror på roteringen. Räcker de inte till filens skapandedatum går en tidigare hämtning inte att utesluta. Utförligt beskriver det Utvärdera webbserverloggar efter ett angrepp. Utan åtkomst till råloggarna, till exempel på delat webbhotell, frågar ni webbhotellet efter loggarna för den aktuella tidsperioden.
Har en dump med personuppgifter hämtats, eller kan det inte uteslutas, börjar kontrollen av en anmälningsskyldighet. Grunderna sammanfattar GDPR-anmälan inom 72 timmar efter incidenten; bedömningen i det enskilda fallet hör till ert dataskyddsombud. Inloggningsuppgifter från hämtade filer byter ni under alla omständigheter ut.
Backuptillägg, paneler och flyttar
Många fynd går tillbaka på backuptillägg för CMS och butiker. De lägger ofta säkerhetskopior i en undermapp i webbroten, delvis med namn av datum och domän som går att gissa. Kontrollera tre inställningar i varje tillägg: Vart säkerhetskopieras det? Raderas lokala kopior efter uppladdning till ett externt mål? Är den lokala mappen skyddad mot direkt hämtning?
Säkerhetskopior från webbhotellspaneler ligger i regel utanför webbroten, till exempel i hemkatalogen. Problem uppstår när någon kopierar en sådan säkerhetskopia till webbroten för att nedladdningen i webbläsaren är bekvämare än via SFTP. För flyttar gäller därför: Överföring via SFTP eller direkt mellan servrarna, aldrig via en offentlig länk.
Sköter byråer eller tjänsteleverantörer era webbplatser bör den regeln också stå i avtalet, tillsammans med skyldighet att städa efter underhållsarbeten. Anvisningar ger IT-leverantörsavtal: reglera säkerhetsskyldigheter tydligt.
Förebygg varaktigt: lagringsplats och spärrar
För att problemet inte ska upprepas behövs två nivåer. Den första är organisatorisk: Säkerhetskopior har en fast plats utanför webbroten och dessutom utanför servern. Hur en hållbar säkerhetskopia ser ut beskriver guiden Backuper enligt 3-2-1-regeln.
Den andra nivån är teknisk: Webbservern nekar i princip typiska backupändelser, även om en fil ändå skulle bli liggande.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Arkiv som .zip spärrar ni bara om er webbplats inte erbjuder nedladdningar i det formatet, eller målinriktat i de kataloger där inga nedladdningar ligger. Som komplement hjälper en regelbunden automatisk sökning med avisering och en kort regel i teamet: Inga säkerhetskopior och kopior i webbroten, inte ens i fem minuter. Närliggande fall som dolda konfigurationsfiler behandlar Skydda inloggningsuppgifter och .env-filer rätt.
Hur hjälper PHP SOS konkret?
- Vi söker igenom era webbrötter efter dumpar, arkiv, kopior och tilläggs-säkerhetskopior och bedömer varje fynd.
- Vi kontrollerar med hjälp av åtkomstloggarna om filer har hämtats och dokumenterar resultatet för er dataskyddsbedömning.
- Vi inrättar spärrar i webbservern och en regelbunden automatisk sökning.
- Vi flyttar säkerhetskopior till en skyddad plats utanför webbroten.
Dessa arbeten är en del av vår serverhärdning för PHP-webbservrar.
Vanliga frågor
Varför hamnar backuper över huvud taget i webbroten?
Oftast av bekvämlighet: En dump skapas för en flytt, ett tillägg lägger säkerhetskopior i sin egen mapp, eller före en ändring skapas snabbt en kopia av en fil med ändelsen .bak. Därefter faller filen i glömska.
Hur farlig är en fil som config.php.bak?
Mycket. En fil med ändelsen .php körs av servern, och innehållet förblir dolt. En kopia med annan ändelse levererar servern däremot oftast som text, med databaslösenord och nycklar.
Är en offentligt hämtbar databasdump en dataincident?
Om den innehåller personuppgifter och har hämtats, eller om ett hämtande inte kan uteslutas, kan anmälningsskyldighet enligt GDPR bli aktuell. Bedömningen i det enskilda fallet gör ert dataskyddsombud eller er juridiska rådgivning.
Var bör backuper ligga i stället?
Utanför webbroten och dessutom utanför servern, enligt 3-2-1-regeln. Minst en kopia bör vara lagrad så att webbservern själv inte kan radera eller ändra den.