Sito PHP hackerato su server dedicato (Hetzner, OVH): la guida d'emergenza per il ripristino e l'hardening

È una sensazione gelida che auguro a nessun imprenditore. Apri il sito della tua attività e al posto della tua homepage trovi un messaggio di un gruppo di hacker. Oppure, un cliente ti chiama furioso perché il tuo e-commerce gli ha rubato i dati della carta di credito. O, ancora, ricevi una notifica da Google: "Questo sito potrebbe essere dannoso". Il tuo business digitale, ospitato su quel server dedicato Hetzner o su quel VPS Cloud OVH che consideravi una solida fortezza, è stato violato. Il panico e un senso di impotenza prendono il sopravvento.

Nella mia esperienza come consulente per la sicurezza e architetto software, ho aiutato numerose aziende a navigare le acque turbolente di un post-incidente informatico. Un sito hackerato non è solo un problema tecnico; è una crisi di business che erode la fiducia dei clienti, minaccia la reputazione e può portare a sanzioni legali per violazione di dati (secondo il GDPR). Molto spesso, questi incidenti sono il culmine di un lungo periodo di incuria: software non aggiornato, configurazioni deboli, mancanza di monitoraggio. Sono le conseguenze dirette di un debito tecnico non gestito, magari lasciato in eredità da un precedente fornitore.

Se ti trovi in questa situazione, respira. La prima cosa da sapere è che agire con metodo è più importante che agire con fretta. Questo articolo è una guida d'emergenza, un protocollo operativo per gestire la crisi, bonificare il sistema e, soprattutto, trasformare questa dolorosa esperienza in un'opportunità per costruire un'infrastruttura digitale veramente resiliente.

Stai cercando un Consulente Informatico esperto per la tua Azienda? Nel mio profilo professionale trovi la mia esperienza e le competenze specifiche per aiutarti a risolvere qualsiasi problematica tecnica. Contattami per una consulenza.

Calma e metodo: i tre passi critici da compiere immediatamente

Prima ancora di pensare a come rimuovere il malware, ci sono tre azioni fondamentali da intraprendere per contenere il danno ed evitare di peggiorare la situazione.

1. Isolare immediatamente il server

Un server compromesso è come un paziente contagioso: va messo in quarantena. L'obiettivo è duplice: impedire all'attaccante di causare ulteriori danni o esfiltrare altri dati e bloccare la propagazione del malware ad altri sistemi.

• Utilizza la "Rescue Mode" del tuo provider: Quasi tutti i principali provider offrono una modalità di salvataggio. Su Hetzner, per esempio, puoi riavviare il server in un ambiente Linux minimale via rete, montando il tuo disco in sola lettura per l'analisi. Questo ti permette di lavorare sul sistema senza che il software compromesso sia in esecuzione.
• Attiva la modalità firewall del pannello di controllo: Provider come OVH, Hetzner e Digital Ocean offrono un firewall a livello di infrastruttura, gestibile dai loro pannelli web. Usalo per bloccare tutto il traffico in entrata e in uscita, ad eccezione del tuo indirizzo IP per l'accesso SSH. Questo "spegne" il sito al mondo esterno mentre tu lavori.

Avviso tecnico: Non limitarti a spegnere il server. Spegnere la macchina può cancellare dati volatili in memoria che potrebbero essere cruciali per l'analisi forense. L'isolamento tramite firewall è una strategia molto più efficace.

2. Non cancellare nulla: il server è una scena del crimine

La tentazione di cancellare i file malevoli o ripristinare un vecchio backup è forte, ma è un errore gravissimo. Il tuo server compromesso è una scena del crimine digitale. Ogni file, ogni riga di log, è una potenziale prova che può aiutarti a capire:

