Proteggere un sito WordPress con n8n: monitoraggio integrità, alert e risposta

Perché monitorare WordPress con n8n

Chi gestisce siti WordPress per clienti sa come va davvero la maggior parte delle compromissioni: il malware resta lì per settimane, nessuno se ne accorge, e quando qualcuno se ne accorre le evidenze per capire da dove è entrato sono ormai compromesse.

Il problema quasi mai è la mancanza di strumenti: è che nessuno guarda. Un controllo di integrità giornaliero che genera un messaggio Telegram letto ogni mattina vale più di una suite di sicurezza con dieci notifiche non aperte.

n8n è perfetto per questo ruolo: orchestrazione pianificata, integrazione SSH e API, notifiche dove il team le legge davvero. In questa guida costruiamo un sistema di monitoraggio completo per un sito WordPress, con quattro controlli e una logica di escalation chiara.

Cosa monitorare, in ordine di importanza

Prima dei workflow, il quadro dei controlli che contano:

Controllo	Cosa rileva	Frequenza consigliata
Checksum del core WordPress	File del core modificati o aggiunti	Giornaliera
Nuovi file PHP in uploads e wp-content	Webshell appena depositate	Giornaliera
Utenti amministratori	Account fantasma creati dall'attaccante	Giornaliera
Login falliti e tentativi su xmlrpc	Brute force e credential stuffing in corso	Ogni ora su siti esposti

Noti cosa manca? La scansione antivirus. Gli scanner a firme trovano i malware noti, ma le webshell custom sfuggono. Il monitoraggio di integrità ragiona per anomalie: non sa cos'è il malware, ma sa quando qualcosa è cambiato.

Prerequisiti

• Un'istanza n8n self-hosted raggiungibile (se ti serve una base, c'è la guida su come iniziare con n8n)
• Accesso SSH al server del sito WordPress, con un utente dedicato di sola lettura diagnostica (mai root, mai l'utente del deploy)
• WP-CLI installato sul server
• Un canale notifiche: Telegram è ideale (nodo nativo, notifiche che si leggono davvero)

Workflow 1: controllo di integrità giornaliero

Il cuore del sistema. Schedule Trigger ogni mattina alle 7, poi SSH sul server:

cd /var/www/sito-cliente
wp core verify-checksums 2>&1

Il comando confronta i file del core con gli hash ufficiali pubblicati da WordPress. Output pulito: Success: WordPress installation verifies against checksums. Qualsiasi altra cosa elenca file modificati o sconosciuti.

Nel workflow n8n:

1. Schedule Trigger (cron: 0 7 * * *)
2. SSH Node con il comando sopra
3. IF Node: l'output contiene "Success"?
4. Se false: messaggio Telegram con l'output completo
5. Se true: opzionale, log silenzioso su Google Sheets o database per storicità

Un dettaglio che fa la differenza in caso di incidente: salva sempre l'output dei check, anche quelli puliti. Quando un cliente ti chiama "il sito si comportava strano da due settimane", avere la serie storica dei checksum ti dice esattamente il giorno in cui qualcosa è cambiato.

Workflow 2: caccia ai file PHP nei percorsi dove non devono stare

In wp-content/uploads non deve esistere nemmeno un file PHP. È la directory degli upload, eseguibile per definizione del web server: la prima meta delle webshell. Stesso discorso per la radice di wp-content con nomi generici.

Secondo workflow, giornaliero:

find /var/www/sito-cliente/wp-content/uploads \
     -name "*.php" -o -name "*.phtml" 2>/dev/null
find /var/www/sito-cliente -maxdepth 1 \
     -name "*.php" -newer /var/www/sito-cliente/wp-config.php 2>/dev/null

La seconda riga merita una spiegazione: segnala i file PHP nella radice del sito modificati dopo wp-config.php, cioè dopo l'ultimo intervento legittimo noto. È un filtro grezzo ma efficace contro i dropper con nomi innocui.

In n8n: Schedule Trigger, SSH, Filter (righe non vuote), IF con conteggio maggiore di zero, alert Telegram con l'elenco dei file e i loro timestamp (ls -la sugli stessi path come secondo comando SSH, così l'alert è già azionabile).

