Hardening di wp-config.php: salt, costanti e permessi dei file

Il file wp-config.php contiene le credenziali del database, le chiavi che proteggono i cookie di accesso e le impostazioni che decidono cosa può fare WordPress. Dopo una pulizia è uno dei primi file da controllare e da rinforzare, insieme ai permessi del resto dell’installazione.

Controllare che sia pulito

Il malware modifica spesso wp-config.php perché viene caricato a ogni richiesta. Le modifiche tipiche sono un include di un file con un nome strano all’inizio del file, una riga lunghissima fuori dallo schermo, codice offuscato tra le costanti. Il confronto con wp-config-sample.php aiuta a capire quali righe sono standard. Vanno controllati anche i file .user.ini e php.ini nella cartella del sito, che con la direttiva auto_prepend_file possono far eseguire un file prima di qualunque altro.

Chiavi e salt

Le otto costanti di chiavi e salt, da AUTH_KEY a NONCE_SALT, servono a firmare i cookie di accesso. Se l’attacco ha letto wp-config.php, può in teoria costruire cookie validi senza conoscere nessuna password. Dopo ogni compromissione vanno quindi rigenerate:

wp config shuffle-salts

L’effetto collaterale è voluto: tutti gli utenti vengono disconnessi e devono accedere di nuovo. Insieme ai salt va cambiata la password del database, perché anche quella era nel file.

Costanti utili

Alcune costanti riducono ciò che un attacco può fare anche se ottiene un accesso da amministratore:

define( 'DISALLOW_FILE_EDIT', true );   // niente editor di temi e plugin
define( 'FORCE_SSL_ADMIN', true );      // amministrazione solo in HTTPS
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );    // errori mai mostrati ai visitatori
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

DISALLOW_FILE_EDIT toglie dall’amministrazione l’editor dei file, uno dei modi più rapidi per trasformare un login rubato in una backdoor. Esiste anche DISALLOW_FILE_MODS, che impedisce di installare e aggiornare plugin e temi dal pannello: è più restrittiva e ha senso solo se gli aggiornamenti vengono gestiti in altro modo, altrimenti il sito resta indietro con le correzioni di sicurezza.

Permessi e proprietà dei file

Il punto di partenza comune è 644 per i file e 755 per le cartelle, con wp-config.php più restrittivo, per esempio 640 o 600, secondo come il server web e PHP accedono ai file:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Ancora più dei permessi conta la proprietà. Se i file del sito appartengono allo stesso utente con cui gira PHP, qualunque codice eseguito da PHP, compreso quello di un plugin vulnerabile, può modificare tutti i file, core compreso. Una configurazione più robusta separa i due ruoli: i file appartengono a un utente di deploy, PHP può scrivere solo dove serve, cioè negli upload e nelle cartelle di cache. Il prezzo è che gli aggiornamenti dal pannello richiedono un passaggio in più, per esempio WP-CLI o un sistema di deploy. Su molti hosting condivisi questa separazione non è disponibile, e allora contano ancora di più le altre misure.

Il resto dell’hardening

wp-config.php è un tassello. Il quadro completo comprende il blocco dell’esecuzione di PHP negli upload, un utente del database con i soli privilegi necessari, l’autenticazione a due fattori per gli amministratori, aggiornamenti regolari e un monitoraggio delle modifiche ai file. Nessuna di queste misure rende un sito invulnerabile, ma insieme rendono un attacco molto più difficile e una reinfezione molto più visibile.