In breve: i file di backup nel webroot, cioè dump del database (.sql), archivi (.zip, .tar.gz) e copie di sicurezza (.bak, .old, ~), possono essere scaricati da chiunque conosca o indovini il nome del file. Cerchi regolarmente tali file con find, sposti le copie di sicurezza fuori dalla directory pubblica, blocchi nel server web le estensioni tipiche e verifichi nei log di accesso se sono già stati richiamati.
Il backup che diventa una fuga
Poco prima di un aggiornamento qualcuno crea in fretta una copia di sicurezza: backup.zip nella directory principale, accanto datenbank.sql. L'aggiornamento riesce, i file restano lì. Mesi dopo sono ancora presenti, con tutto il codice, tutti i dati dei clienti e le credenziali del sito.
Questo schema è tra i rilievi più frequenti nelle verifiche dei server web. Non serve alcun exploit né vulnerabilità di PHP. Un server web fornisce dal webroot ciò che vi si trova e non esegue archivi o file SQL, ma li offre in download.
Un archivio del sito non contiene solo dati, ma anche il codice con la configurazione. Chi lo scarica può cercare con calma le vulnerabilità e conosce le credenziali del database.
Scanner automatizzati cercano in modo mirato nomi tipici come backup.zip, site.tar.gz o dump.sql, spesso combinati con il nome del dominio o una data. Chi crede che un nome di file insolito protegga sottovaluta quanto sistematica sia questa ricerca.
Quali file sono interessati
I file di backup nel webroot si presentano in più forme:
| Tipo | Estensioni tipiche | Che cosa contengono |
|---|---|---|
| Dump del database | .sql, .sql.gz, .dump |
Dati dei clienti, ordini, hash delle password, impostazioni |
| Archivi del sito | .zip, .tar, .tar.gz, .tgz, .rar, .7z |
Tutto il codice, configurazione, upload |
| Copie di singoli file | .bak, .old, .orig, .save, .php~, .copy |
Spesso file di configurazione con credenziali |
| Residui degli editor | .swp, .swo, ~ alla fine |
Parti di file in modifica |
| Copie di sicurezza dei plugin | Sottocartelle proprie nel CMS | Copie complete, in parte con nomi indovinabili |
Particolarmente delicate sono le copie dei file di configurazione. Il file originale config.php viene eseguito dal server e il suo contenuto resta nascosto. La copia config.php.bak il server la fornisce come testo, con la password del database.
Trovare i backup nel webroot: ricerca sul server
La ricerca seguente elenca i file sospetti sotto i webroot con data e dimensione. Adatti i percorsi al suo 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
Non ogni risultato è un problema. Alcuni archivi sono messi a disposizione di proposito per il download, ad esempio i manuali. Ogni file merita però una decisione consapevole. Faccia particolare attenzione ai file grandi e alle cartelle dei plugin di backup. Con lo shared hosting senza accesso alla shell aiutano la panoramica dei file nel pannello di hosting o un accesso via SFTP.
Se trova nel webroot un dump del database con dati dei clienti, lo sposti subito fuori dalla directory pubblica e metta al sicuro i log di accesso prima che vengano ruotati. Solo dopo chiarisca se il file sia stato richiamato.
Il file è già stato scaricato?
La risposta si trova nei log di accesso del server web. Si cercano richiami riusciti, cioè con stato 200, ai file trovati:
# Richiami riusciti delle estensioni di backup tipiche (formato di log 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}'
L'output mostra momento, indirizzo, percorso e dimensione della risposta. Se la dimensione trasmessa corrisponde a quella del file, il file è stato scaricato per intero. Fin dove arrivino indietro i log dipende dalla rotazione. Se non arrivano fino alla data di creazione del file, un richiamo precedente non si può escludere. Lo descrive in dettaglio Analizzare i log del server web dopo un attacco. Senza accesso ai log grezzi, ad esempio nello shared hosting, chieda all'hoster i log per il periodo in questione.
Se è stato richiamato un dump con dati personali, o non si può escluderlo, inizia la verifica di un obbligo di notifica. I fondamenti li riassume Obbligo di notifica GDPR: 72 ore dopo l'incidente; la valutazione nel singolo caso spetta al suo responsabile della protezione dei dati. Le credenziali dei file richiamati le sostituisca in ogni caso.
Plugin di backup, pannelli e traslochi
Molti ritrovamenti derivano dai plugin di backup di CMS e shop. Spesso depositano le copie in una sottocartella del webroot, in parte con nomi composti da data e dominio che si possono indovinare. Verifichi in ogni plugin tre impostazioni: dove si salva? Le copie locali vengono cancellate dopo il caricamento verso una destinazione esterna? La cartella locale è protetta dal richiamo diretto?
Le copie dei pannelli di hosting di norma stanno fuori dal webroot, ad esempio nella directory home. Diventa problematico quando qualcuno copia una di queste copie nel webroot perché il download nel browser è più comodo che via SFTP. Per i traslochi vale quindi: trasferimento via SFTP o direttamente tra i server, mai tramite un link pubblico.
Se agenzie o fornitori di servizi curano i suoi siti, questa regola dovrebbe figurare anche nel contratto, con l'obbligo di fare pulizia dopo i lavori di manutenzione. Indicazioni le dà Contratti con i fornitori IT: regolare con chiarezza gli obblighi di sicurezza.
Prevenire in modo duraturo: luogo di archiviazione e blocchi
Perché il problema non si ripeta servono due livelli. Il primo è organizzativo: le copie di sicurezza hanno un luogo fisso fuori dal webroot e inoltre fuori dal server. Come sia fatta una copia di sicurezza affidabile lo descrive la guida Backup secondo la regola 3-2-1.
Il secondo livello è tecnico: il server web rifiuta in via di principio le estensioni di backup tipiche, anche se una volta un file dovesse rimanere lì.
location ~* \.(sql|sql\.gz|dump|bak|old|orig|save|swp|swo)$ {
return 404;
}
location ~ ~$ {
return 404;
}
Archivi come .zip li blocchi solo se il suo sito non offre download in questo formato, oppure in modo mirato nelle directory in cui non ci sono download. Aiutano inoltre una ricerca automatica regolare con notifica e una breve regola nel team: nessuna copia di sicurezza o copia di file nel webroot, nemmeno per cinque minuti. Casi affini come i file di configurazione nascosti li tratta Proteggere correttamente credenziali e file .env.
Come aiuta concretamente PHP SOS?
- Cerchiamo nei suoi webroot dump, archivi, copie e backup dei plugin e valutiamo ogni ritrovamento.
- Verifichiamo in base ai log di accesso se i file sono stati richiamati e documentiamo il risultato per la sua valutazione sulla protezione dei dati.
- Impostiamo blocchi nel server web e una ricerca automatica regolare.
- Spostiamo le copie di sicurezza in un luogo protetto fuori dal webroot.
Questi lavori fanno parte del nostro hardening del server per server web PHP.
Domande frequenti
Perché i backup finiscono nel webroot, in fondo?
Di solito per comodità: si genera un dump per un trasloco, un plugin deposita copie di sicurezza nella propria cartella, oppure prima di una modifica si crea in fretta una copia di un file con l'estensione .bak. Poi il file cade nel dimenticatoio.
Quanto è pericoloso un file come config.php.bak?
Molto. Un file con l'estensione .php viene eseguito dal server e il suo contenuto resta nascosto. Una copia con un'altra estensione, invece, il server la fornisce di solito come testo, con password del database e chiavi.
Un dump del database richiamabile pubblicamente è una violazione dei dati?
Se contiene dati personali ed è stato richiamato, o se un accesso non si può escludere, si può profilare un obbligo di notifica ai sensi del GDPR. La valutazione nel singolo caso spetta al suo responsabile della protezione dei dati o alla sua consulenza legale.
Dove dovrebbero stare invece i backup?
Fuori dal webroot e inoltre fuori dal server, secondo la regola 3-2-1. Almeno una copia dovrebbe essere archiviata in modo che il server web stesso non possa cancellarla né modificarla.