Workflow 3: sentinella sugli utenti amministratori

Le backdoor più semplici sono un utente admin con password propria. Il controllo è banale ma solo se lo automatizzi:

wp user list --role=administrator --format=csv

Il workflow confronta l'elenco attuale con una baseline: la lista degli amministratori legittimi, conservata in un campo delle credenziali o in un file su n8n. Se compaiono righe nuove, alert immediato con priorità massima.

Variante consigliata per siti con più autori: alert solo sui nuovi admin, log silenzioso su tutto il resto. Eviti il rumore e tieni la storia delle iscrizioni legittime.

Workflow 4: picchi di login falliti e xmlrpc

Controllo orario solo per siti esposti e con login pubblico. Nei log di accesso (Apache/Nginx):

grep "wp-login.php" /var/log/nginx/access.log | grep " POST " | \
  awk -F'"' '{print $1}' | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

Se un IP supera la soglia (per esempio 30 tentativi in un'ora), alert con l'IP. Qui n8n aggiunge valore oltre all'alert: puoi collegare un nodo HTTP verso l'API del firewall o di Cloudflare per bloccare l'IP in automatico. Consiglio di mantenere il blocco manuale all'inizio: gli automatismi di blocco vanno tarati sui falsi positivi prima che sugli attacchi.

La logica di escalation: cosa fare quando scatta l'alert

L'alert è l'inizio di un processo, non la fine. La sequenza che consiglio di scrivere nero su bianco (e di incollare nel canale Telegram stesso):

1. Congela: backup completo di file, database e log dello stato attuale, prima di ogni modifica
2. Non cancellare: i file sospetti sono evidenze; tolti alla cieca, il vettore d'ingresso resta e la reinfezione arriva
3. Valuta l'impatto: sito che vende? Il checkout va verificato subito (script estranei nelle pagine di pagamento)
4. Escalation: se il check di integrità è fallito o ci sono file PHP negli upload, servono competenze di analisi forense, non un plugin

Per costruire i workflow di risposta e bonifica quando l'alert conferma il peggio, il metodo passo per passo è descritto nella guida alla bonifica malware WordPress di WPsec.it, che applica esattamente questa sequenza congelamento, analisi, rimozione su ambienti controllati. E se il monitoraggio ti serve ma non hai il tempo di gestirlo, esiste un servizio di automazioni WordPress con n8n già pronto, con guardrail e report.

Limiti onesti di questo setup

Tre cose che questo monitoraggio NON fa, così nessuno se le aspetta a torto:

• Non previene: un plugin vulnerabile sfruttato con CVE pubblica entra lo stesso. Il monitoraggio accorcia il tempo di permanenza del malware, che è la variabile su cui puoi agire
• Non bonifica: rimuovere backdoor dal database e dai cron richiede metodo e strumenti che un workflow non ha
• Non sostituisce gli aggiornamenti: il controllo di integrità che suona ogni giorno su un sito con plugin obsoleti da mesi è un fumo d'allarme permanente, e i sistemi che suonano sempre vengono disattivati

Il giusto ordine resta: aggiornamenti gestiti, hardening essenziale, e il monitoraggio di questa guida come rete di rilevamento su quello che passa.

In sintesi

Quattro workflow, un pomeriggio di setup, e da domani mattina sai se i siti che gestisci sono integri prima del caffè. La combinazione Schedule Trigger, SSH e Telegram copre l'80 percento del valore del monitoraggio WordPress: checksum, file anomali, utenti, brute force. Il restante 20 percento, la risposta all'incidente, vuole metodo umano: meglio avere l'alert e sapere a chi chiamare che avere una suite che nessuno legge.