Come proteggere un database WordPress: hardening, crittografia e protezione continua
John Turner
John Turner
Ogni sito WordPress funziona su un database. Contiene i tuoi post, i tuoi utenti, le loro password, le impostazioni dei tuoi plugin e gli ordini dei tuoi clienti.
I file sul server contengono il tuo tema e le tue immagini. Il database contiene tutto il resto.
Ecco perché è la prima cosa che un attaccante serio prende di mira.
L'SQL injection è ancora un comune vettore di attacco per WordPress. Gli attaccanti inviano input creati appositamente tramite moduli di accesso, caselle di ricerca o campi di plugin vulnerabili che ingannano il database nell'eseguire comandi che non dovrebbe.
Un'iniezione riuscita può creare nuovi account admin, reindirizzare i tuoi visitatori a siti di spam, iniettare codice dannoso nel tuo contenuto o cancellare completamente il database.
La maggior parte di questi attacchi non fa rumore. Il codice iniettato e gli account admin non autorizzati possono rimanere silenziosamente in un database per settimane prima che qualcosa di visibile vada storto.
Ho lavorato con siti che avevano ogni plugin aggiornato, l'autenticazione a due fattori abilitata e password robuste ovunque. Sono comunque stati colpiti attraverso una connessione al database che nessuno aveva bloccato.
Questo è l'argomento di questo tutorial.
Affronterai 13 passaggi per proteggere il tuo database: gli otto iniziali rafforzano il database stesso e chiudono i percorsi di attacco più comuni, e gli ultimi cinque impostano il livello di backup, monitoraggio e ripristino che ti protegge quando il solo rafforzamento non è sufficiente.
Alla fine, avrai una protezione del database continua e proattiva.
Ecco i punti chiave:
- I 13 passaggi coprono due livelli: rafforzamento del database (Passaggi 1-8) e impostazione di backup, monitoraggio e ripristino (Passaggi 9-13). Hai bisogno di entrambi, perché il solo rafforzamento non ti protegge dopo una violazione.
- Alcune violazioni del database non mostrano sintomi visibili per giorni o settimane, quindi il monitoraggio tramite il plugin Activity Log è importante quanto il rafforzamento della sicurezza.
- Un file di backup non crittografato nell'archiviazione cloud è una seconda copia del tuo intero database. Chiunque ottenga l'accesso a quell'account di archiviazione può leggerlo senza mai toccare il tuo sito live: la crittografia nel Passaggio 9 chiude quel varco.
- Esegui un backup completo del sito prima di iniziare il Passaggio 1. Diversi passaggi apportano modifiche dirette al database che sono difficili da annullare senza uno.
- Salva l'URL di ripristino di emergenza di Duplicator da qualche parte al di fuori di WordPress durante il Passaggio 11. È l'unico strumento che ti permette di rientrare quando la tua bacheca è completamente bloccata, ma solo se l'hai salvato prima che le cose andassero storte.
- La sezione di risoluzione dei problemi copre sei scenari di fallimento, incluso un percorso di ripristino completo per quando il tuo sito non risponde e la tua bacheca di WordPress non si carica.
Indice
- Cos'è un Database WordPress?
- Perché Devi Proteggere il Tuo Database WordPress
- Cosa Ti Serve Prima di Iniziare
- How to Secure Your WordPress Database
- Passaggio 1: Cambia il Nome Utente e l'ID Utente Admin Predefiniti
- Step 2: Change the Default Database Table Prefix
- Step 3: Create a Dedicated Database User with Limited Privileges
- Step 4: Disable Remote Database Connections
- Step 5: Protect Your wp-config.php File
- Step 6: Enable SSL for Database Connections
- Passaggio 7: Aggiungi un Firewall per Applicazioni Web
- Passaggio 8: Pulisci le Tabelle dei Plugin Abbandonati
- Passaggio 9: Imposta Backup Crittografati
- Passaggio 10: Pianifica Backup Automatici del Database
- Passaggio 11: Archivia i Backup Fuori Sede con Duplicator Cloud
- Passaggio 12: Monitora le Modifiche al Database con Activity Log
- Passaggio 13: Testa il Ripristino del Tuo Database
- Troubleshooting Database Security Issues
- Frequently Asked Questions (FAQs)
Cos'è un Database WordPress?
WordPress memorizza tutti i contenuti dinamici del tuo sito in un database. Quando qualcuno visita il tuo sito, WordPress interroga il database, recupera i contenuti pertinenti e assembla la pagina al volo. Se modifichi un'impostazione, pubblichi un post o aggiungi un utente, questi vengono inseriti nel database.
Una nuova installazione di WordPress crea 12 tabelle principali. Ecco cosa contengono le più importanti:
- wp_posts: ogni post, pagina, revisione e tipo di post personalizzato sul tuo sito
- wp_users: tutti gli account utente, i nomi utente e le password con hash
- wp_usermeta: ruoli utente, autorizzazioni e preferenze dell'account
- wp_options: impostazioni a livello di sito, configurazioni dei plugin e dati del tema attivo
- wp_comments: tutti i commenti dei visitatori e i loro metadati
I plugin e i temi aggiungono le proprie tabelle oltre a quelle predefinite di WordPress. Un negozio WooCommerce aggiunge tabelle per ordini, prodotti e dati dei clienti. Un plugin per moduli aggiunge tabelle per ogni invio.
Più costruisci su WordPress, più il tuo database cresce.
Perché Devi Proteggere il Tuo Database WordPress
Il database è un punto di fallimento a cui mirano tutti gli hacker seri. Tutto ciò che vale la pena rubare o distruggere si trova lì.
L'SQL injection è ancora un metodo di attacco comune. Un hacker invia input attentamente elaborati tramite un modulo di accesso, una casella di ricerca o un campo di plugin vulnerabile. Se l'input non viene adeguatamente sanificato, il database lo tratta come un comando e lo esegue.
Da lì, l'attaccante può leggere ed esportare l'intero database, creare nuovi account amministratore, iniettare contenuti dannosi nei tuoi post o cancellare tutto in una volta.
Il tuo file wp-config.php è l'altro obiettivo principale. Contiene il nome del database, il nome utente e la password in testo semplice. Un attaccante che ottiene quel file non ha bisogno del tuo accesso a WordPress. Si connette direttamente al database e aggira completamente WordPress.
Ciò che coglie di sorpresa la maggior parte dei proprietari di siti è quanto siano silenziose queste violazioni. Account amministratore non autorizzati e codice iniettato di solito non rompono nulla di visibile subito. Quando noti i reindirizzamenti spam o i contenuti manomessi, l'attaccante ha spesso avuto accesso per settimane.
Ecco perché l'indurimento della sicurezza da solo non è sufficiente. Hai anche bisogno di un modo per rilevare le modifiche e recuperare da un backup pulito quando qualcosa riesce a passare.
Cosa Ti Serve Prima di Iniziare
Prima di apportare qualsiasi modifica, assicurati di avere tutto ciò che segue a posto. Saltare il passaggio di backup in particolare ha causato problemi a molte persone in passaggi come la modifica del prefisso della tabella. Non vale la pena rischiare.
- Accesso al pannello di controllo dell'hosting. Dovrai accedere a cPanel, MyKinsta, alla dashboard di WP Engine o a qualsiasi pannello fornito dal tuo host. Diversi passaggi coinvolgono phpMyAdmin, che si trova tipicamente nella sezione Database del tuo pannello di controllo.
- Accesso FTP o File Manager. Avrai bisogno di un modo per visualizzare e modificare i file sul tuo server, in particolare wp-config.php. La maggior parte degli host fornisce un file manager direttamente nel pannello di controllo.
- Le tue attuali credenziali del database. Apri wp-config.php e individua i valori DB_NAME, DB_USER, DB_PASSWORD e DB_HOST. Farai riferimento a questi nei passaggi da 3 a 5.
- Un backup completo del sito eseguito prima di iniziare. Usa un plugin di backup come Duplicator o crea un backup manuale. Assicurati di avere copie dei file del tuo sito e del database. Alcuni di questi passaggi apportano modifiche dirette al tuo database e hai bisogno di un punto di ripristino pulito se qualcosa va storto.
- Accesso all'amministrazione di WordPress. Dovrai essere loggato come amministratore per diversi passaggi in questo tutorial.
Come proteggere il tuo database WordPress
Ti fornirò 13 semplici passaggi per proteggere il tuo database WordPress prima che si verifichi un attacco.
Gli primi otto rafforzano il database stesso e chiudono i percorsi di attacco più comuni. I passaggi da 9 a 13 impostano il livello di backup, monitoraggio e ripristino che ti protegge quando il solo rafforzamento non è sufficiente.
Ecco una panoramica di ciò che farai:
- Passaggio 1: Modifica il nome utente e l'ID utente predefiniti dell'amministratore. Rimuovi le due credenziali più prese di mira negli attacchi automatizzati a WordPress.
- Passaggio 2: Modifica il prefisso predefinito delle tabelle del database. Sostituisci il prefisso wp_ prevedibile che gli script di iniezione SQL sono progettati per colpire.
- Passaggio 3: Crea un utente di database dedicato con privilegi limitati. Riduci il tuo utente di database solo ai quattro permessi di cui WordPress ha effettivamente bisogno.
- Passaggio 4: Disabilita le connessioni remote al database. Chiudi l'accesso esterno al tuo database a livello di configurazione MySQL.
- Passaggio 5: Proteggi il tuo file wp-config.php. Blocca il file che memorizza le credenziali del tuo database in testo normale.
- Passaggio 6: Abilita SSL per le connessioni al database. Crittografa i dati in transito tra WordPress e MySQL se vengono eseguiti su server separati.
- Passaggio 7: Aggiungi un Web Application Firewall. Filtra i tentativi di iniezione SQL prima che raggiungano il tuo database.
- Passaggio 8: Pulisci le tabelle dei plugin abbandonati. Rimuovi le tabelle orfane lasciate dai plugin disinstallati che gonfiano il tuo database e contengono vulnerabilità non corrette.
- Passaggio 9: Imposta backup crittografati. Attiva la crittografia AES-256 in modo che i tuoi file di backup non possano essere letti senza la tua chiave, anche se qualcuno li scarica direttamente.
- Passaggio 10: Pianifica backup automatici del database. Rimuovi l'errore umano dalla tua routine di backup in modo da avere sempre un punto di ripristino recente, indipendentemente da quanto le cose si facciano frenetiche.
- Passaggio 11: Archivia i backup off-site. Tieni copie fuori dal tuo server in modo che una violazione a livello di hosting non possa eliminare le tue opzioni di ripristino.
- Passaggio 12: Monitora le modifiche al database. Individua la creazione di account di amministrazione non autorizzati e modifiche non autorizzate in tempo reale.
- Passaggio 13: Prova un ripristino del database. Conferma che il tuo piano di ripristino funzioni prima che ti serva.
Passaggio 1: Cambia il Nome Utente e l'ID Utente Admin Predefiniti
WordPress crea un utente con il nome utente "admin" e un ID di 1 durante l'installazione. Questi due valori sono integrati in quasi tutti gli script automatizzati di brute-force e SQL injection che prendono di mira WordPress. Modificarli rimuove due dei bersagli più prevedibili nel tuo database.
Ecco un metodo semplice per cambiare il nome utente dell'amministratore senza toccare il database:
- Crea un nuovo account amministratore direttamente in WordPress
- Accedi come quel nuovo utente
- Elimina l'account admin originale
- Riassegna i suoi contenuti al nuovo account
Se hai bisogno di apportare la modifica direttamente nel database, ecco come farlo tramite phpMyAdmin.
Accedi a phpMyAdmin dal tuo pannello di controllo hosting, seleziona il tuo database WordPress dalla barra laterale sinistra e fai clic sulla scheda SQL. Esegui le seguenti query una alla volta:
UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';
UPDATE wp_users SET ID = 101 WHERE ID = 1;
UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;
UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;
Tutte e quattro le query sono necessarie. Il tuo ID utente appare in wp_users, wp_posts e wp_usermeta, quindi aggiornare solo la prima tabella lascia riferimenti interrotti nelle altre due.
Un avviso prima di eseguire qualsiasi operazione: effettua prima un backup completo. Un errore di battitura in una query SQL diretta può danneggiare il tuo sito in modi difficili da annullare senza di esso.
Mi piace usare Duplicator per questo. Ha preset di backup facili da usare per i principianti che ti danno copie rapide del tuo database o dell'intero sito.

