Quando un sito di un cliente va giù per un attacco, hai circa quindici minuti per contenere il danno prima che il cliente lo scopra da solo e ti chiami in panico. Quello che fai in quei quindici minuti determina se l’incidente diventa un problema gestito o una crisi che danneggia il rapporto con il cliente. Non esiste improvvisazione in questa fase: o hai un protocollo pronto o perdi tempo prezioso a capire da dove iniziare.
Questo articolo è quel protocollo. È costruito sull’esperienza diretta di gestione di incidenti su siti WordPress in produzione, con le lezioni apprese da situazioni che non sono andate come avrebbero dovuto. Non è teoria sulla sicurezza informatica: è la sequenza di azioni concrete da eseguire nell’ordine giusto quando il problema è già in corso.
Prima di tutto: capire cosa sta succedendo
La distinzione più importante da fare nei primi minuti è quella tra un attacco DDoS e un’infezione o compromissione del sito. Sono problemi diversi che richiedono risposte diverse.
Un attacco DDoS (Distributed Denial of Service) non compromette il sito: lo sommerge di traffico fino a renderlo irraggiungibile. Il sito è tecnicamente intatto ma non risponde perché il server è sovraccarico. L’attacco può durare minuti o giorni.
Una compromissione del sito significa che qualcuno ha avuto accesso non autorizzato: ha installato malware, iniettato codice, creato backdoor o rubato dati. Il sito può sembrare funzionante ma è stato modificato. Questo richiede un’analisi forense prima di qualsiasi altra azione.
Un ransomware su hosting condiviso è più raro ma esiste: il server viene cifrato e l’accesso ai file bloccato. In questo caso il problema è dell’hosting provider, non del sito specifico, e la risposta è diversa.
I segnali che distinguono i tre scenari: se il sito è irraggiungibile ma i file sono intatti e i log mostrano volumi anomali di traffico, è DDoS. Se il sito è raggiungibile ma mostra contenuti strani, reindirizza su altri siti o Google mostra warning “questo sito potrebbe essere dannoso”, è una compromissione. Se non riesci ad accedere all’hosting e il provider non risponde normalmente, valuta il ransomware.
Fase 1 — I primi 15 minuti: isolamento
L’obiettivo di questa fase è fermare il danno attivo senza perdere le prove di cosa sta succedendo.
Attiva la modalità manutenzione o Under Attack Mode su Cloudflare. Se il sito usa Cloudflare, vai su Security → Settings e attiva “Under Attack Mode”. Questa modalità aggiunge un challenge JavaScript a ogni visitatore prima di mostrare il sito, bloccando la maggior parte del traffico automatizzato malevolo in pochi secondi. Il sito rimane raggiungibile per gli utenti umani ma con un ritardo di cinque secondi. È la prima azione da fare su qualsiasi attacco DDoS su sito con Cloudflare attivo.
Se il sito non usa Cloudflare, attiva la modalità manutenzione di WordPress tramite un plugin dedicato o inserendo manualmente un file .maintenance nella root del sito. Non è efficace contro il DDoS a livello di rete ma blocca le richieste a livello applicativo e mostra al visitatore umano un messaggio controllato invece di un errore.
Identifica il tipo di attacco nei log. Accedi al pannello di hosting e cerca i log di accesso di Apache o Nginx degli ultimi trenta minuti. Cerca pattern anomali: migliaia di richieste allo stesso URL (tipicamente /wp-login.php, /xmlrpc.php o la homepage), tutte con lo stesso user-agent o da range IP simili. Questo è un attacco a livello applicativo. Se il server è irraggiungibile completamente, incluso il pannello di hosting, è un attacco a livello di rete che richiede l’intervento del provider.
Blocca le IP o i range di IP malevoli. Se il pattern mostra richieste massive da un range IP identificabile, blocca quel range nel firewall di Cloudflare o nel file .htaccess. Non è una soluzione definitiva ma riduce immediatamente il carico sul server. Una query semplice nei log di Nginx o Apache mostra le IP con più richieste negli ultimi trenta minuti: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20.
Scatta uno screenshot dello stato attuale. Prima di fare qualsiasi altra modifica, documenta tutto: screenshot della dashboard Cloudflare con i volumi di traffico anomali, screenshot dei log con i pattern identificati, stato del sito in quel momento. Se in futuro ci sarà bisogno di una segnalazione alle autorità o di una disputa assicurativa, questa documentazione è fondamentale.
Fase 2 — Da 15 a 30 minuti: analisi e contenimento
Con il danno immediato fermato o rallentato, si passa all’analisi per capire la portata reale dell’incidente.
Verifica se si tratta di DDoS o compromissione. Accedi al backend di WordPress se possibile e controlla: ci sono utenti amministratori che non dovrebbero esserci? Ci sono file PHP nella cartella uploads che non hai mai caricato? Ci sono plugin o temi attivati che non riconosci? Se sì, il sito è stato compromesso e il DDoS potrebbe essere una distrazione o una conseguenza del malware.
Esegui un primo scan di sicurezza. Se Wordfence è installato, esegui un scan immediato. Wordfence identifica i file modificati rispetto alla versione originale di WordPress e dei plugin e segnala i file sospetti. Sucuri Scanner e MalCare sono alternative valide se Wordfence non è installato. Non aspettare che lo scan sia completo per procedere: avvialo e vai avanti.
Verifica i backup disponibili. Identifica l’ultimo backup pulito del sito: quando è stato fatto, dove è conservato, come si ripristina. Se il sito è stato compromesso, potresti aver bisogno di un ripristino completo da un punto precedente all’infezione. Sapere dove si trovano i backup e quanto sono recenti in questa fase ti permette di valutare le opzioni senza perdere tempo dopo.
Registra tutto in un documento condiviso. Apri un documento e inizia a registrare: orario di scoperta del problema, azioni eseguite con timestamp, risultati dei check, stato del sito. Questo documento serve per la comunicazione interna al team, per la comunicazione al cliente e per l’analisi post-incidente.
Fase 3 — Da 30 a 60 minuti: comunicazione e risoluzione
Con la situazione contenuta e documentata, si passa alla comunicazione con il cliente e alla risoluzione definitiva.
Contatta il cliente prima che lo scopra da solo. Questa è la parte che fa la differenza tra un cliente che si fida di te e uno che non lo farà mai più. Non aspettare di aver risolto tutto per comunicare. Contattalo adesso, con le informazioni che hai: “Abbiamo rilevato un’anomalia sul tuo sito e stiamo intervenendo. Il sito è temporaneamente in modalità manutenzione per proteggere i dati. Ti aggiornerò tra trenta minuti con lo stato completo.”
Non usare la parola “attacco” se non sei ancora sicuro. Non fare promesse sui tempi di ripristino che potresti non rispettare. Sii specifico su cosa stai facendo e quando darai il prossimo aggiornamento.
Risolvi il problema identificato. Se è DDoS puro: con Cloudflare in Under Attack Mode il sito è già protetto. Valuta se alzare ulteriormente le protezioni con regole WAF specifiche per bloccare il traffico anomalo in modo più granulare. Contatta il provider di hosting per segnalare l’attacco e richiedere supporto a livello di rete se il volume supera quello che Cloudflare riesce a gestire.
Se è compromissione: non riavviare il sito prima di aver rimosso il malware. Ripristina da un backup pulito se il malware è esteso e difficile da identificare completamente. Se il backup è anch’esso compromesso, la rimozione manuale richiede un developer con esperienza in sicurezza WordPress.
Fai un report post-incidente entro 24 ore. Dopo la risoluzione, prepara un documento sintetico per il cliente: cosa è successo, come è stato gestito, cosa è stato fatto per prevenire che si ripeta. Non è un mea culpa: è la dimostrazione che hai il controllo della situazione e che stai proteggendo il suo sito in modo professionale. Le agenzie che fanno questo report costruiscono una fiducia che vale molto più del problema che hanno gestito.
Il caso che ci ha insegnato il valore del protocollo
Un’agenzia con cui lavoriamo gestiva l’ecommerce di un’azienda di abbigliamento durante il Black Friday. Alle 10:40 di venerdì mattina il sito è andato giù per un attacco DDoS a livello applicativo: migliaia di richieste al minuto verso /wp-login.php da centinaia di IP diversi. Il server dell’hosting era in ginocchio.
Il titolare dell’agenzia ci ha subito contattati e abbiamo subito attivato il protocollo. Alle 10:49 avevamo attivato Under Attack Mode su Cloudflare. Alle 10:52 avevamo identificato il pattern nei log e bloccato i range IP principali. Alle 10:55 avevamo inviato un messaggio al titolare dell’agenzia che ha subito contattato così il cliente: “Stiamo gestendo un picco anomalo di traffico. Il sito è temporaneamente rallentato ma funzionante. Ti aggiorno alle 11:30.”
Alle 11:23 il sito era completamente operativo. Il cliente aveva perso circa 35 minuti di traffico ridotto ma non c’era stato nessun downtime completo. La comunicazione proattiva aveva trasformato una potenziale crisi in una dimostrazione di competenza. Il cliente ha rinnovato il contratto di manutenzione aumentando il canone mensile.
La differenza tra quel risultato e uno scenario catastrofico era il protocollo pronto. Non la bravura nell’improvvisare.
Quando serve un supporto esterno per gestire un attacco
Non tutte le agenzie o le aziende hanno al proprio interno le competenze e le risorse necessarie per intervenire rapidamente quando un sito viene compromesso o finisce sotto attacco. È una situazione più comune di quanto si pensi: spesso veniamo contattati da agenzie che gestiscono decine di siti WordPress per conto dei propri clienti e che si trovano ad affrontare un’emergenza fuori dall’ordinario, oppure da aziende e professionisti che scoprono un problema quando il sito è già offline o segnalato come pericoloso dai motori di ricerca.
In questi casi il fattore più importante non è soltanto risolvere il problema tecnico, ma farlo nel minor tempo possibile limitando il danno economico e reputazionale. Un sito ecommerce fermo durante una campagna marketing, un portale aziendale irraggiungibile o un sito infettato da malware possono generare conseguenze significative già nelle prime ore.
Per questo motivo interveniamo sia in modalità emergenziale sia attraverso attività preventive di monitoraggio e manutenzione. Analizziamo l’origine dell’attacco, individuiamo eventuali vulnerabilità sfruttate, ripristiniamo il corretto funzionamento del sito e implementiamo le misure necessarie per ridurre il rischio che l’incidente si ripeta. Quando richiesto, supportiamo anche l’agenzia nella comunicazione con il cliente finale e nella preparazione della documentazione tecnica post-incidente.
Molti dei clienti che oggi seguiamo in modo continuativo ci hanno inizialmente contattato proprio durante una situazione critica. La differenza tra un disservizio temporaneo e una crisi che compromette il rapporto con il cliente spesso dipende dalla rapidità con cui viene attivata una procedura di risposta efficace.
Se gestisci siti WordPress per conto di clienti o hai bisogno di un supporto specialistico per un sito sotto attacco, puoi contattarci per una valutazione immediata della situazione e delle possibili azioni da intraprendere.
Come prevenire che si ripeta
Un attacco gestito bene è anche un’opportunità per strutturare meglio la sicurezza del sito per il futuro.
Le misure che implementiamo sistematicamente dopo ogni incidente: Cloudflare attivo con regole WAF per bloccare le richieste massive a /wp-login.php e /xmlrpc.php, autenticazione a due fattori su tutti gli account amministratori WordPress, accesso al backend limitato per IP quando possibile, backup giornalieri automatici conservati fuori dall’hosting del sito, monitoraggio uptime con alerting immediato via SMS.
Noi di Blurr includiamo tutte queste misure nei siti che sviluppiamo e manteniamo per le agenzie partner. Non come servizio aggiuntivo: come parte del processo standard di consegna. Su blurr.it/servizi/ trovi come strutturiamo la sicurezza su ogni progetto. Per approfondire cosa succede a un sito senza monitoraggio attivo, leggi cosa succede a un sito web senza monitoraggio: un caso reale. Per capire come strutturiamo i piani di manutenzione che includono la gestione degli incidenti, leggi l’articolo dedicato.
FAQ
Come capire se un sito WordPress è sotto attacco DDoS o è stato compromesso? Se il sito è irraggiungibile ma i file sono intatti e i log mostrano volumi anomali di traffico da molti IP diversi, è quasi certamente un DDoS. Se il sito è raggiungibile ma mostra contenuti insoliti, reindirizza verso altri URL o Google mostra avvisi di sicurezza, è una compromissione. I due problemi possono coesistere: un sito compromesso può essere usato come origine di un DDoS verso altri siti.
Cosa fare immediatamente se il sito di un cliente viene attaccato? Prima azione: attivare Under Attack Mode su Cloudflare se disponibile, o la modalità manutenzione di WordPress. Seconda: identificare il tipo di attacco nei log. Terza: bloccare i range IP malevoli identificati. Quarta: documentare tutto con timestamp. Quinta, e non meno importante: contattare il cliente con un aggiornamento proattivo prima che scopra il problema da solo. L’ordine di queste azioni determina il risultato dell’incidente.
Cloudflare Under Attack Mode blocca anche i visitatori normali? Aggiunge un challenge JavaScript della durata di circa cinque secondi a ogni nuovo visitatore. Gli utenti umani superano il challenge automaticamente dopo pochi secondi. I bot automatici che non eseguono JavaScript vengono bloccati. Il sito rimane accessibile ma con un leggero ritardo. È una misura temporanea da disattivare non appena l’attacco è contenuto.
Quanto tempo ci vuole per ripristinare un sito WordPress dopo un attacco? Dipende dalla tipologia. Un DDoS gestito con Cloudflare si contiene in meno di trenta minuti nella maggior parte dei casi. Una compromissione con malware richiede da due a otto ore per un’analisi e pulizia completa, o meno se si ripristina da un backup pulito recente. Un sito senza backup recente e con malware esteso può richiedere uno o due giorni di lavoro. È questo il motivo per cui i backup giornalieri automatici fuori dall’hosting non sono un’opzione: sono il prerequisito di qualsiasi piano di sicurezza sensato.