In breve: se si tratta di DDoS o di attacco hacker lo mostrano le tracce. Un DDoS genera moltissime richieste e rende il sito lento o irraggiungibile, ma non modifica nulla. Un exploit ha spesso bisogno di poche richieste e lascia file, account, processi o connessioni nuovi. L'inquadramento corretto decide se deve respingere il carico o contenere un incidente.
La differenza in parole semplici
Un attacco DDoS (Distributed Denial of Service) è come una folla che blocca l'ingresso di un negozio. Nessuno entra, ma nel negozio non viene rubato nulla. L'obiettivo è sovraccaricare il Suo sito o il Suo server, in modo che i clienti veri non riescano più a passare.
Un exploit è invece un'intrusione attraverso una porta aperta. L'aggressore sfrutta una debolezza, ad esempio in PHP, nel CMS o in un'estensione, per eseguire codice sul Suo server. Può avvenire in silenzio, senza che il sito rallenti. Le conseguenze vanno da pagine di spam al furto di dati fino alla presa di controllo del server.
Per la direzione la differenza è decisiva: un DDoS è un problema di disponibilità che finisce con l'attacco. Un exploit riuscito è un incidente di sicurezza che resta finché non viene trovato, bonificato e documentato.
DDoS o attacco hacker: i segnali a confronto
La tabella seguente aiuta nel primo inquadramento. Non sostituisce un'analisi, ma mostra dove guardare per prima cosa.
| Caratteristica | Più probabilmente DDoS | Più probabilmente exploit o intrusione |
|---|---|---|
| Raggiungibilità | lento o fuori servizio | spesso normale |
| Richieste nel log | moltissime, spesso uniformi | poche richieste mirate |
| File | invariati | file PHP nuovi o modificati |
| Account | invariati | nuovi admin, password modificate |
| Processi | server web e PHP a pieno carico | processi sconosciuti, mining, invio di spam |
| Rete | molto traffico in entrata | connessioni in uscita insolite |
| Dopo la fine | tutto come prima | le tracce restano |
Attenzione alle sovrapposizioni: la scansione di massa alla ricerca di una vulnerabilità può sembrare un piccolo DDoS. Proprio questo era da aspettarsi attorno a PHP2Shell, quando gli aggressori cercavano server vulnerabili. Un carico alto può quindi significare anche che qualcuno sta cercando in quel momento di entrare.
Primi controlli sul server
I comandi seguenti non modificano nulla nel sistema e danno un quadro rapido. In caso di sospetta intrusione metta al sicuro i log prima di effettuare interventi più ampi.
# Carico e tempo di attività
uptime
# Connessioni riassunte e controparti più frequenti
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Indirizzi client più frequenti nell'access log (adattare il percorso)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# File PHP modificati negli ultimi 7 giorni
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Processi con il carico CPU più alto
ps aux --sort=-%cpu | head -15
Nel riepilogo delle connessioni la quarta colonna mostra la controparte. Molte connessioni da pochi indirizzi o un aumento fino a un multiplo del valore normale indicano un sovraccarico. File PHP nuovi nelle directory di upload o di cache, processi dell'utente del server web con nomi estranei o connessioni in uscita verso destinazioni sconosciute indicano piuttosto un'intrusione. Un elenco dettagliato si trova in Segnali di compromissione dopo PHP2Shell.
Perché un carico alto può essere anche una manovra diversiva
Capita che gli aggressori provochino un sovraccarico mentre contemporaneamente entrano in modo mirato. Il team è allora occupato con la raggiungibilità e le vere tracce si perdono nel rumore dei log. Vale perciò: anche se un DDoS è evidente, dopo la sua fine controlli file, account e connessioni in uscita.
Nel caso di PHP2Shell si aggiunge che, secondo php.net e le società di sicurezza, non esistono Indicators of Compromise pubblicati e confermati. Il rilevamento si basa sull'analisi del comportamento. Un server che nel periodo di scansione da metà ottobre non era aggiornato dovrebbe quindi essere verificato a prescindere dal carico osservato.
Un'ulteriore variante sono le e-mail di estorsione in cui si minaccia un attacco DDoS se non si paga. Conservi tali messaggi, non paghi senza accordarsi con gli esperti e valuti una denuncia presso la Zentrale Ansprechstelle Cybercrime (ZAC, punto di contatto centrale tedesco per il cybercrimine). Informi in parallelo il Suo hoster, in modo che si possano preparare misure di protezione. Come analizzare i log a tal fine è spiegato nella guida Analizzare i log del server web dopo un attacco.
Che cosa fare nelle prime ore
In caso di sospetto DDoS:
- Informare l'hoster o il data center; lì ci sono spesso filtri a monte del server.
- Attivare o inasprire un servizio di protezione a monte oppure un WAF con virtual patching.
- Impostare rate limit nel server web e proteggere in modo particolare le pagine costose come ricerca o carrello.
- Conservare i log, in modo che l'attacco sia ricostruibile in seguito.
In caso di sospetta intrusione:
- Non cancellare nulla e non reinstallare il server prima di aver messo al sicuro log e file interessati.
- Aggiornare PHP a una versione corretta e riavviare tutti i worker, se non è ancora avvenuto.
- Se l'aggiornamento non è subito possibile, scollegare temporaneamente il sito dalla rete, come raccomanda il BSI (Ufficio federale tedesco per la sicurezza informatica).
- Rinnovare le credenziali da un dispositivo pulito, non dal server potenzialmente compromesso.
- Far verificare se possano essere coinvolti dati personali; in tal caso possono decorrere termini di notifica.
In entrambi i casi aiuta una breve nota oggettiva per hoster e fornitori di servizi: da quando esiste il problema, quali siti sono interessati, che cosa ha osservato e che cosa è già stato modificato. Annoti inoltre chi ha preso quale decisione. Questa cronologia fa risparmiare tempo nell'analisi ed è preziosa in seguito per assicurazione, protezione dei dati e rielaborazione interna. Se non è chiaro se ci sia davvero un attacco, tratti la situazione in via precauzionale come un incidente finché non è provato il contrario.
Come aiuta concretamente PHP SOS?
- Inquadriamo la situazione da remoto sulla base di carico, log, file e connessioni e Le diciamo con che cosa probabilmente ha a che fare.
- In caso di sovraccarico impostiamo filtri, rate limit e regole di protezione a monte finché l'attacco non si attenua.
- In caso di sospetta intrusione ci occupiamo della incident response strutturata: mettere al sicuro, contenere, trovare la causa, bonificare.
- Alla fine documentiamo che cosa è accaduto e quali misure sono state attuate, fino alla chiusura dell'incidente.
Domande frequenti
Un attacco DDoS può rubare dati?
Un puro attacco DDoS mira alla raggiungibilità, non ai dati. Non modifica file e non legge database. Può però presentarsi contemporaneamente a un tentativo di intrusione, perciò vale comunque la pena dare un'occhiata a file e account.
Da cosa riconosco che il mio sito è stato violato?
Indizi tipici sono file PHP nuovi o modificati, account admin sconosciuti, reindirizzamenti verso siti esterni, connessioni in uscita inattese e processi che non c'entrano con la Sua applicazione. Un singolo segnale non è una prova, più segnali insieme sono un segnale serio.
Una CDN o un WAF aiutano contro entrambi i tipi di attacco?
Contro gli attacchi basati sul volume un servizio a monte di solito aiuta bene. Contro gli exploit le regole funzionano solo se riconoscono lo schema. Con PHP2Shell Cloudflare stessa fa notare che le regole basate solo sui dati della richiesta non bastano.
Devo segnalare un attacco DDoS?
Dipende dal singolo caso e dal Suo settore. Senza accesso a dati personali l'obbligo di notifica del GDPR di regola non si applica, ma possono esistere obblighi specifici del settore. Lo chiarisca con il Suo responsabile della protezione dei dati o con un avvocato.