Duplicator ha i migliori strumenti di ripristino tra tutti i plugin di backup che ho provato. Vedrai come funzionano più avanti in questo tutorial!
Per confermare che la modifica ha funzionato, disconnettiti da WordPress e accedi di nuovo con il tuo nuovo nome utente. La tua dashboard dovrebbe caricarsi esattamente come prima.
Passaggio 2: Modifica il prefisso delle tabelle del database predefinito
WordPress denomina ogni tabella del database con un prefisso wp_ per impostazione predefinita. Gli script di SQL injection che prendono di mira WordPress sono costruiti attorno a questo.
Cambiare il prefisso in qualcosa di imprevedibile non fermerà da solo un attaccante sofisticato, ma rimuove il tuo sito dal pool di bersagli che gli strumenti automatizzati colpiscono al primo passaggio.
Ci sono due modi per farlo: utilizzare un plugin di sicurezza (consigliato per la maggior parte degli utenti) o apportare le modifiche manualmente tramite phpMyAdmin.
Metodo con plugin (consigliato)
Il metodo con plugin è la scelta più sicura per i principianti perché gestisce automaticamente i dati serializzati. Alcune tabelle di opzioni dei plugin memorizzano il prefisso all'interno di dati PHP serializzati e una ricerca e sostituzione SQL grezza può danneggiare tali dati se non viene gestita con attenzione.
All-In-One Security include uno strumento per il prefisso del database con protezioni integrate.
Installa il plugin scelto, naviga nella sua sezione degli strumenti del database ed esegui la modifica del prefisso da lì. Il plugin aggiornerà wp-config.php, rinominerà tutte le tabelle e gestirà i riferimenti ai dati serializzati in un unico passaggio.
Metodo manuale
Se preferisci modificare manualmente il prefisso delle tabelle del tuo database, segui questi passaggi.
Innanzitutto, apri wp-config.php tramite FTP o File Manager e aggiorna la riga $table_prefix al tuo nuovo prefisso. Usa solo lettere, numeri e underscore:
$table_prefix = 'site82_';
In secondo luogo, accedi a phpMyAdmin, seleziona il tuo database WordPress e apri la scheda SQL. Esegui una query RENAME TABLE per ogni tabella nel tuo database:
RENAME TABLE wp_posts TO site82_posts;
RENAME TABLE wp_users TO site82_users;
Repeat this for all 12 core tables and any tables added by plugins.
Successivamente, aggiorna la tabella wp_options, che contiene righe che fanno ancora riferimento al vecchio prefisso nella colonna option_name:
UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';
Infine, aggiorna la tabella wp_usermeta per lo stesso motivo:
UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';
Controlla i tuoi plugin attivi dopo aver eseguito queste query. Alcuni plugin memorizzano il prefisso nelle proprie righe di dati e necessitano che anche quelle vengano aggiornate. Se qualcosa sembra non funzionare, il backup pre-modifica è il modo più rapido per tornare a uno stato funzionante.
Per confermare che tutto ha funzionato, visita la homepage del tuo sito, quindi disconnettiti ed effettua nuovamente l'accesso alla tua bacheca di WordPress. Entrambe dovrebbero funzionare esattamente come prima.
Passaggio 3: Crea un Utente Database Dedicato con Privilegi Limitati
Quando WordPress viene installato, la maggior parte delle configurazioni di hosting crea un utente del database con accesso amministrativo completo all'intero database. WordPress di solito necessita solo di quattro autorizzazioni di base per funzionare: SELECT, INSERT, UPDATE e DELETE. Ogni autorizzazione oltre queste potrebbe creare un rischio aggiuntivo.
Se un aggressore sfrutta una vulnerabilità di un plugin e ottiene l'accesso alle credenziali del tuo database, i privilegi limitati fanno la differenza tra la lettura dei tuoi dati e l'eliminazione dell'intero database.
Ci sono due modi per affrontare questo problema: limitare i privilegi dell'utente del database esistente o creare un nuovo utente dedicato con solo le autorizzazioni di cui WordPress ha bisogno.
Limitare i privilegi tramite phpMyAdmin
Accedi a phpMyAdmin, fai clic su Account utente in alto, trova il tuo utente del database di WordPress nell'elenco e fai clic su Modifica privilegi. Deseleziona tutto tranne SELECT, INSERT, UPDATE e DELETE. Scorri verso il basso e fai clic su Vai per salvare.
Creazione di un nuovo utente dedicato tramite SQL
Se preferisci una configurazione pulita, esegui queste query nella scheda SQL di phpMyAdmin:
CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';
GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';
FLUSH PRIVILEGES;
If you create a new user, update your wp-config.php file with the new credentials:
define('DB_USER', 'wpuser_secure');
define('DB_PASSWORD', 'StrongPasswordHere');
Una nota importante: alcuni plugin e importanti aggiornamenti del core di WordPress necessitano delle autorizzazioni CREATE o ALTER per aggiungere o modificare tabelle del database durante l'installazione. Se un'installazione di un plugin fallisce dopo questo passaggio, ripristina temporaneamente tali autorizzazioni, completa l'installazione, quindi revoca nuovamente.
Se gestisci più siti WordPress sullo stesso server, utilizza un database completamente separato e un utente del database separato per ciascuno. Se un sito viene compromesso, tale contenimento impedisce all'aggressore di raggiungere gli altri.
Per confermare che le autorizzazioni siano impostate correttamente, crea una bozza di post in WordPress, salvala ed eliminala. Se tutte e tre le azioni hanno successo, il tuo utente del database ha ciò di cui ha bisogno e nient'altro.
Passaggio 4: Disabilita le Connessioni Remote al Database
Nella maggior parte delle configurazioni di WordPress, WordPress e MySQL vengono eseguiti sullo stesso server. Non c'è motivo di consentire agli IP esterni di connettersi direttamente al tuo database. Lasciare l'accesso remoto aperto significa che un aggressore può tentare di autenticarsi contro MySQL da qualsiasi punto di Internet, bypassando completamente WordPress.
Ci sono due posti dove chiudere questo, e dovresti controllare entrambi.
Configurazione MySQL
Se gestisci il tuo server (VPS o hosting cloud), individua il file di configurazione di MySQL. Di solito si trova in /etc/mysql/mysql.conf.d/mysqld.cnf. Trova la riga bind-address e conferma che sia impostata su 127.0.0.1:
bind-address = 127.0.0.1
Se è impostata su 0.0.0.0, cambiala in 127.0.0.1 e riavvia MySQL per applicare la modifica:
sudo systemctl restart mysql
Hostname utente del database
Anche se MySQL è associato a localhost, vale la pena confermare che il tuo utente del database di WordPress sia limitato alle connessioni locali anche a livello utente.
In phpMyAdmin, fai clic su Account utente e trova il tuo utente del database di WordPress. La colonna Host dovrebbe mostrare localhost o 127.0.0.1. Se vedi un carattere jolly %, quell'utente può connettersi da qualsiasi indirizzo IP.
Elimina eventuali utenti impostati su % e ricreali con localhost come host:
DROP USER 'wpuser'@'%';
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';
GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
Utenti di hosting condiviso
Se sei su hosting condiviso e non hai accesso al file di configurazione di MySQL, controlla invece il tuo pannello di controllo. In cPanel, cerca MySQL remoto nella sezione Database.
Rimuovi eventuali indirizzi IP elencati lì. Questo equivale a chiudere l'accesso remoto a livello di hosting.
Per confermare che l'accesso remoto sia disabilitato, il tuo utente del database di WordPress dovrebbe mostrare localhost come unico host consentito nella schermata Account utente di phpMyAdmin.
Passaggio 5: Proteggi il tuo file wp-config.php
Il tuo file wp-config.php contiene il nome del database, il nome utente, la password e le chiavi di autenticazione in testo semplice. Se un aggressore può leggere questo file, ha tutto ciò che gli serve per connettersi direttamente al tuo database. È uno dei primi file presi di mira in qualsiasi attacco a WordPress.
Applica tutte e tre le seguenti protezioni insieme. Ognuna chiude un'esposizione diversa.
1. Sposta il file sopra la root del web
WordPress cerca automaticamente una directory sopra la root se non riesce a trovare wp-config.php in posizione, quindi puoi spostare il file senza modificare alcuna impostazione. Se la root del tuo sito è /public_html, sposta wp-config.php in /home/username/. Usa FTP o il File Manager del tuo host per farlo.
Questo funziona sulla maggior parte delle configurazioni di hosting standard, ma alcuni provider di hosting gestito non lo consentono. Se il tuo host limita l'accesso sopra la root del web, passa alle due protezioni successive.
2. Blocca l'accesso web tramite .htaccess
Aggiungi la seguente regola al tuo file .htaccess, che si trova nella directory principale di WordPress. Questo dice ad Apache di negare tutte le richieste del browser per il file direttamente, anche se qualcuno conosce il percorso:
<Files wp-config.php>
order allow,deny
deny from all
</Files>
Se il tuo host utilizza una configurazione Apache più recente, usa invece questa versione:
<Files "wp-config.php">
Require all denied
</Files>
3. Imposta i permessi del file su 400 o 440
I permessi del file controllano quali utenti sul server possono leggere, scrivere o eseguire un file. Impostare wp-config.php su 400 significa che solo il proprietario del file può leggerlo. Impostarlo su 440 estende l'accesso in lettura anche al gruppo del server, cosa che alcune configurazioni di hosting richiedono.
Nel File Manager del tuo host, fai clic con il pulsante destro del mouse su wp-config.php, seleziona Cambia permessi e inserisci 400. Tramite FTP, la maggior parte dei client ti consente di fare clic con il pulsante destro del mouse sul file e impostare direttamente i permessi.
Per confermare che tutte e tre le protezioni siano attive, prova ad accedere a tuodominio.com/wp-config.php in un browser. Dovresti ricevere un errore 403 Forbidden.
Passaggio 6: Abilita SSL per le connessioni al database
Quando WordPress e MySQL sono in esecuzione sullo stesso server, i dati tra di loro rimangono locali e non attraversano mai una rete. Ma se il tuo database è in esecuzione su un server separato (comune nelle configurazioni VPS, hosting cloud o ambienti gestiti), quei dati viaggiano attraverso una connessione di rete. Senza SSL, viaggiano in testo semplice, comprese le credenziali di accesso e i token di sessione.
Se utilizzi un hosting condiviso standard con WordPress e MySQL sullo stesso server, puoi saltare questo passaggio. Se utilizzi un'architettura multi-server o una configurazione cloud in cui il tuo database è in esecuzione separatamente, non farlo.
Verifica prima con il tuo host
Molti provider di hosting gestito gestiscono automaticamente l'SSL per le connessioni al database. Kinsta, WP Engine e Cloudways impongono connessioni al database crittografate a livello di infrastruttura. Controlla la documentazione del tuo host prima di apportare modifiche manuali: potresti essere già coperto.
Abilita SSL sul server MySQL
Se gestisci il tuo server, aggiungi quanto segue al tuo file mysqld.cnf per configurare i certificati SSL e richiedere connessioni crittografate:
[mysqld]
ssl-ca = /path/to/ca.pem
ssl-cert = /path/to/server-cert.pem
ssl-key = /path/to/server-key.pem
require_secure_transport = ON
Riavvia MySQL dopo aver salvato il file.
Indica a WordPress di utilizzare SSL
Aggiungi la seguente riga al tuo file wp-config.php, sopra la riga che dice /* Questo è tutto, smetti di modificare! */:
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
Questo indica alla connessione al database di WordPress di richiedere SSL quando si connette a MySQL.
Per confermare che SSL sia attivo, controlla il log degli errori del tuo server MySQL dopo che WordPress effettua la prossima connessione al database. Dovresti vedere SSL elencato come attivo per l'utente dell'applicazione.
Passaggio 7: Aggiungi un Firewall per Applicazioni Web
La protezione del database nei passaggi precedenti riduce significativamente la tua superficie di attacco. Ma non elimina il rischio che un plugin vulnerabile diventi un punto di ingresso per l'SQL injection.
Un Web Application Firewall (WAF) si posiziona davanti al tuo sito e filtra le richieste dannose prima che raggiungano WordPress o il tuo database.
Per la sicurezza del database, il compito più importante di un WAF è riconoscere i pattern di SQL injection negli input dei moduli, nei parametri URL e negli header delle richieste e bloccarli prima che vengano eseguiti. Blocca anche IP e bot dannosi, riduce i tentativi di accesso brute-force e mantiene un registro delle richieste bloccate che puoi rivedere se qualcosa sembra sospetto.
Tre opzioni WAF funzionano bene per la maggior parte dei siti WordPress:
- Wordfence: Si installa direttamente come plugin di WordPress. Il livello gratuito include un WAF con protezione di base contro SQL injection. Il livello premium aggiunge intelligence sulle minacce in tempo reale e aggiornamenti delle regole più rapidi.
- Sucuri: Offre uno scanner basato su plugin e un WAF a livello DNS. L'opzione a livello DNS instrada tutto il traffico attraverso la rete di Sucuri prima che raggiunga il tuo server, il che fornisce una protezione più forte ma richiede un piano a pagamento.
- Cloudflare: Un WAF a livello DNS con un livello gratuito che copre il filtraggio di attacchi di base. I piani a pagamento aggiungono regole più granulari e una migliore copertura per gli attacchi a livello di applicazione.
Se devi modificare le regole del firewall dopo l'installazione, testa eventuali modifiche su una copia di staging del tuo sito prima di applicarle alla produzione. Una regola configurata in modo errato può bloccare traffico legittimo: moduli di contatto, flussi di checkout e azioni di amministrazione sono tutte vittime comuni.
Un WAF è un livello complementare, non una sostituzione per i passaggi di hardening che hai già completato. Pensalo come il filtro che cattura ciò che sfugge a tutto il resto.
Passaggio 8: Pulisci le Tabelle dei Plugin Abbandonati
Quando disinstalli un plugin in WordPress, le sue tabelle di database vengono solitamente lasciate indietro. WordPress non le elimina automaticamente e la maggior parte dei plugin non esegue la pulizia dopo la rimozione.
Nel tempo, queste tabelle orfane gonfiano il tuo database e creano un rischio di sicurezza nascosto: una tabella di un plugin con una vulnerabilità nota di SQL injection è ancora sfruttabile anche dopo che il plugin stesso non c'è più.
Per identificare le tabelle orfane, utilizza un plugin come WP-Optimize o Advanced Database Cleaner. Entrambi scansionano il tuo database e segnalano le tabelle che non corrispondono a nessun plugin attualmente attivo.
Installane uno, esegui una scansione di ottimizzazione del database e rivedi i risultati prima di eliminare qualsiasi cosa.

