# Mettere in sicurezza da soli root server e vServer

> Mettere in sicurezza un vServer dopo PHP2Shell: verificare i pacchetti PHP, riconoscere i backport, riavviare i worker e rafforzare il root server nel tempo.

Fonte: https://phpsos.de/it/server/root-server-vserver/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** chi gestisce da sé un root server o un vServer deve anche metterlo in sicurezza da sé dopo PHP2Shell: portare i pacchetti PHP a uno stato corretto, riavviare tutti i processi PHP e verificare il risultato. Il gestore del data center di norma si occupa solo di hardware, virtualizzazione e rete. Poi vale la pena rafforzare il server in modo duraturo.

## La Sua responsabilità con un server proprio

Con un root server o un vServer non gestito affitta potenza di calcolo, non assistenza. Sistema operativo, web server, PHP, database, firewall, backup e monitoraggio sono nelle Sue mani. Per direzione e titolari significa: se nessuno in azienda o presso un fornitore di servizi si è assunto espressamente questi compiti, non li svolge nessuno.

PHP2Shell lo rende visibile. Le due vulnerabilità CVE-2026-109618 e CVE-2026-109619 si trovano in PHP stesso e consentono l'esecuzione di codice senza autenticazione. Il 21/10/2026 il progetto PHP ha pubblicato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda l'aggiornamento immediato e, se non è possibile, di scollegare temporaneamente dalla rete il web server.

## Mettere in sicurezza un vServer: verificare inventario e stato dei pacchetti

Per prima cosa si faccia un quadro di quali versioni di PHP sono installate e da quale fonte provengono. Molti server usano, oltre ai pacchetti della distribuzione, fonti di pacchetti aggiuntive. I comandi seguenti leggono soltanto. I nomi dei pacchetti sono esempi.

```bash
# Debian/Ubuntu: pacchetti PHP installati e relativa provenienza
apt list --installed 'php*' 2>/dev/null
apt-cache policy php8.3-fpm

# AlmaLinux/Rocky/RHEL
dnf list installed 'php*'

# Quali binari PHP esistono in tutto?
ls /usr/bin/php* /usr/sbin/php-fpm* 2>/dev/null
```

Il solo numero di versione non basta. Le distribuzioni spesso forniscono le correzioni di sicurezza come backport e il numero mostrato resta più vecchio. A decidere è il changelog del pacchetto.

```bash
# Debian/Ubuntu (nome del pacchetto a titolo di esempio)
apt changelog php8.3-fpm 2>/dev/null | grep -iE 'CVE-2026-1096(18|19)'

# Famiglia RHEL (nome del pacchetto a titolo di esempio)
rpm -q --changelog php-fpm | grep -iE 'CVE-2026-1096(18|19)'
```

Un'istruzione dettagliata si trova alla pagina [Verificare versione e stato della patch di PHP](https://phpsos.de/it/php2shell/php-version-pruefen/).

## Installare l'aggiornamento e rinnovare tutti i processi

Installi gli aggiornamenti tramite la gestione dei pacchetti e poi riavvii ogni servizio che carica PHP. A seconda della struttura sono PHP-FPM, Apache con mod_php, LiteSpeed o un application server. I nuovi file sul disco non bastano finché in memoria girano vecchi processi.

```bash
# Trovare i servizi con PHP
systemctl list-units --type=service | grep -iE 'php|apache2|httpd|lsws'

# Mostrare i processi con l'orario di avvio
ps -eo pid,lstart,cmd | grep -E 'php|apache2|httpd' | grep -v grep

# Debian/Ubuntu: riconoscere programmi con librerie obsolete (se installato)
needrestart -r l
```

Ogni processo rilevante dovrebbe essere stato avviato dopo l'aggiornamento. Utile sui sistemi Debian è lo strumento `needrestart`, che mostra i servizi con librerie obsolete. I dettagli sul riavvio sono descritti alla pagina [Riavviare PHP-FPM e tutti i worker](https://phpsos.de/it/php2shell/php-fpm-neustart/).

> **Importante:**
> Una patch non rimuove il malware introdotto prima dell'aggiornamento. Conservi i log del web server a partire dal 20/10/2026 e verifichi la presenza di tracce sul server prima di classificarlo come pulito.

Per una prima ricerca di tracce si prestano alcuni controlli che non modificano nulla. Cerchi file PHP creati o modificati dal 17/10/2026 nelle directory web, voci sconosciute nei crontab di tutti gli utenti, nuovi utenti di sistema e chiavi SSH, nonché processi dell'utente del web server che mantengono connessioni in uscita.

```bash
# File PHP modificati dal 17/10/2026 (percorso a titolo di esempio)
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls

# Connessioni di rete con il processo corrispondente
ss -tupn
```

