Alle 3 di notte: quando un cliente mi chiama per un hack

Erano le tre e mezza di notte quando il telefono ha squillato. Numero sconosciuto. Ho quasi ignorato la chiamata, ma qualcosa mi ha fatto scorrere il dito sul verde. Dall'altra parte, la voce concitata di Marco, titolare di un e-commerce di prodotti per la montagna che avevo realizzato due anni prima.

"Alex, il sito... c'è scritto che vendiamo Viagra. Ovunque. E ci sono file strani nel server."

Mi sono seduto di colpo sul letto. Quella frase ha fatto scattare tutti gli allarmi. Il sito era stato compromesso.

I primi cinque minuti di panico controllato

Mentre Marco continuava a parlarmi, ho già acceso il computer. Prima regola quando succede: mantieni la calma e agisci veloce. Il panico non serve a nessuno, tantomeno al cliente che ha il suo business online che mostra pubblicità di farmaci contraffatti.

Ho fatto login via SSH al server. Primo controllo: i file modificati di recente. Eccoli là: una serie di file PHP con nomi apparentemente innocui nascosti in sottocartelle di WordPress. wp-includes/wp-class.php, wp-content/themes/twentytwenty/inc/template.php. Classici.

"Marco, ora metto il sito in manutenzione. Nessuno lo vedrà per le prossime ore. Dormi, domattina ti dico tutto."

Non ha dormito, ne sono sicuro. Nemmeno io.

Cosa era successo davvero

All'alba avevo il quadro completo. Il sito girava su WordPress, versione non aggiornata da otto mesi. Otto. In quel periodo erano uscite tre patch di sicurezza critiche. Una di queste riguardava proprio un plugin per le recensioni che Marco aveva installato tempo prima.

Gli hacker erano entrati da lì. Una volta dentro, avevano installato una backdoor – un file che gli permetteva di accedere quando volevano – e poi avevano modificato il database per iniettare contenuti spam in tutte le pagine. Il sito era diventato un hub per vendere prodotti illegali, sfruttando il buon posizionamento SEO che Marco aveva costruito in anni.

La cosa peggiore? Non era solo il contenuto visibile. Avevano anche creato migliaia di pagine nascoste, visibili solo ai motori di ricerca, piene di link a siti farmaceutici. Google aveva già iniziato a penalizzarlo nelle ricerche.

Diciamocelo: questa è la telefonata che ogni sviluppatore teme. Perché quando succede, è sempre urgente, sempre nel weekend o di notte, e il cliente – giustamente – è nel panico totale.

La ricostruzione (e le notti insonni)

Ho passato due giorni pieni a pulire tutto. Non è un lavoro che puoi fare in un'ora, quando l'infezione è profonda. Ecco cosa ho fatto, nell'ordine:

Backup del disastro. Prima di toccare qualsiasi cosa, ho fatto un backup completo dello stato compromesso. Sembra controintuitivo, ma se qualcosa va storto durante la pulizia, devi poter tornare indietro. E serve anche come evidenza se devi fare analisi forensi.

Identificazione di tutti i file modificati. Con un comando find ho estratto tutto ciò che era stato toccato negli ultimi 30 giorni. Centinaia di file. Li ho confrontati uno per uno con una installazione pulita di WordPress della stessa versione. Un lavoro da certosino.

Pulizia del database. Qui è dove si nasconde il grosso. Tabelle WordPress con righe iniettate, campi modificati, utenti amministratori fantasma. Ho scritto query SQL per individuare anomalie e le ho eliminate manualmente. Non mi fido degli script automatici per queste cose.

Reinstallazione completa. Core di WordPress, tutti i plugin, il tema. Tutto reinstallato da zero, con le ultime versioni disponibili. I file personalizzati (come template specifici che avevo sviluppato) li ho riscritti da zero partendo dai sorgenti puliti del mio repository Git locale.

Cambio di tutte le password. Database, FTP, SSH, pannello hosting, email, WordPress admin. Tutto. E non password semplici: 32 caratteri random generati da un password manager. Ho anche attivato l'autenticazione a due fattori dove possibile.

Le lezioni che ho imparato (a caro prezzo)