Puoi anche rivedere manualmente l'elenco delle tabelle in phpMyAdmin. Seleziona il tuo database WordPress dalla barra laterale sinistra e scorri l'elenco delle tabelle. Le tabelle che non corrispondono al tuo $table_prefix corrente o che portano il nome di un plugin che non usi più sono candidati per la rimozione.
Tuttavia, crea prima un backup fresco del database. L'eliminazione di una tabella è permanente e alcune tabelle che sembrano abbandonate sono ancora attivamente utilizzate.
Sii particolarmente cauto con qualsiasi tabella associata a WooCommerce, plugin di moduli come Gravity Forms o WPForms, e plugin di membership o LMS. Questi spesso memorizzano record di transazioni, invii di moduli e dati utente di cui potresti aver bisogno anche se il plugin non è più attivo.
Incrocia ogni tabella candidata con il tuo elenco di plugin attivi prima di rimuoverla. Se non sei sicuro a cosa appartenga una tabella, cerca il nome della tabella insieme alla parola "WordPress" per identificare il plugin che l'ha creata.
Per eliminare una tabella orfana confermata in phpMyAdmin, seleziona la tabella, fai clic su Operations e scorri verso il basso per fare clic su Drop Table. In alternativa, eseguila tramite la scheda SQL:
DROP TABLE old_plugin_table_name;
Per confermare che la pulizia sia avvenuta senza problemi, esegui un rapido test funzionale sul tuo sito dopo aver rimosso le tabelle. Controlla la tua homepage, invia un modulo di test se ne hai uno, ed effettua il logout e il login.
Passaggio 9: Imposta Backup Crittografati
I passaggi precedenti riducono le possibilità di subire un attacco riuscito al tuo database. Questo passaggio è ciò che ti fa uscire da uno.
La maggior parte delle persone pensa ai backup come a uno strumento di ripristino di emergenza. A seconda di come li crei, possono anche rappresentare un rischio per la sicurezza.
Un file di backup non crittografato che si trova in una cartella di Google Drive è una seconda copia del tuo intero database. Chiunque ottenga l'accesso a quell'account di archiviazione può scaricarlo, aprirlo e leggere ogni record utente, hash di password e ordine cliente senza mai toccare il tuo sito live. La crittografia rende quel file inutile senza la tua chiave.
Ecco perché crittografo sempre i backup con Duplicator. Questo plugin ti consente di abilitare la crittografia AES-256 su ogni backup.

