Ore 23:47, sabato sera: il sito è stato bucato

Era sabato sera, quasi mezzanotte. Stavo guardando un film quando il telefono ha iniziato a squillare. Numero sconosciuto. Di solito non rispondo, ma qualcosa mi ha fatto cambiare idea.

Dall'altra parte c'era Marco, titolare di un e-commerce di prodotti artigianali che avevo realizzato due anni prima. Voce concitata: "Alex, il sito mostra roba strana. Ci sono pagine che non ho mai creato, vendono orologi e borse di lusso. Cosa sta succedendo?"

Ecco, quello era il momento. Il sito era stato hackerato.

I primi cinque minuti sono cruciali

Ho chiesto a Marco di mandarmi uno screenshot mentre mi collegavo in VPN. Appena aperto il browser, ho capito la situazione: defacement classico con iniezione di pagine spam per SEO poisoning. Qualcuno aveva compromesso il sito e inserito centinaia di pagine fake per posizionarsi su Google con query commerciali ad alto valore.

Prima cosa: ho messo il sito in modalità manutenzione. Non è elegante, ma quando hai un'emorragia devi tamponare subito. I visitatori vedevano una pagina "Torniamo presto", mentre io potevo lavorare senza che il danno si espandesse.

Seconda cosa: ho cambiato tutte le password. FTP, database, pannello hosting, WordPress admin. Tutto. Con password generate random di 24 caratteri. Marco era ancora al telefono, nervoso, mi chiedeva quanto tempo ci sarebbe voluto. Gli ho detto la verità: "Non lo so ancora, ma prima sistemiamo, poi dormiamo".

La caccia al punto di ingresso

Qui inizia la parte da detective digitale. Gli hacker erano entrati da qualche parte, dovevo capire da dove. Ho scaricato tutti i log del server degli ultimi sette giorni e ho iniziato a controllare.

Nel file access.log ho trovato richieste POST anomale a un file chiamato wp-config-sample.php. Strano, quel file è innocuo, è solo un esempio di configurazione che WordPress include di default. Sono andato a controllare via SSH: il file era stato modificato. Conteneva codice PHP malevolo camuffato.

L'attaccante aveva sfruttato un plugin obsoleto per caricare una backdoor. Da lì aveva pieno accesso al filesystem. Classico.

Ho eliminato il file compromesso, poi ho fatto una scansione completa con Wordfence via CLI (la versione web era troppo lenta). Risultato: 247 file modificati. Plugin, temi, persino alcuni file core di WordPress. Un casino totale.

Ripulire o reinstallare?

A questo punto avevo due opzioni. La prima: ripulire manualmente ogni file compromesso, confrontandolo con l'originale. Operazione lunga, rischiosa, perché basta dimenticarne uno per lasciare la porta aperta.

La seconda: reinstallare tutto da zero. Core di WordPress, tema, plugin. Recuperare il database, ripulirlo dalle tabelle fake (ne avevano create una ventina), e ripartire.

Ho scelto la seconda. Più drastica, ma più sicura. Per fortuna avevo i backup automatici attivi (ogni notte alle 3), quindi ho recuperato il database di tre giorni prima, quando il sito era ancora pulito. Ho perso qualche ordine recente, ma Marco ha confermato che erano solo due e li aveva già evasi.

Verso le 4 del mattino, il sito era di nuovo online. Pulito, veloce, sicuro. Ho implementato un firewall applicativo (Cloudflare nella modalità gratuita va benissimo) e configurato regole più restrittive sul server. Ho anche disabilitato l'editor dei file dal backend WordPress, perché se un attaccante arriva lì, non deve poter modificare il codice direttamente.

Le lezioni di quella notte

Da quell'episodio ho cambiato il mio approccio alla realizzazione siti web a Trento e ovunque. Prima consideravo la sicurezza come un optional da aggiungere dopo, ora è parte integrante fin dal primo giorno.

Tutti i siti che sviluppo oggi hanno:

• Backup automatici giornalieri con retention di 30 giorni, salvati fuori dal server
• Aggiornamenti automatici di sicurezza per WordPress core e plugin critici
• Plugin di sicurezza (Wordfence o Sucuri) configurati in modo aggressivo
• Autenticazione a due fattori per tutti gli utenti amministratori
• Firewall applicativo (WAF) attivo, anche solo il tier gratuito di Cloudflare fa differenza
• Monitoraggio uptime con alert via email e SMS
• Log centralizzati con retention di 90 giorni

Ma soprattutto: ho iniziato a educare i clienti. Marco pensava che la sicurezza fosse "roba da informatici". Gli ho spiegato che il suo sito era come un negozio fisico: se non chiudi la porta a chiave, qualcuno prima o poi entra. Non per rubare, magari solo per lasciare volantini pubblicitari (le pagine spam), ma il risultato è lo stesso: il tuo spazio viene violato.

Oggi quando sviluppo un e-commerce a Trento o un gestionale web, la sicurezza è parte del preventivo. Non è un costo aggiuntivo, è un requisito base. Come le fondamenta di una casa.

I segnali che qualcosa non va

Con l'esperienza ho imparato a riconoscere i segnali. Se il tuo sito WordPress improvvisamente rallenta, se Google Search Console ti segnala pagine che non hai mai creato, se ricevi email di password reset che non hai richiesto, se il traffico nel pannello analytics impenna senza motivo, sono tutti campanelli d'allarme.

Un altro sintomo classico: il sito viene blacklistato da Google o dai browser. Chrome mostra "Il sito che stai per visitare contiene malware". A quel punto il danno reputazionale è fatto, recuperare è dura.

Marco è stato fortunato: se ne è accorto in poche ore. Ho visto casi dove il sito era compromesso da settimane, magari con un cryptominer nascosto che usava la CPU dei visitatori per minare criptovalute. Il proprietario non se ne accorgeva perché il sito funzionava normalmente.

Quanto costa non essere preparati

Quella notte è costata a Marco circa 8 ore del mio tempo in emergenza, quindi un costo non previsto. Più il danno indiretto: il sito è stato offline per alcune ore proprio nel weekend, periodo di picco per le vendite. Ha perso ordini, ha perso posizioni su Google per qualche settimana (le pagine spam avevano inquinato l'indicizzazione), e soprattutto ha perso serenità.

Ora ha un contratto di manutenzione mensile che include monitoraggio, backup, aggiornamenti, e assistenza prioritaria. Costa meno di una cena fuori al mese, e dorme sonni tranquilli.

Per chi sviluppa software gestionale su misura come me, la sicurezza è ancora più critica. Un gestionale contiene dati sensibili, anagrafiche clienti, documenti contabili. Se quello viene compromesso, il danno può essere devastante, anche dal punto di vista legale con il GDPR.

Quella notte mi ha insegnato che la sicurezza non è un prodotto che installi, è un processo continuo. Oggi uso checklist pre-lancio per ogni progetto, con 47 punti di controllo. Sembra esagerato, ma dopo aver visto un sito hackerato alle 23:47 di sabato sera, preferisco esagerare.

Se gestisci un sito web o un e-commerce e non hai un piano di disaster recovery, parliamone. Non aspettare la telefonata alle 23:47 di un sabato sera. Credetemi, preferirei continuare a guardare il film.