Back-upbestanden in de webroot: .zip, .sql en .bak

Kort gezegd: Back-upbestanden in de webroot, dus database-dumps (.sql), archieven (.zip, .tar.gz) en reservekopieën (.bak, .old, ~), kan iedereen downloaden die de bestandsnaam kent of raadt. Zoek zulke bestanden regelmatig met find, verplaats back-ups naar buiten de openbare map, blokkeer typische extensies in de webserver en controleer in de toegangslogboeken of ze al zijn opgehaald.

De back-up die een lek wordt

Vlak voor een update maakt iemand nog snel een back-up: backup.zip in de hoofdmap, ernaast datenbank.sql. De update slaagt, de bestanden blijven staan. Maanden later zijn ze er nog steeds, met de volledige code, alle klantgegevens en de toegangsgegevens van de website.

Dit patroon behoort tot de meest voorkomende bevindingen bij controles van webservers. Er is geen exploit voor nodig en geen kwetsbaarheid in PHP. Een webserver levert uit de webroot uit wat daar staat en archieven of SQL-bestanden voert hij niet uit, maar biedt hij aan om te downloaden.

Een archief van de website bevat daarbij niet alleen gegevens, maar ook de code inclusief configuratie. Wie het downloadt, kan rustig naar zwakke plekken zoeken en kent de toegangsgegevens voor de database.

Geautomatiseerde scanners zoeken gericht naar typische namen zoals backup.zip, site.tar.gz of dump.sql, vaak gecombineerd met de domeinnaam of een datum. Wie denkt dat een ongebruikelijke bestandsnaam beschermt, onderschat hoe systematisch deze zoektocht verloopt.

Welke bestanden bedoeld zijn

Back-upbestanden in de webroot komen in meerdere vormen voor:

Bijzonder gevoelig zijn kopieën van configuratiebestanden. Het originele bestand config.php voert de server uit, de inhoud blijft verborgen. De kopie config.php.bak levert hij als tekst uit, inclusief databasewachtwoord.

Back-ups in de webroot vinden: zoeken op de server

De volgende zoekopdracht toont verdachte bestanden onder de webroots met datum en grootte. Pas de paden aan uw server aan:

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

Niet elke treffer is een probleem. Sommige archieven worden bewust voor download aangeboden, bijvoorbeeld handleidingen. Elk bestand verdient echter een bewuste beslissing. Let vooral op grote bestanden en op mappen van back-upplug-ins. Bij shared hosting zonder shelltoegang helpt het bestandsoverzicht in het hostingpaneel of een opvraging via SFTP.

Is het bestand al gedownload?

Het antwoord staat in de toegangslogboeken van de webserver. Gezocht wordt naar geslaagde opvragingen, dus status 200, van de gevonden bestanden:

# Geslaagde opvragingen van typische back-upextensies (combined-logformaat)
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}'

De uitvoer toont tijdstip, adres, pad en grootte van het antwoord. Komt de overgedragen grootte overeen met de bestandsgrootte, dan is het bestand volledig geladen. Hoe ver logboeken teruggaan, hangt af van de rotatie. Reiken ze niet tot de aanmaakdatum van het bestand, dan kan een eerdere opvraging niet worden uitgesloten. Uitvoerig beschrijft dat Weblogboeken na een aanval beoordelen. Zonder toegang tot de ruwe logboeken, bijvoorbeeld bij shared hosting, vraagt u de hostingprovider om de logboeken voor de betreffende periode.

Is een dump met persoonsgegevens opgehaald of valt dat niet uit te sluiten, dan begint de beoordeling van een meldplicht. De basis vat AVG-meldplicht: 72 uur na het incident samen; de beoordeling in het concrete geval hoort bij uw functionaris voor gegevensbescherming. Toegangsgegevens uit opgehaalde bestanden vervangt u in elk geval.

Back-upplug-ins, panelen en verhuizingen

Veel vondsten zijn terug te voeren op back-upplug-ins van CMS en webshops. Ze plaatsen back-ups vaak in een submap van de webroot, deels met namen uit datum en domein die te raden zijn. Controleer in elke plug-in drie instellingen: waarheen wordt een back-up gemaakt? Worden lokale kopieën na het uploaden naar een extern doel verwijderd? Is de lokale map beschermd tegen rechtstreekse opvraging?

Back-ups uit hostingpanelen staan in de regel buiten de webroot, bijvoorbeeld in de homedirectory. Problematisch wordt het als iemand zo'n back-up naar de webroot kopieert, omdat downloaden in de browser handiger is dan via SFTP. Voor verhuizingen geldt daarom: overdracht via SFTP of rechtstreeks tussen de servers, nooit via een openbare link.

Verzorgen bureaus of dienstverleners uw websites, dan moet deze regel ook in het contract staan, inclusief de plicht tot opruimen na onderhoudswerk. Aanwijzingen geeft Contracten met IT-dienstverleners: beveiligingsplichten helder regelen.

Blijvend voorkomen: opslaglocatie en blokkades

Om te voorkomen dat het probleem terugkeert, zijn twee niveaus nodig. Het eerste is organisatorisch: back-ups hebben een vaste plek buiten de webroot en bovendien buiten de server. Hoe een betrouwbare back-up eruitziet, beschrijft de gids Back-ups volgens de 3-2-1-regel.

Het tweede niveau is technisch: de webserver weigert typische back-upextensies principieel, ook als er toch eens een bestand blijft liggen.

location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
    return 404;
}
location ~ ~$ {
    return 404;
}

Archieven zoals .zip blokkeert u alleen als uw website geen downloads in dit formaat aanbiedt, of gericht in de mappen waarin geen downloads staan. Aanvullend helpen een regelmatige automatische zoekactie met melding en een korte regel in het team: geen back-ups en kopieën in de webroot, ook niet voor vijf minuten. Verwante gevallen zoals verborgen configuratiebestanden behandelt Toegangsgegevens en .env-bestanden correct beveiligen.

Hoe helpt PHP SOS concreet?

• Wij doorzoeken uw webroots op dumps, archieven, kopieën en plug-inback-ups en beoordelen elke vondst.
• Wij controleren aan de hand van de toegangslogboeken of bestanden zijn opgehaald en documenteren het resultaat voor uw beoordeling inzake gegevensbescherming.
• Wij richten blokkades in de webserver en een regelmatige automatische zoekactie in.
• Wij verplaatsen back-ups naar een beschermde plek buiten de webroot.

Deze werkzaamheden zijn onderdeel van onze serverhardening voor PHP-webservers.

Veelgestelde vragen

Bronnen

• OWASP Top 10
• AVG art. 33: melding aan de toezichthoudende autoriteit
• Nginx-documentatie