AES-256 è lo stesso standard di crittografia utilizzato dagli istituti finanziari e dai sistemi governativi. Con esso abilitato, il tuo archivio di backup è completamente illeggibile senza password, anche se qualcuno scarica il file direttamente dal tuo account di archiviazione.
Due cose da fare prima di salvare: scrivi questa password e conservala in un gestore di password. Se la perdi, i tuoi backup crittografati diventano permanentemente inaccessibili. Conserva una copia da qualche parte al di fuori di WordPress.
Passaggio 10: Pianifica Backup Automatici del Database
Un backup crittografato ti protegge solo se ne hai effettivamente uno quando qualcosa va storto.
I backup manuali falliscono nella pratica perché la vita si mette di mezzo. Ti ricordi di eseguirne uno prima di un aggiornamento importante, magari dopo una migrazione, occasionalmente quando qualcosa non va. Quello che non fai è eseguirne uno ogni singolo giorno senza fallo.
Quel divario è la differenza tra un ripristino pulito e uno disordinato. Se un aggressore crea un account amministratore dannoso o inietta contenuti dannosi oggi e tu non te ne accorgi per due settimane, hai bisogno di un backup di prima che ciò accadesse.
Una pianificazione giornaliera ti offre un punto di ripristino pulito che non ha più di 24 ore. Un'abitudine di backup manuale ti offre qualunque cosa tu abbia eseguito per ultima.
Nella tua dashboard di WordPress, vai su Duplicator Pro » Pianificazione Backup e fai clic su Aggiungi Nuovo. Dai un nome alla pianificazione del backup e scegli un modello. Ad esempio, potresti creare un modello di backup del database.

