fbpx
giovedì, Novembre 21, 2024
HomeGuideConsigliRisolvere "Error establishing a database connection" su WordPress

Risolvere “Error establishing a database connection” su WordPress

-

Torniamo a parlare di “sicurezza web”, questa volta in maniera più mirata. Nel nostro obiettivo WordPress ed un errore in particolare che, colpevole la scarsa quantità di informazioni sul web, può causare numerevoli danni.

Ultimamente, sono incappato più volte, su alcuni miei siti WordPress, in un fastidioso problema.

Inizialmente in maniera sporadica, poi sempre più spesso, il sito risultava offline, con un misterioso messaggio: Error establishing a database connection.

Chiaramente, se masticate leggermente il mondo del web design, il primo pensiero va ad un errore di configurazione.

Tale messaggio infatti compare, il più delle volte, quando le credenziali all’interno del wp-config non sono corrette. Se il tuo sito, sin dal primo giorno, rispondeva con tale messaggio, quasi sicuramente il tuo problema è qui:

define(‘DB_NAME’, ‘nome-database‘);
define(‘DB_USER’, ‘nome-utente-database‘);
define(‘DB_PASSWORD’, ‘password-database‘);
define(‘DB_HOST’, ‘localhost‘);

Questi campi vanno riempiti con le credenziali del tuo database (che esse ti siano state fornite dal tuo provider o generate da te, non importa), per far si che il sito sia correttamente visualizzato.

Purtroppo, a causa di questo facile errore, per chi è alle prime armi, il web è pieno zeppo di guide su come risolvere Error establishing a database connection in caso di wp-config errato.

NON SEMPRE LA SOLUZIONE É COSÌ SEMPLICE

Difatti, il problema vero nasce quando il sito in analisi ha sempre funzionato correttamente, per poi all’improvviso andare offline, riportando tale messaggio.

Infatti, se fosse un semplice errore di wp-config, il sito non avrebbe mai dovuto essere online. Anche in questo caso, potrebbero esserci più cause: i dati di accesso al database sono stati modificati, il tuo host è in manutenzione, o le più svariate motivazioni.

Dopo qualche mese di ricerche, di sudore e, non lo nego, di imprecazioni, ho scovato (grazie anche ad un amico programmatore), la causa del mio problema.

Abbiamo notato che la ram della mia VPS privata (sulla quale è hostato solo un piccolo sito WP, con pochissimi visitatori unici al giorno) era sempre satura. Parliamo di circa il 70%-80% di 2gb di ram, per un sitariello/portfolio che tocca a malapena i 100 visitatori quotidiani.

Abbiamo subito sospettato un attacco, probabilmente spiderbot.

Uno spiderbot, o crawler, è un software, a volte maligno, a volte no (anche i motori di ricerca come Google hanno i loro crawler), che visita la rete per gli scopi più disparati.

In questo case, tale spiderbot, eseguiva una moltitudine di accessi simultanei al mio sito, anzi ad un singolo file del mio sito, sovraccaricando le memorie ram e quindi generando il fatidico errore.

Ma quindi sono stato preso di mira? Un hacker vuole rubare i miei dati ed il mio sito?

Chiaramente no, questi software colpiscono la rete in maniera random e, molto probabilmente, non siete vittime di un attacco mirato, bensì hanno sparato nella folla e siete stati colpiti voi.

IL COLPEVOLE (NON É IL MAGGIORDOMO)

No. Questa volta il colpevole non è il maggiordomo.

Bensì un file chiamato: xml-rpc.php. Questo file è uno dei documenti di base di WordPress, è un protocollo utilizzato in informatica per eseguire chiamate a procedure remote attraverso la rete (ebbene sì, anche io ho accesso a Wikipedia).

Saltando tutta la, sicuramente bellissima, parte tecnica che vi spiega nel dettaglio di sigle aramaiche le funzioni di questo file, posso svelarvi ch’esso, all’interno di WP in particolare, serve per postare i contenuti sul proprio sito/blog in remoto, da piattaforme diverse dal vostro solito back-end.

Semplificando ancora di più, in maniera estrema, xml-rpc serve per postare articoli tramite l’app di WordPress sul vostro smartphone.

Oh! E non lo sapevo dire prima?

RISOLVERE IL PROBLEMA

Per alcuni di voi, questo potrebbe essere causa di un conflitto interiore, poichè sfruttano tale funzionalità.

A me, invece, non è servito più di mezzo secondo per decidere.

Basta infatti rimuovere l’accesso a questo specifico file per prevenire gli attacchi di questi spiderbot, rinunciando alla possibilità di postare da remoto, a favore di una maggiore sicurezza.

Come farlo?

TRAMITE .htaccess

Inserendo questo codice nel nostro htaccess impedirai gli accessi all’xml-rpc prevenendo il problema. (clicca sulla foto per ottenere il codice)

Chiaramente nella stringa “allow from” puoi inserire un IP (il tuo ad esempio), che faccia eccezione a tale regola.

TRAMITE FTP

Se invece preferisci fare un’azione tanto bruta quanto efficace, senza dover toccare alcun altro file, puoi disabilitare tutti i permessi dell’xml-rpc tramite FTP.

Usando un gestore FTP, nel mio caso FileZilla, puoi revocare tutti gli accessi di Visualizzazione, Lettura e Scrittura.

Basta cliccare con il tasto destro sul file in questione e, nel menù a tendina, selezionare “permessi file”.

Nella finestra che comparirà, rimuovere tutte le spunte fino ad arrivare a “permessi 000“.

PER UN’ULTERIORE SICUREZZA

A questo punto, chiunque provi ad accedere a tale file, riceverà un “Error 403 – You don’t have permission to access /xmlrpc.php on this server.

Per aumentare ancor di più la sicurezza del tuo sito ed evitare sovraccarichi alla tua ram, puoi affidarti a dei plugin per la sicurezza (come ad esempio Wordfence, iThemes security o qualunque altro) per fare in modo che, dopo un certo numero di “error 403” tale IP venga sospeso temporaneamente (lockout) o bannato permanentemente dal tuo sito.

In questo modo, se pur dovessi continuare a ricevere attacchi, l’IP dello spider verrà rilevato ed escluso, onde evitare qualsiasi genere di problema.

INFINE

É doveroso ricordare che tale guida serve a prevenire attacchi futuri, mentre per riportare il tuo sito online dopo aver subito un attacco con Error establishing a database connection dovrai restartare il tuo database.

Inoltre il problema potrebbe essere di natura diversa, così come la soluzione potrebbe richiedere approcci diversi. A tal proposito non fai mai male ricordare, che state leggendo un blog di grafici e dunque, non per forza, di web-designer o programmatori.

Dunque, se hai trovato un modo migliore per ovviare il problema, se libero di rispondere o di inviare un messaggio e faremo sì che il tuo punto di vista possa essere altrettanto utile a tutti gli utenti e lettori di Roba da Grafici.

Commenta

Commenti

Simone Checchia
Simone Checchiahttps://www.checchiadesign.com
Creative Director di blueorange_design, docente di User Interface e Social Media. Adobe Certified Professional e Adobe Educator, a colazione mangio pane e Creative Cloud, innaffiati con molto caffè. Dirigo Roba da Grafici, la più grande community italiana sul design e la comunicazione visiva.
- Advertisment -