Nessuno di questi controlli prova da solo un'intrusione, e un risultato vuoto non prova il contrario. Mostrano però se serve un'indagine più approfondita. Lavori su copie dei log e non modifichi i file sospetti finché lo stato non è stato salvato. In caso di riscontri, la via sicura è un'indagine ordinata. In questo caso non spenga semplicemente il server e non lo reinstalli subito, perché si perdono tracce importanti per la valutazione degli obblighi di notifica e per un'eventuale denuncia.

## Rafforzare il server in modo duraturo

Dopo la patch d'emergenza segue la messa in sicurezza di base. Non impedisce ogni vulnerabilità, ma limita il danno e accorcia i tempi di reazione la prossima volta. Si sono dimostrati validi questi punti:

- **Accessi:** SSH solo con chiave, nessun accesso diretto come root, interfacce di amministrazione raggiungibili solo da reti note.
- **Firewall:** aprire solo le porte realmente necessarie, limitare le connessioni in uscita del web server.
- **Configurazione di PHP:** disattivare le funzioni pericolose, `open_basedir` per ogni sito, pool e utenti separati per ogni applicazione.
- **Permessi dei file:** il web server non deve poter scrivere sul codice del programma, le directory di upload non eseguono PHP.
- **Aggiornamenti:** installare automaticamente gli aggiornamenti di sicurezza, pianificare in modo fisso riavvio e controllo.
- **Backup:** copie secondo la regola 3-2-1, almeno una copia al di fuori del server e protetta da modifiche.
- **Registri:** raccogliere i log in modo centralizzato e conservarli abbastanza a lungo.

Com'è fatto un backup affidabile è descritto alla pagina [Backup secondo la regola 3-2-1](https://phpsos.de/it/ratgeber/backups-3-2-1/). Come cornice per le aziende è adatto l'IT-Grundschutz del BSI.

## Quando un managed server è la scelta migliore

Un server proprio conviene se qualcuno ne assicura la cura in modo affidabile: seguire gli aggiornamenti, valutare situazioni come PHP2Shell, poter reagire di notte. Se manca questa capacità, ha senso o un managed server o un contratto di manutenzione fisso. In entrambi i casi è importante mettere per iscritto le competenze. Maggiori informazioni alla pagina [Managed server: chiarire le responsabilità](https://phpsos.de/it/server/managed-server/).

## Come aiuta concretamente PHP SOS?

- Rileviamo tutte le installazioni di PHP, le fonti dei pacchetti e i servizi del Suo server e valutiamo lo stato effettivo della patch.
- Installiamo gli aggiornamenti, riavviamo tutti i processi e documentiamo il risultato.
- Verifichiamo il server alla ricerca di tracce di compromissione e salviamo i log per una successiva analisi.
- Nell'ambito del nostro [hardening dei server](https://phpsos.de/it/leistungen/server-haertung/) configuriamo correttamente accessi, firewall, pool PHP e permessi.
- Su richiesta ci occupiamo della manutenzione continuativa tramite un [contratto di manutenzione della sicurezza](https://phpsos.de/it/leistungen/security-wartungsvertrag/).


## Domande frequenti

**Il mio data center aggiorna automaticamente il vServer?**  
Di norma no, nel caso di root server e vServer non gestiti. Il fornitore mette a disposizione hardware o virtualizzazione e rete, mentre il sistema operativo e tutti i servizi che vi girano li gestisce Lei. In caso di dubbio verifichi il Suo contratto.

**Bastano gli aggiornamenti di sicurezza automatici?**  
Aiutano, ma non sostituiscono il controllo. Gli aggiornamenti automatici non sempre riavviano i processi PHP in esecuzione e spesso non coprono i pacchetti provenienti da fonti esterne. Dopo ogni aggiornamento di sicurezza verifichi lo stato dei pacchetti e gli orari di avvio dei processi.

**Come scopro se il mio pacchetto contiene un backport?**  
Nel changelog del pacchetto e nei bollettini di sicurezza della Sua distribuzione. Se vi compare il numero CVE, la correzione è inclusa, anche se il numero di versione sembra più vecchio. Se manca la voce, chiarisca lo stato prima di classificare il server come aggiornato.

**Che cosa faccio se per la mia versione di PHP non arriva alcuna patch?**  
Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali. Applichi le misure transitorie secondo php.net, pianifichi rapidamente il passaggio a una versione supportata e, se necessario, secondo la raccomandazione del BSI scolleghi temporaneamente il server dalla rete.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [php.net: versioni supportate](https://www.php.net/supported-versions.php)
- [IT-Grundschutz del BSI](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)