Scegli una posizione di archiviazione. Duplicator supporta backup locali, nonché popolari archivi cloud come Duplicator Cloud, Google Drive, Amazon S3 e Google Cloud.

Imposta la frequenza in base all'attività del tuo sito.

I backup giornalieri del database sono la scelta giusta per qualsiasi sito che pubblica contenuti regolarmente, elabora ordini o ha account utente attivi. Settimanale va bene per siti statici o a basso traffico in cui il database cambia raramente.
Passaggio 11: Archivia i Backup Fuori Sede con Duplicator Cloud
Un backup archiviato sullo stesso server del tuo sito non è un vero backup. Se il tuo server viene compromesso, il ransomware crittografa i tuoi file o il tuo host subisce un guasto catastrofico, perdi il tuo backup nello stesso momento in cui perdi il tuo sito.
L'archiviazione off-site è ciò che separa "Ho perso tutto" da "Ho ripristinato in 20 minuti."
Duplicator Cloud è l'opzione di archiviazione di backup WordPress più semplice. È stato creato per i backup WordPress, si integra direttamente in Duplicator Pro e non richiede l'autenticazione API.

Se preferisci un'alternativa, Duplicator Pro supporta anche Google Drive, Amazon S3, Dropbox, OneDrive e qualsiasi provider di archiviazione compatibile con S3, inclusi Cloudflare R2, Backblaze B2 e DigitalOcean Spaces.
Una volta connesso il tuo archivio, modifica la tua pianificazione di backup e impostala per inviare copie al tuo provider di archiviazione connesso automaticamente dopo ogni esecuzione.
Mantieni almeno una copia sul tuo host e una copia nell'archivio cloud off-site. Per siti critici o quelli che gestiscono dati dei clienti, una terza copia scaricata localmente aggiunge un ulteriore livello di protezione.
Se hai bisogno di ripristinare, Duplicator Pro può prelevare direttamente dallo spazio di archiviazione cloud connesso senza dover prima riscaricare l'archivio sul tuo server.
Naviga su Duplicator Pro » Backup. Trova un backup cloud e premi Ripristina. Questo è più veloce di un download manuale e funziona anche se le copie di backup locali sono state eliminate.

