Log di sicurezza WordPress: cosa monitorare, come e perché un audit trail vale più di tre plugin di sicurezza

La domanda che ci fanno più spesso dopo un'intrusione è: quando è successo? E la risposta, nella maggior parte dei casi, è che non lo sappiamo con precisione. Il sito è stato compromesso, il malware era lì da settimane, ma nessuno se n'è accorto perché nessuno stava guardando. È qui che un audit trail fa la differenza: non previene l'attacco, ma ti dice esattamente quando è iniziato, cosa è stato toccato, e quanto si è diffuso. Senza log, stai lavorando al buio.

Il paradosso è che quasi tutti i siti WordPress hanno un plugin di sicurezza installato — ma pochi hanno un sistema di log vero. Un plugin di sicurezza scansiona i file e blocca i pattern noti, ma non ti dice chi ha fatto login alle 3 di notte da un IP russo, né che file sono stati modificati nella cartella uploads nelle ultime 48 ore. Quelle informazioni le dai per scontate finché non ti servono, e quando ti servono non le hai.

I cinque log che un sito WordPress dovrebbe sempre avere

Non serve loggare tutto — serve loggare le cose che ti dicono cosa è successo. Il primo è il log dei login: chi, quando, da che IP, con che esito. WordPress non lo registra di default, ma è il primo segnale di un attacco brute force o di un account compromesso. Il secondo è il log delle modifiche ai file: qualsiasi file modificato nella cartella wp-content, nei plugin, nei temi, o peggio nei file del core. Il terzo è il log degli accessi admin: ogni pagina di wp-admin visitata, da chi, da dove.

Il quarto è il log delle query sensibili: modifiche agli utenti, cambi di ruolo, creazione di nuovi amministratori, modifiche alle opzioni di sicurezza. Il quinto — e spesso il più trascurato — è il log dei fallimenti: login falliti, tentativi di accesso a file protetti, richieste bloccate dal WAF. I fallimenti sono dove gli attaccanti fanno prove prima di trovare il modo di entrare.

Il primo log da attivare è quello dei login. Puoi registrarlo con un piccolo snippet nel file functions.php del tema child:

// Registra ogni tentativo di login (successo e fallimento)
add_action( 'wp_login', 'log_successful_login', 10, 2 );
add_action( 'wp_login_failed', 'log_failed_login' );

function log_successful_login( $user_login, $user ) {
    $log = sprintf(
        '[%s] LOGIN OK user=%s id=%d ip=%s ua=%s',
        current_time( 'mysql' ),
        $user_login,
        $user->ID,
        $_SERVER['REMOTE_ADDR'] ?? 'unknown',
        $_SERVER['HTTP_USER_AGENT'] ?? 'unknown'
    );
    // Salva in un file fuori dalla root pubblica, o su un syslog
    file_put_contents( WP_CONTENT_DIR . '/../logs/security.log', $log . "\n", FILE_APPEND );
}

function log_failed_login( $username ) {
    $log = sprintf(
        '[%s] LOGIN FAIL user=%s ip=%s ua=%s',
        current_time( 'mysql' ),
        $username,
        $_SERVER['REMOTE_ADDR'] ?? 'unknown',
        $_SERVER['HTTP_USER_AGENT'] ?? 'unknown'
    );
    file_put_contents( WP_CONTENT_DIR . '/../logs/security.log', $log . "\n", FILE_APPEND );
}

Dove conservare i log (e dove no)

L'errore più grave che vediamo è conservare i log sullo stesso server del sito. Se un attaccante compromette WordPress, ha accesso al filesystem — e il primo cosa che fa un malware è cancellare i log per coprire le tracce. I log di sicurezza devono stare altrove: su un syslog esterno, su un servizio di log management, o almeno su un server separato a cui WordPress ha accesso solo in scrittura.

La regola operativa è semplice: il sito scrive i log, ma non può leggerli né cancellarli. Questo significa un syslog remoto, un servizio come un log aggregator, o nella pratica più semplice per i siti gestiti, un sistema di monitoraggio che raccoglie i log via API o SSH e li conserva su infrastruttura separata. Se i log sono sullo stesso server del sito, non sono un audit trail — sono un file che l'attaccante può modificare.

Il monitoraggio che avvisa prima del danno

Avere i log non serve a nulla se nessuno li guarda. Il punto è trasformare i log in allerte: un login admin da un IP nuovo, una modifica ai file del core, un nuovo utente amministratore creato, un picco di login falliti dallo stesso IP. Ognuno di questi eventi è un segnale che qualcosa sta succedendo — e se lo vedi in tempo, puoi intervenire prima che diventi un'intrusione completa.

Il monitoraggio può essere semplice o sofisticato. Il minimo è un controllo giornaliero dei login admin e delle modifiche ai file. Il livello successivo è un sistema che confronta i file del core con i checksum ufficiali di WordPress e segnala qualsiasi discrepanza:

# Verifica l'integrità dei file del core WordPress
# Scarica i checksum ufficiali per la versione installata
wp core verify-checksums

# Output atteso: 'Success: WordPress installation verifies against checksums.'
# Se vedi 'Warning: File modified' o 'Error: checksums do not match',
# un file del core è stato alterato — possibile intrusione.

# Per un controllo più completo, confronta tutti i file
wp core verify-checksums --version=6.9 --locale=en_US

# Automatizza con cron: ogni notte alle 4
# 0 4 * * * wp core verify-checksums --path=/var/www/html 2>&1 | mail -s "WP checksum alert" admin@example.com

Il test che ti dice se il tuo monitoraggio funziona

Il modo migliore di sapere se il tuo sistema di log funziona è testarlo. Crea un utente amministratore di test, fai un login da un IP diverso, modifica un file del core (poi ripristinalo), e verifica che ognuno di questi eventi sia registrato. Se non vedi l'evento nei log, il tuo monitoraggio ha un buco — meglio scoprirlo in un test che durante un'intrusione reale.

Un audit trail non previene gli attaczi, ma li rende gestibili. Senza log, un'intrusione è un problema opaco: non sai quando è iniziata, cosa è stato toccato, quanto si è diffuso. Con i log, sai esattamente cosa è successo e puoi intervenire con precisione — ripristinare i file compromessi, chiudere gli account compromessi, bloccare gli IP malevoli. La differenza tra un danno contenuto e un disastro completo, spesso, è proprio questo: sapere cosa è successo.