Account di hosting violato: riconoscere l'attacco e rispondere

Lo scenario è sempre lo stesso, e si presenta di mattina presto: il sito non si vede, oppure si vede fin troppo — annunci di farmacie, redirect verso pagine sospette, un avviso del browser che dichiara il dominio pericoloso. L'account di hosting condiviso è stato violato. Il panico è una reazione comprensibile ma controproducente: ciò che serve è un protocollo. Questa guida lo attraversa per intero, dai segnali alla bonifica, perché nella gestione di una compromissione la rapidità e l'ordine contano più della vulnerabilità che l'ha causata.

I segnali che qualcosa non va

• Redirect solo dai motori: il sito diretto funziona, ma dai risultati di ricerca si finisce altrove — cloaking classico, progettato per ingannare i controlli del proprietario;
• file mai visti: script nella cartella degli upload, file con nomi casuali, pagine nuove in lingue straniere;
• codice iniettato: righe cifrate in fondo a index.php o agli header del tema, eval e stringhe base64 dove non devono esserci;
• avvisi di Safe Browsing: il browser o la Search Console segnalano il dominio;
• email di rimbalzo: coda di messaggi inviati dal server che non avete mai spedito — spam di posta in gioco;
• carico anomalo: CPU del piano condiviso saturata da processi web.

Come avvengono le intrusioni

Quasi mai per magia tecnica. Le vie principali: credenziali deboli o rubate (FTP a testo chiaro, password riutilizzate finite in fughe di dati); CMS trascurati, con plugin non aggiornati o abbandonati — il vettore più frequente, trattato nella guida ai WordPress compromessi; il computer locale del webmaster infetto che intercetta le password; più raramente il vicino di macchina sul server condiviso, oggi limitato dall'isolamento dei principali provider. Conoscere la porta d'ingresso determina la bonifica: cambiare le password senza chiudere la falla del plugin significa invitare di nuovo gli ospiti.

Prima ora: congelare, non cancellare

1. Snapshot completo: copia di file e database così come sono, prima di qualunque pulizia — sono le prove e la mappa dell'attacco;
2. se il provider lo consente, attivare una pagina di manutenzione per ridurre il danno reputazionale;
3. annotare tutto ciò che è anomalo: orari nei log, file con date di modifica recenti, account creati di recente;
4. cambio immediato delle password di tutti i livelli: pannello hosting, FTP/SFTP, database, amministratore del CMS, email di servizio.

Individuare i file modificati

Il metodo è l'aritmetica dei tempi: confrontare le date di modifica con l'ultima distribuzione nota. Dalla shell, l'elenco dei file toccati negli ultimi giorni:

find . -type f -mtime -7 -not -path "./logs/*"

e la caccia ai pattern tipici delle webshell:

grep -rEl "eval\s*\(|base64_decode|gzinflate|str_rot13|shell_exec" ./public_html

Chi ha un deposito pulito (il repository, un backup noto) può fare di meglio: il confronto degli hash file per file, che evidenzia ogni differenza — modifiche, aggiunte, cancellazioni. I log di accesso completano il quadro: indicano la richiesta che ha eseguito lo script, e spesso la vulnerabilità precisa.

Bonifica e messa in sicurezza

1. rimuovere i file estranei e ripristinare quelli modificati dalla copia pulita;
2. aggiornare core, tema e plugin del CMS all'ultima versione, dopo aver eliminato ciò che non serve più;
3. verificare gli utenti amministrativi: eliminare account sconosciuti e ripristinare le chiavi;
4. rigenerare chiavi e salti di configurazione del CMS;
5. richiedere la revisione a Safe Browsing e verificare l'assenza del dominio nelle blacklist;
6. solo alla fine, riaprire il sito — e tenere sotto controllo i log per settimane.

Prevenire la prossima volta

• SFTP ovunque, FTP disattivato; password uniche e lunghe, custodite in un gestore;
• verifica a due fattori sul pannello di hosting;
• backup fuori dall'hosting, con regola 3-2-1, e restore provato almeno una volta;
• aggiornamenti automatici per le release minori del CMS;
• una rete di distribuzione davanti all'origine, con regole di protezione: tema della guida all'edge;
• permessi dei file minimi e disattivazione dell'editing via interfaccia amministrativa.