Quel caso mi ha insegnato cose che ora applico a ogni sito web che realizzo a Trento e ovunque. Perché la verità è questa: non è questione di se qualcuno proverà a entrare, ma di quando.

Da allora, ho cambiato radicalmente approccio. Ogni mio cliente riceve un piano di manutenzione che include aggiornamenti settimanali automatici per patch di sicurezza. Non aspetto che me lo chiedano, è incluso nel pacchetto. Punto.

Ho anche iniziato a usare strumenti di monitoraggio attivo. Servizi come Wordfence per WordPress, ma anche monitoring personalizzati con script che mi avvisano se file critici vengono modificati. Una volta mi hanno salvato: un tentativo di accesso alle 2 di notte, bloccato e notificato in tempo reale.

Per i progetti più critici – specialmente per e-commerce o software gestionali che gestiscono dati sensibili – ho iniziato a implementare WAF (Web Application Firewall) a livello di server. Non è economico, ma quando gestisci dati di pagamento o informazioni personali, non puoi risparmiare.

Un altro cambiamento: backup giornalieri automatici, conservati per almeno 30 giorni, su storage separato dal server principale. Se il server viene compromesso, i backup devono essere al sicuro altrove. Sembra ovvio, ma ho visto situazioni dove il backup era nella stessa macchina compromessa. Inutile.

Cosa fare se succede anche a te

Se un giorno ti svegli e scopri che il tuo sito è stato hackerato, ecco il mio consiglio pratico, nato dall'esperienza diretta:

Non cancellare nulla subito. Lo so, l'istinto è eliminare tutto ciò che sembra sospetto. Resistete. Prima fate un backup completo dello stato attuale. Vi servirà per capire come sono entrati e assicurarvi di aver pulito tutto.

Mettete il sito offline immediatamente. Pagina di manutenzione, redirect temporaneo, quello che volete. Ma non lasciate online un sito compromesso che danneggia la vostra reputazione e quella dei vostri visitatori.

Cambiate tutte le password. Tutte. Hosting, database, FTP, email associate al dominio, account admin. Se usate la stessa password altrove (cosa che spero non facciate), cambiatela anche lì.

Controllate il file .htaccess e wp-config.php. Sono i primi file che gli hacker modificano. Confrontateli con una versione pulita. Cercate redirect strani, include nascosti, codici base64 encoded.

Chiamate qualcuno che sa cosa fare. Se non avete competenze tecniche approfondite, non improvvisate. Un sito compromesso male pulito è peggio di uno lasciato offline. Gli hacker lasciano backdoor multiple, proprio per questo. Ne trovate una, ne rimangono tre.

Il finale (meno drammatico di quanto sembri)

Il sito di Marco è tornato online dopo tre giorni. Pulito, aggiornato, sicuro. Abbiamo anche colto l'occasione per migrare a un hosting più performante con firewall dedicato. Gli ho fatto un restyling leggero dell'interfaccia, già che c'eravamo.

Google ci ha messo due settimane a rimuovere completamente la penalizzazione. Ho dovuto usare Search Console per segnalare la rimozione dei contenuti malevoli e richiedere una riconsiderazione. Ma alla fine, il posizionamento è tornato quello di prima.

Marco ora ha un contratto di manutenzione mensile. Costa meno di una cena fuori, e gli garantisce che io controllo tutto ogni settimana. Aggiornamenti, backup, monitoring. Dorme meglio. Anch'io.

Quella notte alle tre e mezza mi ha insegnato più di mille corsi online. La sicurezza web non è un optional, non è qualcosa da rimandare. È la base. Perché quando ti chiamano alle tre di notte, vuoi essere sicuro di avere già fatto tutto il possibile per prevenire.

Se hai un sito – vetrina, e-commerce, blog personale, quello che vuoi – e non ricordi quando è stato aggiornato l'ultima volta, questo è il momento di controllare. Sul serio. Non aspettare la telefonata notturna.

E se ti serve una mano per mettere in sicurezza il tuo progetto web, o per costruire qualcosa di solido fin dall'inizio, scrivimi. Ti prometto che risponderò anche se mi chiami alle tre di notte. Ma spero davvero che non sarà necessario.