Anche se non hai accesso alla tua bacheca wp-admin, puoi ripristinare un backup cloud. La tua bacheca cloud Duplicator ti consente di annullare istantaneamente qualsiasi backup da remoto, anche backup parziali del database!

Passaggio 12: Monitora le Modifiche al Database con Activity Log
La mossa più comune che un attaccante compie dopo aver ottenuto l'accesso al database è la creazione di un account amministratore non autorizzato. Questo gli fornisce un modo persistente per rientrare nel tuo sito anche dopo che il punto di ingresso originale è stato chiuso e ripulito.
Senza monitoraggio, quell'account può rimanere inattivo per settimane. Con un plugin per il registro delle attività, viene rilevato nel momento in cui viene creato.
Activity Log registra ogni azione sul tuo sito WordPress con data e ora e indirizzo IP. Tieni traccia senza sforzo degli accessi degli utenti, della creazione di nuovi account, delle modifiche ai ruoli e delle modifiche alle impostazioni.

Per la sicurezza del database, gli eventi più importanti sono i nuovi utenti che non hai creato tu, le escalation di ruolo in cui un account di livello inferiore ottiene improvvisamente l'accesso amministrativo e i tentativi di accesso da indirizzi IP non familiari.
Activity Log è incluso gratuitamente con Duplicator Elite. Una volta che il tuo piano è attivo, scarica il plugin e installalo in WordPress. Inizierà subito il monitoraggio.
Controlla regolarmente il registro per tre cose.
- Qualsiasi nuovo account utente che non riconosci.
- Qualsiasi utente esistente il cui ruolo è cambiato senza la tua azione.
- Qualsiasi accesso da un indirizzo IP che non corrisponde alle posizioni del tuo team.
Ognuna di queste cose può indicare una violazione attiva o un compromesso avvenuto giorni o settimane fa.
Activity Log ti consente di filtrare il registro per utente, tipo di azione o intervallo di date ed esportare i risultati. Questo è utile sia per audit di routine che per la risposta agli incidenti, dove è necessario individuare esattamente quando si è verificata una modifica non autorizzata.

