In breve: gli attacchi automatizzati ai server web procedono a ondate: dei programmi setacciano Internet alla ricerca di server raggiungibili, li classificano in base a caratteristiche esterne e provano in massa vulnerabilità note come PHP2Shell. Le dimensioni dell'azienda non contano. Offrono protezione un PHP aggiornato, una piccola superficie di attacco e un monitoraggio che nota rapidamente i colpi andati a segno.
Il punto di partenza: «Chi dovrebbe interessarsi al nostro sito?»
Questa domanda la sentiamo spesso dopo PHP2Shell, soprattutto dalle aziende più piccole. La risposta onesta: probabilmente nessuno personalmente. Ma con vulnerabilità di questo tipo non serve nemmeno. Gli attacchi sono eseguiti da programmi che non cercano nomi, ma occasioni.
Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) per PHP2Shell contava su uno sfruttamento rapido e su vasta scala. Cloudflare ha riferito di tentativi di attacco e del fatto che gli aggressori modificavano i propri schemi per aggirare le regole di protezione. Entrambe le cose corrispondono a ciò che avviene regolarmente con vulnerabilità critiche in software molto diffuso.
Come funzionano gli attacchi automatizzati ai server web
Le campagne automatizzate seguono di solito uno schema simile. La panoramica seguente descrive le fasi in generale, senza dettagli di attacco:
| Fase | Che cosa avviene | Che cosa aiuta contro di essa |
|---|---|---|
| Ricerca | i programmi esaminano ampi intervalli di indirizzi o elenchi pubblici come i registri dei certificati alla ricerca di server web raggiungibili | pochi sistemi raggiungibili pubblicamente, inventario di tutti gli indirizzi |
| Classificazione | le risposte vengono analizzate: server web, versione di PHP, CMS, percorsi tipici | nascondere le indicazioni di versione, rimuovere i file non necessari |
| Tentativo | le vulnerabilità note vengono testate in massa, spesso senza classificazione preliminare | PHP aggiornato, riavvio, WAF come livello aggiuntivo |
| Insediamento | in caso di successo viene lasciata una backdoor, ad esempio una webshell o un cronjob | permessi di scrittura limitati, nessuna esecuzione PHP nelle cartelle di upload |
| Sfruttamento | il server viene usato, ad esempio per spam, cryptomining, reindirizzamenti o furto di dati | monitoraggio di processi, file e connessioni in uscita |
Importante è la terza riga. Molte campagne non si danno nemmeno la pena di classificare prima con precisione i server. Provano semplicemente tutto ciò che è raggiungibile. Per questo la sola discrezione non protegge.
Perché gli attacchi arrivano a ondate
Le campagne automatizzate raramente passano una volta e mai più. Tipico è uno schema a ondate. La prima ondata segue poco dopo la divulgazione di una vulnerabilità, spesso ancora con strumenti poco maturi. Altre ondate arrivano quando gli aggressori migliorano i propri strumenti o li adattano alle regole di protezione. Con PHP2Shell Cloudflare ha osservato proprio questo: schemi di attacco modificati per aggirare le regole.
Per Lei significa: un server che ha superato indenne la prima ondata non è al sicuro in modo permanente finché non è aggiornato. E un server appena configurato è un bersaglio dal momento in cui è raggiungibile. Chi ad esempio fa emettere un nuovo certificato TLS rende visibile il nome nei registri pubblici dei certificati, che analizzano anche gli scanner. Un nuovo sistema dovrebbe quindi andare in rete solo quando è già aggiornato.
Perché le piccole aziende sono colpite allo stesso modo
Per gli attacchi automatizzati non conta il valore di un singolo bersaglio, ma la quantità. Il server di una piccola azienda offre potenza di calcolo, un dominio con buona reputazione, un invio di posta e talvolta dati dei clienti. Per gli aggressori è sufficiente.
Inoltre: le aziende più piccole spesso non hanno un IT proprio che installi subito gli aggiornamenti. I loro server restano vulnerabili più a lungo e finiscono perciò più spesso negli elenchi dei risultati degli scanner. Chi applica la patch per primo esce da questi elenchi.
Un altro punto è la catena di fornitura. Molti piccoli siti stanno su server di agenzie o di piccoli hoster, su cui girano a fianco decine di progetti dei clienti. Per gli aggressori un server del genere è particolarmente redditizio, perché un solo colpo riguarda molti siti contemporaneamente. Il Suo rischio non dipende allora solo dalla Sua diligenza, ma anche da quella del Suo fornitore di servizi.
Le scansioni nei Suoi log sono normali e non sono una prova di intrusione. Un attacco riuscito si manifesta con altre tracce: nuovi file, processi estranei, account sconosciuti, connessioni in uscita insolite.
Cosa può verificare da solo
Uno sguardo ai log mostra quanto il Suo server viene scansionato. I comandi seguenti si limitano a leggere e non modificano nulla:
# I dieci indirizzi con più richieste nel log di accesso attuale
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Richieste a cui è stato risposto con «non trovato», per frequenza
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Il server rivela la sua versione di PHP nell'header?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
Molte richieste a percorsi inesistenti sono il tipico rumore di scansione. Dovrebbe invece diventare più attento se a tali richieste seguono improvvisamente risposte riuscite, se nelle cartelle di upload vengono richiamati file che non conosce, o se l'utente del server web avvia processi che di solito non avvia mai. Indicatori confermati specificamente per PHP2Shell finora non esistono, la valutazione si basa quindi su simili anomalie di comportamento. Come analizzare i log in modo più approfondito lo descrive la guida Analizzare i log del server web. Se la terza interrogazione mostra una versione di PHP, vale la pena l'impostazione expose_php = Off; i retroscena si trovano in Nascondere le indicazioni di versione.
I livelli di protezione nell'ordine giusto
- Aggiornare PHP e riavviare: senza questo passaggio tutte le altre misure restano rattoppi.
- Ridurre la superficie di attacco: spegnere o mettere dietro un'autenticazione siti non usati, sistemi di test e vecchi micrositi.
- Regole al perimetro: un Web Application Firewall con un set di regole curato, ad esempio l'OWASP Core Rule Set con ModSecurity, intercetta una parte dei tentativi.
- Frenare i tentativi ripetuti: strumenti come Fail2ban bloccano gli indirizzi che generano un numero vistoso di errori. Contro scansioni distribuite aiuta solo in misura limitata.
- Monitorare: tenere d'occhio i processi dell'utente del server web, i nuovi file PHP e le connessioni in uscita, perché un colpo riuscito non resti inosservato per settimane.
Come aiuta concretamente PHP SOS?
- Rilevare la superficie di attacco: accertiamo quali dei Suoi sistemi sono raggiungibili dall'esterno e che cosa rivelano di sé.
- Aggiornare e rafforzare: aggiorniamo PHP, riavviamo e riduciamo indicazioni di versione, permessi di scrittura e servizi non necessari.
- Regole e blocchi: configuriamo regole WAF e meccanismi di blocco adatti alla Sua applicazione.
- Monitoraggio continuo: segnaliamo processi, file e connessioni anomali prima che un colpo diventi incidente.
Come si presenta tutto questo nell'esercizio continuo lo descrive Security monitoring per server web.
Conclusione
Gli attacchi automatizzati non chiedono a chi appartenga un server. Chiedono solo se è vulnerabile. La risposta migliore è poco spettacolare: applicare rapidamente la patch, offrire poco, guardare con attenzione. Chi lo fa continuerà a essere scansionato, ma non verrà più trovato.
Domande frequenti
Le piccole aziende sono bersaglio di attacchi automatizzati?
Sì. Le scansioni automatizzate controllano i server raggiungibili senza riguardo per il gestore. Se dietro c'è un gruppo o un'azienda artigiana, per il software non ha importanza. Conta se il server appare vulnerabile.
Da che cosa riconosco le scansioni nei miei log?
Tipiche sono molte richieste a percorsi che sul Suo sito non esistono affatto, spesso da indirizzi che cambiano e con identificativi vistosi. Voci simili sono normali e non sono ancora la prova di un attacco riuscito, ma mostrano che il Suo server viene sondato.
Aiuta nascondere la versione di PHP?
Rende un po' più difficile agli scanner classificare con precisione il Suo server ed è un'impostazione di base sensata. Non protegge però dagli attacchi che provano semplicemente ogni server. L'aggiornamento resta un obbligo.
Posso evitare del tutto le scansioni?
No. Ogni server raggiungibile pubblicamente viene scansionato regolarmente. L'obiettivo non è impedire le scansioni, ma far sì che non trovino nulla: software aggiornato, poca superficie di attacco e un monitoraggio che segnala le anomalie.