# Nozioni di base su PHP per amministratori

> Nozioni di base su PHP per amministratori senza background da sviluppatore: binari, livelli di php.ini, pool FPM, comandi utili, log e checklist dopo PHP2Shell.

Fonte: https://phpsos.de/it/php/php-grundwissen-admins/  
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:** per gli amministratori senza background da sviluppatore bastano cinque nozioni di base per gestire PHP in sicurezza: PHP è composto da più programmi (riga di comando, PHP-FPM, modulo Apache), ciascuno con una propria versione; le impostazioni agiscono per livelli, dal php.ini all'applicazione; PHP-FPM distribuisce le richieste ai worker in pool; un aggiornamento ha effetto solo dopo il riavvio di tutti i processi; e i log sono l'indizio più importante quando qualcosa non va. Chi conosce questi punti può chiudere vulnerabilità come PHP2Shell in modo rapido e dimostrabile.

## Di che cosa è fatto PHP su un server

PHP non è un singolo programma. Su un tipico server Linux si trovano più varianti, ciascuna collegata tramite un'interfaccia del server (SAPI):

| Variante | Nome tipico | A che cosa serve |
|---|---|---|
| Riga di comando (CLI) | `php`, `php8.3` | cronjob, Composer, script di manutenzione |
| PHP-FPM | `php-fpm`, `php-fpm8.3` | richieste web dietro Nginx o Apache |
| Modulo Apache | `mod_php`, `libphp` | richieste web direttamente nel processo Apache |
| CGI | `php-cgi` | strutture più vecchie |