Passaggio 13: Testa il Ripristino del Tuo Database
La maggior parte delle persone scopre che il proprio backup è rotto esattamente quando è sotto la massima pressione per recuperare rapidamente. Un test richiede solo pochi minuti. Un ripristino fallito durante un incidente attivo ti costa molto di più.
La funzione di staging con un clic di Duplicator Pro ti consente di ripristinare un backup su un URL di staging separato senza toccare il tuo sito live. In Duplicator Pro » Staging, crea un nuovo sito di staging.

Seleziona un backup completo del sito recente come modello. Scegli uno schema di colori amministrativo univoco per differenziare i tuoi siti di staging e live.

Una volta che Duplicator ha finito di creare il tuo sito di staging, avrai una replica completa del tuo sito live. Questo è un terreno di prova efficace per eseguire ripristini di prova.
Carica un backup nella pagina Importa backup di Duplicator. Esamina il sito di staging dopo il completamento del ripristino.

Controlla la tua homepage, accedi alla bacheca di WordPress, apri alcuni post e verifica che le impostazioni del tuo plugin siano corrette. Se manca qualcosa o è rotto, hai trovato il problema ora invece che durante un vero recupero.
Per confermare che il tuo test di ripristino sia andato a buon fine, il tuo sito di staging dovrebbe caricarsi in modo pulito con tutti i contenuti, utenti e impostazioni intatti dalla data del backup.
Risoluzione dei problemi di sicurezza del database
Anche quando segui attentamente ogni passaggio, le cose possono andare storte. Ecco i punti di guasto più comuni e come superarli.
Il tuo sito diventa bianco dopo aver modificato il prefisso delle tabelle
Cosa vedi: Uno schermo bianco o un errore PHP generico subito dopo aver modificato il prefisso delle tabelle.
Perché succede: La causa più comune è un riferimento a tabella mancante. Alcuni plugin memorizzano il vecchio prefisso all'interno di dati PHP serializzati nelle tabelle delle opzioni o usermeta. Se una query SQL grezza ha aggiornato i nomi delle tabelle ma ha perso quei riferimenti interni, WordPress non riesce a trovare ciò che sta cercando.
Come risolvere: Ripristina immediatamente un backup. Questo è esattamente il motivo per cui quel backup è non negoziabile prima di iniziare questi passaggi di sicurezza del database.
Una volta tornato a uno stato funzionante, usa un plugin come All-In-One Security per apportare la modifica del prefisso invece. I loro strumenti gestiscono automaticamente i dati serializzati e hanno molte meno probabilità di lasciare riferimenti interrotti.
WordPress non riesce a connettersi al database dopo aver modificato wp-config.php
Cosa vedi: Un messaggio "Errore durante la connessione al database" sul front-end o uno schermo bianco vuoto.
Perché succede: Un errore di battitura in uno dei valori delle credenziali del database è la causa più comune. Spostare wp-config.php in una posizione che il tuo server non riesce a trovare è la seconda causa più comune. Le autorizzazioni dei file impostate in modo troppo restrittivo (come 000) possono anche impedire a WordPress di leggere il file.
Come risolvere: Connettiti tramite FTP o File Manager e apri direttamente wp-config.php. Verifica che DB_NAME, DB_USER, DB_PASSWORD e DB_HOST siano corretti e corrispondano esattamente a quanto presente nel tuo pannello di controllo di hosting. Se hai spostato il file, conferma che si trovi una directory sopra la root di WordPress, non più in profondità. Imposta le autorizzazioni su 400 o 440 se sono state modificate in altro modo.
Un plugin smette di funzionare dopo aver limitato i privilegi del database
Cosa vedi: Un plugin genera un errore, non riesce a salvare le impostazioni o visualizza un avviso relativo al database dopo aver completato il Passaggio 3.
Perché succede: Alcuni plugin necessitano di autorizzazioni CREATE o ALTER per installare o aggiornare le proprie tabelle di database. Una volta revocate tali autorizzazioni, il plugin non può apportare le modifiche strutturali necessarie.
Come risolvere: Concedi temporaneamente le autorizzazioni CREATE e ALTER al tuo utente del database tramite phpMyAdmin. Aggiorna o reinstalla il plugin, lascialo completare la sua configurazione, quindi revoca nuovamente tali autorizzazioni. Questa è una parte normale della manutenzione di una configurazione di database con privilegi minimi.
Nulla funziona: Percorso di recupero completo
Se il tuo sito non risponde, la tua bacheca di WordPress è bloccata e non riesci ad accedervi con i normali mezzi, utilizza una delle opzioni di ripristino di emergenza di Duplicator.
Per i backup archiviati nel cloud di Duplicator, puoi ripristinarli da remoto. Il tuo sito tornerà online senza ulteriori problemi.
Prima che si verifichino disastri, puoi anche impostare un backup come punto di ripristino in WordPress. Salva l'URL di ripristino di emergenza in un luogo sicuro.
Se il tuo sito non funziona, incolla questo URL in un browser web e segui le istruzioni.
Se non hai configurato un backup di ripristino di emergenza o un backup cloud, contatta la linea di supporto di emergenza del tuo provider di hosting. La maggior parte degli host gestiti conserva i propri snapshot a livello di server. Per i siti sotto attacco attivo con malware in tempo reale, Wordfence e Sucuri offrono entrambi servizi di risposta di emergenza a pagamento.
Domande frequenti (FAQ)
È necessario modificare il prefisso delle tabelle del database di WordPress per la sicurezza?
È un utile passaggio di rafforzamento, ma non una soluzione definitiva. Modificare il prefisso da wp_ a qualcosa di imprevedibile rimuove il tuo sito dal pool di bersagli che gli script automatizzati di SQL injection colpiscono al primo passaggio. Un attaccante determinato può aggirarlo. Detto questo, richiede solo pochi minuti ed elimina un'intera categoria di attacchi a basso sforzo, quindi vale la pena farlo come parte di una configurazione di sicurezza più ampia.
Quali permessi del database necessita WordPress per funzionare?
Per il normale funzionamento quotidiano, l'utente del database di WordPress necessita di quattro permessi: SELECT, INSERT, UPDATE e DELETE. Tutto il resto — DROP, ALTER, CREATE, GRANT — può essere revocato. L'unica eccezione è quando si installa un nuovo plugin che aggiunge le proprie tabelle di database. Tali installazioni potrebbero richiedere temporaneamente CREATE o ALTER. Ri-concedili per l'installazione, quindi revoca di nuovo quando è terminata.
Ogni quanto dovrei eseguire il backup del mio database WordPress?
Per i siti attivi che pubblicano regolarmente contenuti o elaborano transazioni, i backup giornalieri del database sono la cadenza giusta. Per i siti con traffico ridotto e modifiche infrequenti, il backup settimanale è accettabile. La domanda da porsi è: quanti dati puoi permetterti di perdere? Se perdere una settimana di contenuti o ordini è inaccettabile, esegui il backup giornalmente. I backup pianificati di Duplicator Pro lo rendono automatico una volta configurato.
Qualcuno può rubare i miei dati da un file di backup?
Sì, se il backup non è crittografato. Un archivio di backup non crittografato archiviato in un account di archiviazione cloud è una copia completa del tuo database. Chiunque ottenga l'accesso a tale account di archiviazione può scaricarlo e leggere ogni record utente, hash della password e ordine del cliente senza mai toccare il tuo sito live. La crittografia AES-256 in Duplicator Pro rende il file illeggibile senza la tua password, anche se qualcuno lo scarica direttamente.
Come faccio a sapere se il mio database WordPress è stato compromesso?
Controlla gli account utente che non hai creato in Utenti » Tutti gli utenti. Cerca post o pagine contenenti link o contenuti sconosciuti che non hai scritto. Fai attenzione ai visitatori reindirizzati a siti di spam. In phpMyAdmin, analizza la tabella wp_options alla ricerca di voci sconosciute, in particolare nelle righe siteurl e home. I timestamp del registro attività ti consentono di individuare esattamente quando è stata apportata una modifica non autorizzata, che è spesso il modo più rapido per confermare una violazione.
Qual è l'URL di disaster recovery di Duplicator e quando lo uso?
L'URL di disaster recovery è un link diretto all'installer di Duplicator che recupera un backup dal tuo spazio di archiviazione cloud connesso senza la necessità che WordPress sia funzionante. Lo usi quando il tuo sito è completamente inaccessibile: un database corrotto, un aggiornamento fallito che ha bloccato la schermata di amministrazione o una violazione che ti ha bloccato completamente. Imposta un backup completo del sito recente come punto di disaster recovery, copia l'URL generato e archivialo da qualche parte al di fuori di WordPress prima che ti serva.
Ho bisogno di un plugin di sicurezza separato se sto già usando un WAF?
Un WAF filtra il traffico dannoso prima che raggiunga il tuo sito, ma non monitora ciò che accade all'interno di WordPress dopo che una richiesta è stata elaborata. Un plugin di sicurezza come Wordfence aggiunge scansione malware, controlli di integrità dei file e protezione degli accessi che un WAF non copre. I due livelli servono a scopi diversi. Per la maggior parte dei siti, un WAF combinato con il registro attività per il monitoraggio interno copre gli aspetti più importanti senza sovrapposizioni significative.
Hai protetto il tuo database. Ecco come mantenerlo tale.
Se hai completato tutti questi passaggi, il tuo database è in condizioni migliori rispetto alla maggior parte dei siti WordPress in esecuzione al momento.
Il lavoro, tuttavia, non è finito. La sicurezza del database non è una configurazione una tantum. È una pratica di manutenzione.
Rivedi il tuo registro attività mensilmente e cerca qualsiasi cosa che non corrisponda alla tua attività. Prova un ripristino trimestrale: le connessioni di archiviazione scadono, le password di crittografia vengono smarrite e l'unico modo per sapere che i tuoi backup sono utilizzabili è usarne uno.
Riesamina i privilegi utente del tuo database dopo ogni nuova installazione di plugin, poiché alcuni plugin aumentano nuovamente i permessi durante gli aggiornamenti senza renderlo evidente. E se mai migrassi su un nuovo host, riesegui i passaggi 4 e 5 da capo. Le impostazioni di accesso remoto e i permessi dei file non vengono sempre trasferiti come ti aspetteresti.
Dopo aver completato questa configurazione, crea un backup del solo database ed etichettalo chiaramente come tuo punto di riferimento post-hardening. Se in futuro dovessi indagare su una violazione, quel punto di riferimento ti fornirà un punto di confronto pulito.
Oltre 1,5 milioni di professionisti WordPress utilizzano Duplicator Pro per gestire backup, migrazioni, staging e disaster recovery. È lo strumento alla base degli archivi crittografati AES-256, dell'archiviazione off-site Duplicator Cloud, dei ripristini con un clic, del ripristino del solo database e degli URL di disaster recovery che ti permettono di tornare online anche quando WordPress stesso non si carica.
Se questo tutorial ti è stato utile, anche queste guide meritano di essere aggiunte ai preferiti.
- Come ottimizzare il tuo database WordPress
- Ecco i passaggi per riparare il database di WordPress che ho eseguito personalmente (nessuno sviluppatore necessario)
- Manutenzione del database di WordPress: Cosa fare settimanalmente, mensilmente e trimestralmente
- WordPress è sicuro? Sveliamo la verità
- Come proteggere il tuo sito web dagli hacker (Guida definitiva alla sicurezza)
- Come recuperare un sito WordPress compromesso (9 consigli esperti)