In breve: è stato colpito? Ci chiami. La aiutiamo. Se sospetta che il Suo server sia stato violato, una cosa conta prima di tutto: conservare le tracce. Dal primo messaggio ci occupiamo da remoto del quadro della situazione, del salvataggio, del contenimento, della bonifica e della documentazione, fino alla conclusione dell'incidente.
Ora non cancelli nulla e non reinstalli nulla. Nemmeno ripristinare un backup prima di aver fatto un salvataggio. Chi mette in ordine distrugge proprio le tracce che mostrano come l'aggressore sia entrato. Segnali l'emergenza e procederemo insieme.
È stato colpito? Segnali che un server è stato violato
Basta un sospetto per contattarci. Non deve dimostrare l'attacco. Indizi tipici sono:
- Il web server o PHP-FPM avvia processi come
shobash. È un forte segnale d'allarme, che spieghiamo nella pagina Il web server avvia una shell. - Nelle cartelle di upload, cache o temp ci sono file PHP nuovi o sconosciuti.
- Esistono cronjob che nessuno ha creato o chiavi SSH che nessuno sa attribuire.
- Il carico è alto senza una ragione riconoscibile o il server stabilisce connessioni in uscita insolite.
- Le email del Suo server finiscono nello spam o vengono rifiutate.
- L'hoster, un cliente o un avviso del browser segnala codice dannoso.
- Nel CMS compaiono account di amministratore che nessuno ha creato.
Altri segnali li trova in Sono già stato compromesso?. Se più punti sono veri, consideri il server violato finché non è dimostrato il contrario.
Server violato: che cosa fare subito
- Mantenere la calma e non modificare nulla. Niente cancellazione di file, niente «riparazioni rapide», niente reinstallazione sopra lo stato precedente.
- Annotare il momento. Scriva che cosa ha osservato e quando, e chi ha apportato per ultimo modifiche al sistema.
- Conservare i log. I log di accesso, di errore e di sistema non devono ruotare né essere sovrascritti. Con PHP2Shell la stampa specializzata consiglia di conservare i log del server a partire dal 20/10/2026.
- Ridurre la superficie d'attacco. Scolleghi il server dalla rete pubblica o lo blocchi con il firewall se i dati potrebbero uscire. Non si limiti a spegnerlo.
- Raccogliere gli accessi. Chi ha accesso SSH, al pannello, FTP, al CMS e al database? Cambi le password solo dopo averlo concordato e soltanto da un dispositivo pulito.
- Indicare un referente. Una persona con potere decisionale dovrebbe essere raggiungibile, anche per spegnimenti e riavvii.
- Ci contatti ora. Ci chiami o ci scriva su WhatsApp. Il resto lo chiariamo con Lei passo dopo passo.
Scollegarlo dalla rete o lasciarlo in funzione?
È la domanda più frequente nei primi minuti e non ha una risposta valida per tutti. Se è in funzione uno shop online con pagamenti o un portale con dati dei clienti, di solito prevale la protezione dei dati. Allora un isolamento temporaneo è la scelta giusta, ad esempio con una pagina di manutenzione o una regola del firewall che ammette solo i Suoi amministratori.
Uno spegnimento brusco, invece, è raramente il miglior primo passo, perché nella memoria di lavoro ci sono tracce che un riavvio cancella. Meglio una copia del sistema, ad esempio uno snapshot presso l'hoster, prima di cambiare qualcosa. Nella situazione PHP2Shell il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda di scollegare temporaneamente dalla rete i web server quando un aggiornamento non è subito possibile. Ciò non significa che ogni server spento sia stato violato.
Se nel Suo caso convenga isolare, limitare o lasciare in funzione lo decidiamo con Lei in base a ciò che si trova sul sistema.
Reinstallare o bonificare?
Molti vorrebbero ricostruire subito il server. Non è sbagliato, ma solo dopo il salvataggio. Altrimenti resta poco chiaro come l'aggressore sia entrato, e la stessa via resta aperta anche al nuovo sistema. La valutazione è descritta nella pagina Reinstallare o bonificare il server?, il salvataggio prima di una ricostruzione nella pagina Conservare le prove prima di reinstallare.
Importante: un aggiornamento di PHP da solo non risolve il problema. Chiude la vulnerabilità, ma non rimuove il malware già introdotto. Come trovare le tracce nei registri è spiegato in Analizzare i log del web server dopo un attacco. E parta dal presupposto che anche le credenziali nei file di configurazione siano state lette: gli accessi a database, posta e API vanno nell'elenco dei segreti da rinnovare.
In concreto, come aiuta PHP SOS?
- Quadro della situazione: chiariamo con Lei che cosa è stato osservato, quali sistemi potrebbero essere coinvolti e quali dati vi si trovano.
- Salvare e chiudere: salviamo file, database e log prima che venga modificato qualcosa. Poi conteniamo l'attacco e chiudiamo la porta d'ingresso, con PHP2Shell con la patch e il riavvio di tutti i processi PHP.
- Verificare e bonificare: cerchiamo web shell, backdoor, cronjob e accessi estranei e li rimuoviamo. I dettagli sono in Rimozione di malware e web shell.
- Rafforzare e riferire: riceve una documentazione con linea temporale, punti di ritrovamento e raccomandazioni. Se l'incidente va oltre un singolo server, passiamo a una Incident response strutturata.
Che cosa non fare
Sotto stress si commettono errori evitabili. Non cancelli file «sospetti» per sospetto senza averli prima salvati. Non esegua comandi presi da forum che non capisce. E non installi plugin di sicurezza su un server che potrebbe essere già compromesso: il codice dannoso può ingannare gli scanner, e il risultato La culla in una falsa sicurezza. Prudenza anche con i consigli di bloccare tutte le richieste con un determinato ID di sessione; gli autori specializzati respingono espressamente consigli simili su PHP2Shell. Può verificare in sicurezza la Sua versione con php -v e dando un'occhiata al changelog del pacchetto della Sua distribuzione, perché i backport lasciano spesso invariato il numero di versione.
Che cosa dovrebbe inviarci
- una breve descrizione: che cosa è emerso, da quando, che cosa è stato modificato per ultimo
- il tipo di sistema: server proprio, vServer, server gestito o pacchetto di hosting
- l'accesso via SSH o pannello oppure l'autorizzazione a parlare con il Suo hoster
- indicazioni sui backup esistenti e sulla loro data
- i messaggi di avviso di hoster, browser o clienti, nel loro testo
Se manca qualcosa, ci contatti comunque. Le lacune le colmiamo parlandone.
Perché PHP SOS
Lavoriamo Made in Germany e da oltre 25 anni, con la nostra rete di partner di professionisti della cybersicurezza, ci specializziamo nella sicurezza informatica. Ha un unico interlocutore, lavoriamo da remoto, senza trasferte, in tutta la Germania e in Europa. Ogni passaggio viene documentato e distinguiamo apertamente tra ciò che è provato, ciò che è probabile e ciò che è sconosciuto. Non facciamo promesse che nessuno può mantenere. Una panoramica del follow-up è nella checklist dopo un attacco, l'intero servizio di assistenza urgente in Sito web violato? Assistenza urgente da remoto. Sull'obbligo di notifica per le violazioni dei dati legga la regola delle 72 ore; la valutazione giuridica resta ai responsabili della protezione dei dati e agli avvocati.
È stato colpito? Ci chiami. La aiutiamo.
Non aspetti che il sospetto diventi un danno maggiore. Ce ne occupiamo dal primo messaggio e restiamo accanto a Lei finché l'incidente non è concluso e documentato. Segnali subito l'emergenza.
Domande frequenti
Server violato: devo spegnerlo subito?
Non in modo precipitoso. Spegnerlo può distruggere tracce volatili nella memoria di lavoro. È meglio scollegarlo dalla rete o isolarlo con il firewall e prima fare un salvataggio. Se non è sicuro, ci contatti prima.
Come faccio a sapere se il mio server è stato davvero violato?
Gli indizi sono processi avviati dal web server, nuovi file PHP nelle cartelle di upload o di cache, cronjob e chiavi SSH sconosciuti e connessioni in uscita insolite. La certezza la dà solo un'analisi di log e file. Non esistono indicatori PHP2Shell confermati; il rilevamento si basa sull'analisi del comportamento.
Basta un aggiornamento di PHP se il server è già stato violato?
No. Una patch chiude la porta d'ingresso, ma non rimuove il malware già introdotto e non dimostra che prima non sia successo nulla. Dopo l'aggiornamento vanno inoltre riavviati tutti i processi PHP.
Devo segnalare un server violato?
Se potrebbero essere coinvolti dati personali, può essere necessaria una notifica all'autorità di controllo entro 72 ore. La valutazione spetta al Suo responsabile della protezione dei dati o al Suo avvocato; noi forniamo i fatti tecnici.
Posso bonificare da solo il server violato?
Nei sistemi piccoli è possibile, ma rischioso: chi rimuove solo i file visibili trascura spesso backdoor, cronjob o accessi. Verifichiamo se basti una bonifica o se sia più sensata una ricostruzione da fonti pulite.