Ogni variante può avere una versione diversa e un php.ini diverso. Su molti server girano inoltre più versioni di PHP in parallelo, ad esempio 8.2 e 8.4. In un aggiornamento ciascuna va considerata singolarmente. Come lavorano le interfacce lo spiega [PHP-FPM spiegato](https://phpsos.de/it/php/php-fpm-erklaert/).

Quale variante serva effettivamente i Suoi siti web lo scopre dai processi in esecuzione e dalla configurazione del server web:

```bash
ps -eo pid,user,lstart,cmd | grep -E "php|httpd|apache2" | grep -v grep
apachectl -M 2>/dev/null | grep -i php     # Apache carica un modulo PHP?
ls /run/php/ 2>/dev/null                    # socket FPM, spesso per versione e pool
```

La colonna con l'ora di avvio è importante in seguito per il riavvio: tutti i processi PHP devono essere stati avviati dopo il momento dell'aggiornamento. Se i processi girano con utenti diversi, ciò indica pool separati, il che è un bene. Se in Apache compare un modulo PHP benché tutti i siti web debbano girare tramite FPM, è un indizio di un residuo del passato che va rimosso. Per le interfacce di hosting come Plesk o cPanel vale lo stesso principio, solo che l'interfaccia mostra versioni e handler per ogni sito web; resta però determinante ciò che gira effettivamente come processo.

## I comandi più importanti per gli amministratori

```bash
php -v                    # versione della riga di comando
php --ini                 # php.ini caricato e directory lette in aggiunta
php --ini=diff            # da PHP 8.5: scostamenti dal valore predefinito
php -m                    # moduli compilati e caricati
php --ri session          # impostazioni di un'estensione
php -l datei.php          # controllo della sintassi senza esecuzione
php-fpm8.3 -v             # versione del binario FPM (nome a seconda della distribuzione)
php-fpm8.3 -t             # testare la configurazione FPM senza riavviare
systemctl status php8.3-fpm
```

Due avvertenze dal manuale: `php -l` trova errori di sintassi, ma non gli errori che si verificano solo in fase di esecuzione. E `php -i` richiama `phpinfo()`; l'output non appartiene a file pubblici nella directory web.

## Come agiscono le impostazioni di PHP

Un'impostazione può essere definita in più punti. Chi possa modificare che cosa lo regola la modalità di modifica di ogni direttiva:

1. **php.ini e conf.d:** configurazione di base per variante, letta all'avvio.
2. **Pool FPM:** `php_value` e `php_admin_value` per pool. I valori impostati con `php_admin_value`, secondo il manuale, l'applicazione non può sovrascriverli con `ini_set()`.
3. **Livello di directory:** `.user.ini` con FPM o `.htaccess` con mod_php, solo per direttive in modalità `INI_PERDIR` o `INI_ALL`.
4. **Applicazione:** `ini_set()` in fase di esecuzione, solo per direttive in modalità `INI_ALL`.

Un esempio: `memory_limit` ha la modalità `INI_ALL`, quindi può essere modificato dall'applicazione. `post_max_size` ha `INI_PERDIR` e non si lascia modificare con `ini_set()`. Per questo php.net richiede, nelle misure transitorie PHP2Shell, di impostare i valori in modo che le applicazioni non possano sovrascriverli. I dettagli sui livelli li spiega [Il php.ini spiegato](https://phpsos.de/it/php/php-ini-erklaert/).

## I pool PHP-FPM in breve

Un pool è un gruppo di worker con utente, socket e impostazioni propri. Le direttive più importanti secondo il manuale:

```ini
[shop]
user = shop
group = shop
listen = /run/php/shop.sock
pm = dynamic                 ; static, dynamic oppure ondemand
pm.max_children = 20         ; al massimo 20 richieste contemporanee
pm.max_requests = 500        ; rinnovare il worker dopo 500 richieste
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/shop-slow.log
php_admin_value[error_log] = /var/log/php-fpm/shop-error.log
php_admin_flag[log_errors] = on
```

Un pool proprio per ogni sito web con utente proprio separa i siti web l'uno dall'altro. `security.limit_extensions` è per impostazione predefinita su `.php .phar` e impedisce a FPM di eseguire estensioni di file diverse da PHP. `clear_env` è attivato per impostazione predefinita e tiene le variabili d'ambiente lontane dal worker.

## Log: dove devono guardare gli amministratori

PHP scrive gli errori nella destinazione stabilita con `error_log`, PHP-FPM inoltre nel proprio log e, per le richieste lente, nello slowlog con backtrace. A ciò si aggiungono i log degli accessi e degli errori del server web. Faccia attenzione che in produzione `display_errors` sia disattivato e `log_errors` attivato: gli errori appartengono al log, non alla pagina web. I log dovrebbero inoltre essere ruotati e conservati per un periodo stabilito, perché nel caso grave esistano ancora. Dopo PHP2Shell la stampa specializzata raccomanda di conservare i log del server dal 20/10/2026. Un forte segnale d'allarme è un processo PHP-FPM o del server web che avvia una shell; come riconoscerlo lo si trova in [Segnale d'allarme: il server web avvia una shell](https://phpsos.de/it/blog/webserver-startet-shell/).

## Checklist per gli amministratori dopo PHP2Shell

1. Elencare tutte le varianti e le versioni di PHP sul server, anche quelle non usate.
2. Verificare lo stato dei pacchetti; per i backport della distribuzione cercare nel changelog CVE-2026-109618 e CVE-2026-109619.
3. Aggiornare a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 ovvero al backport confermato.
4. Riavviare PHP-FPM, Apache e LiteSpeed e controllare gli orari di avvio dei processi.
5. Controprova con `php -r 'var_dump(ini_get("memory_hard_limit_percent"));'`; `bool(false)` significa, secondo il manuale, una versione interessata.
6. Mettere al sicuro i log e verificare eventuali anomalie.

Come dimostrare in modo affidabile versione e stato delle patch lo descrive [Verificare correttamente la versione di PHP e lo stato delle patch](https://phpsos.de/it/php2shell/php-version-pruefen/).

## Come aiuta concretamente PHP SOS?

Nel [contratto di manutenzione della sicurezza](https://phpsos.de/it/leistungen/security-wartungsvertrag/) ci occupiamo con il Suo team della manutenzione di base di PHP:

- **Inventario:** tutte le varianti di PHP, versioni, pool e posizioni di configurazione per ogni server.
- **Configurazione:** valori rilevanti per la sicurezza impostati con `php_admin_value`, pool separati per ogni sito web.
- **Aggiornamenti:** installazione, riavvio, controllo e documentazione a ogni rilascio di sicurezza.
- **Trasferire il sapere:** spieghiamo ai Suoi amministratori che cosa abbiamo modificato e perché.


## Domande frequenti

**Perché php -v mostra una versione diversa da quella del sito web?**  
Riga di comando, PHP-FPM e modulo Apache sono programmi separati con versione e php.ini propri. php -v mostra solo la riga di comando. Per il sito web conta la versione del binario che elabora effettivamente le richieste.

**Quale php.ini vale sul mio server?**  
Lo mostra php --ini per la riga di comando. Per PHP-FPM di solito esiste un php.ini proprio e ulteriori file di pool. Da PHP 8.5 php --ini=diff mostra quali valori si discostano dal valore predefinito.

**Qual è la differenza tra php_value e php_admin_value?**  
Entrambi impostano valori in un pool FPM. I valori impostati con php_admin_value, secondo il manuale, l'applicazione non può sovrascriverli con ini_set(). Per le impostazioni rilevanti per la sicurezza php_admin_value è quindi la scelta giusta.

**Basta un aggiornamento senza riavvio?**  
No. I processi PHP in esecuzione mantengono in memoria il vecchio codice. Dopo un aggiornamento vanno riavviati PHP-FPM, Apache con mod_php o LiteSpeed, altrimenti continua a girare la versione vulnerabile.

## Fonti

- [Manuale PHP: opzioni della riga di comando](https://www.php.net/manual/en/features.commandline.options.php)
- [Manuale PHP: configurazione di FPM](https://www.php.net/manual/en/install.fpm.configuration.php)
- [Manuale PHP: impostazioni del core](https://www.php.net/manual/en/ini.core.php)
- [php.net: bollettini di sicurezza](https://www.php.net/)