• Chi ti ha attaccato (l'indirizzo IP, il paese di origine).
• Come è entrato (il vettore d'attacco, ad esempio una vulnerabilità in un plugin, una password debole).
• Cosa ha fatto una volta dentro (escalation di privilegi, installazione di una backdoor, furto di dati).

Cancellare questi file significa distruggere le prove necessarie per chiudere la falla di sicurezza. Se non capisci come sono entrati, ripristinare un backup pulito è inutile: verranno hackerati di nuovo, spesso nel giro di poche ore.

3. Creare un'immagine completa del sistema compromesso

Prima di iniziare qualsiasi operazione di pulizia, è imperativo creare un'immagine forense o, più semplicemente, un backup completo dello stato attuale del server.

• Snapshot a livello di virtualizzazione: Se sei su un VPS Cloud (es. Hetzner Cloud, Digital Ocean Droplet, Aruba Cloud), la funzione di snapshot è il modo più rapido e sicuro per clonare lo stato esatto del disco.
• Copia manuale con dd: Su un server dedicato, puoi usare strumenti come dd dalla modalità di ripristino per creare un'immagine bit-a-bit del disco su un'unità di archiviazione esterna.

# Esempio concettuale di clonazione disco con dd via SSH (da eseguire con estrema cautela)

# Assumendo di essere in modalità rescue e di avere un server di storage montato

```bash
dd if=/dev/sda | gzip -c | ssh utente@server-storage 'dd of=/percorso/backup/sda.img.gz'

Questo backup è la tua assicurazione. Potrà essere analizzato in un secondo momento in un ambiente sicuro e isolato, senza rischiare di alterare il sistema originale. Se la situazione è grave e richiede un'indagine formale, questo è il materiale che un esperto forense utilizzerà.

L'intervento tecnico: analisi, bonifica e ripristino

Con il server isolato e un backup dello stato compromesso al sicuro, inizia la vera e propria operazione di pulizia. Questo processo è meticoloso e richiede competenze tecniche approfondite.

Fase 1: Analisi dei log per identificare il vettore d'attacco

Questa è l'attività investigativa. Analizzo sistematicamente tutti i file di log per ricostruire la catena di eventi.

• Log del web server (/var/log/nginx/access.log, /var/log/apache2/access.log): Cerco richieste POST sospette verso file inaspettati, scansioni di vulnerabilità, richieste con user-agent strani o provenienti da indirizzi IP noti per attività malevole.
• Log degli errori (/var/log/nginx/error.log, /var/log/php/7.4-fpm.log): Spesso rivelano tentativi di exploit che hanno generato errori, lasciando una traccia chiara.
• Log di sistema (/var/log/auth.log, /var/log/syslog): Cerco tentativi di login SSH falliti (brute-force), sessioni di login riuscite da IP sospetti o comandi strani eseguiti da utenti di sistema.
• Log del database (/var/log/mysql/error.log): Possono indicare tentativi di SQL Injection.

L'obiettivo è rispondere alla domanda: "Da dove sono entrati?". La risposta è quasi sempre una di queste: una password debole (FTP, SSH, database, pannello di amministrazione), una vulnerabilità in un'applicazione web non aggiornata (es. un vecchio plugin WordPress, una versione obsoleta di phpMyAdmin), o una falla nel software del server stesso.

Fase 2: Scansione e rimozione del malware

Una volta capito (o ipotizzato) il vettore, si passa alla caccia al malware.

• Scansione con strumenti specifici: Su un sistema Debian o Ubuntu, installo e utilizzo strumenti come:
  • ClamAV: un antivirus open-source per identificare file malevoli noti.
  • Maldet (Linux Malware Detect): specializzato nella ricerca di webshell PHP, mailer e altri tipi di malware comuni negli ambienti di hosting.
  • rkhunter o chkrootkit: per verificare la presenza di rootkit a livello di sistema.
• Analisi manuale dei file: Nessuno strumento automatico è perfetto. È essenziale un'analisi manuale. Cerco file con timestamp di modifica recenti e sospetti, specialmente in cartelle scrivibili come /tmp o le directory di upload. Analizzo il codice PHP alla ricerca di funzioni sospette come eval(), base64_decode(), gzuncompress() usate per offuscare codice malevolo (le cosiddette webshell).

Fase 3: Bonifica del codice e del database

La rimozione del malware è solo una parte. Bisogna pulire il codice dell'applicazione e il database.

• Codice sorgente: La strategia più sicura è non "pulire" i file compromessi, ma sostituirli completamente con una versione pulita proveniente da un repository Git o da un archivio ufficiale. Se il progetto non è versionato (scenario comune nei casi critici), il processo è molto più complesso e richiede un confronto file per file.
• Database: Controllo la tabella degli utenti alla ricerca di amministratori aggiunti dall'attaccante. Ispeziono i contenuti (es. post, pagine) alla ricerca di codice JavaScript malevolo o link a siti di phishing iniettati.
• Cambio di tutte le credenziali: Ogni singola password, chiave API, salt di crittografia presente nell'applicazione deve essere rigenerata da zero.

Questo processo, come spiego anche nella mia pagina chi sono, va oltre la semplice programmazione. È un'attività che richiede una mentalità da investigatore e una profonda comprensione di come funzionano sia le applicazioni che le infrastrutture sottostanti.

Dall'incidente alla resilienza: l'hardening del server per il futuro

Ripulire il server non basta. Se non si corregge la causa principale, l'incidente si ripeterà. La fase finale, e la più importante, è l'hardening: rendere il server un bersaglio molto più difficile.

• Aggiornamenti sistematici: La prima causa di violazioni è il software obsoleto. Si imposta un piano per aggiornare regolarmente il sistema operativo (apt update && apt upgrade), il runtime PHP e tutte le dipendenze del progetto (composer update).
• Configurazione di un firewall robusto: Utilizzo UFW (Uncomplicated Firewall) o iptables per chiudere tutte le porte tranne quelle strettamente necessarie (es. 80 per HTTP, 443 per HTTPS, e una porta non standard per SSH).
• Hardening del servizio SSH:
  • Disabilito il login per l'utente root.
  • Impongo l'autenticazione tramite chiavi crittografiche, disabilitando le password.
  • Cambio la porta SSH di default dalla 22 a una porta alta.
• Hardening di PHP e del web server:
  • Disabilito funzioni PHP pericolose nel file php.ini (disable_functions).
  • Configuro permessi dei file e delle directory restrittivi, assicurando che il web server non possa scrivere al di fuori delle cartelle necessarie.
• Implementazione di un piano di Disaster Recovery: Configuro backup automatici, giornalieri, crittografati e archiviati su una location esterna (es. un bucket S3-compatible).

Se la tua attività è stata colpita e hai bisogno di un intervento professionale per bonificare il sistema e implementare una strategia di sicurezza a lungo termine, contattami per una valutazione dell'incidente.

Un attacco hacker è un evento traumatico, ma può essere il catalizzatore per un cambiamento positivo. Costringe a fare i conti con le proprie debolezze e a investire in una sicurezza che prima veniva data per scontata. Trasformare questa crisi in un'infrastruttura fortificata è il modo migliore per assicurarsi che non accada mai più.