--- title: "Server Debian fermo a 14 mesi fa: come aggiorno un VPS in produzione con Laravel senza rompere nulla" description: "Aggiornamento di sicurezza su Debian con Laravel in produzione: 247 pacchetti arretrati, 38 CVE, il protocollo per aggiornare senza downtime e senza sorprese." canonical: "https://www.mauriziofonte.it/blog/post/piano-urgente-sicurezza-debian-laravel.html" author: "Maurizio Fonte" date: "2025-07-01T08:45:47+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Informatica" tags: ["Sicurezza Informatica", "VPS & Hosting"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Informatica](https://www.mauriziofonte.it/blog/cat/sicurezza_informatica.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) # [Server Debian fermo a 14 mesi fa: come aggiorno un VPS in produzione con Laravel senza rompere nulla](https://www.mauriziofonte.it/blog/post/piano-urgente-sicurezza-debian-laravel.html) Martedì 1 Luglio 2025, alle 08:45 ![Server Debian fermo a 14 mesi fa: come aggiorno un VPS in produzione con Laravel senza rompere nulla](https://www.mauriziofonte.it/image/001920200-piano-urgente-sicurezza-debian-laravel.jpg) A maggio 2025 ho fatto un audit infrastrutturale per una PMI piemontese che gestisce un portale di prenotazioni B2B nel settore turistico - circa 300 strutture ricettive partner e 12.000 prenotazioni al mese. L'applicazione Laravel 10 girava su un VPS OVH Value (4 vCPU, 8 GB RAM, 160 GB SSD) con Debian 11, PHP 8.1, MySQL 8.0 e Nginx 1.22. Il titolare mi aveva chiamato per un problema di performance, non di sicurezza. Ma il primo comando che eseguo su qualunque server che prendo in carico è sempre lo stesso: ```bash apt list --upgradable 2>/dev/null | wc -l ``` La risposta: 248 righe. Meno una (l'header), faceva 247 pacchetti con aggiornamenti disponibili. L'ultimo `apt upgrade` era stato eseguito il 12 marzo 2024 - quattordici mesi prima. Per un anno e due mesi, il server aveva continuato a servire migliaia di richieste al giorno con OpenSSH vulnerabile a regreSSHion (CVE-2024-6387), PHP 8.1.12 con 7 CVE note nella versione installata, e il kernel Linux 5.10.0-20 quando il corrente era 5.10.0-30 con decine di fix di sicurezza accumulati. L'applicazione funzionava. Il business andava avanti. Nessuno sapeva di essere esposto. Questo è lo scenario più comune che incontro sulle PMI italiane con VPS unmanaged: il server funziona, il sito risponde, nessuno si preoccupa degli aggiornamenti perché "non è rotto, perché aggiustarlo?" La risposta è che un server non aggiornato non è rotto - è aperto. E la differenza tra "funziona" e "è sicuro" è la stessa che c'è tra una porta chiusa e una porta chiusa a chiave. ## Quanto è davvero rischioso non aggiornare un server Debian in produzione? Molto più di quanto la maggior parte dei titolari di PMI pensi. Il [portale ufficiale Debian Security](https://www.debian.org/security/) pubblica advisory per ogni vulnerabilità corretta nei pacchetti della distribuzione stabile. Nel solo 2024-2025, Debian ha emesso oltre 200 DSA (Debian Security Advisory) che coprivano CVE in pacchetti comunemente installati sui server di produzione: OpenSSL, OpenSSH, curl, systemd, PHP, MySQL, Nginx. Ogni advisory non applicato è una porta che qualcuno, da qualche parte, sa come aprire. Sul VPS del cliente piemontese, i 247 pacchetti arretrati si distribuivano così: 38 erano patch di sicurezza pure (provenienti dal repository `debian-security`), 142 erano aggiornamenti di bugfix della distribuzione stabile, 67 erano aggiornamenti di pacchetti PHP dal repository Sury (il PPA standard per PHP su Debian). I 38 security patch erano il rischio immediato. Tra questi, il più critico era OpenSSH 8.4p1 - la versione installata era vulnerabile a [regreSSHion (CVE-2024-6387), una race condition nel signal handler di sshd](https://www.mauriziofonte.it/blog/post/vulnerabilita-ssh-erlang-accesso-remoto-senza-credenziali.html) che potenzialmente permetteva esecuzione remota di codice pre-autenticazione. La patch era disponibile da luglio 2024. Era stata ignorata per 10 mesi. Sul server del cliente piemontese, i rischi concreti erano tre. Il primo era OpenSSH con regreSSHion: un attaccante poteva potenzialmente ottenere una root shell sul server senza autenticazione, sfruttando una race condition nel signal handler. Il secondo era PHP 8.1.12, che aveva CVE note per buffer overflow nella gestione dei file PHAR e per information disclosure nell'estensione LDAP - vulnerabilità meno spettacolari di una RCE, ma che in combinazione con altri vettori potevano facilitare un'escalation. Il terzo era il kernel Linux 5.10.0-20, che era esposto a multiple local privilege escalation - il tipo di vulnerabilità che un attaccante usa dopo aver ottenuto un primo accesso a basso privilegio per diventare root. Il punto che ripeto a ogni titolare è questo: nessuna di queste vulnerabilità ha un exploit "facile" che un ragazzino può lanciare da un portatile. Ma gli attaccanti professionisti - quelli che prendono di mira le PMI per i dati dei clienti o per usare il server come punto di appoggio per attacchi ad altri target - hanno strumenti automatizzati che scansionano internet alla ricerca di server con versioni vulnerabili note. Un server con 14 mesi di arretrato è un bersaglio con un cartello "APERTO" attaccato alla porta. Stai cercando un **Consulente Informatico** esperto per un audit di sicurezza della tua infrastruttura VPS? Nel mio [profilo professionale](https://www.mauriziofonte.it/pages/about) trovi l'esperienza concreta su hardening, aggiornamenti di sicurezza e gestione di server Debian in produzione per PMI. ## Il protocollo: aggiornare senza rompere nulla La paura di aggiornare è comprensibile. Un `apt upgrade` su un server di produzione è un'operazione che può modificare decine di pacchetti simultaneamente, e se qualcosa va storto - un conflitto di dipendenze, un servizio che non riparte, una configurazione sovrascritta - il business si ferma. Ma la soluzione non è non aggiornare: è aggiornare con metodo. Il protocollo che applico si divide in cinque passaggi, nell'ordine. ### Passaggio 1: snapshot del server Prima di qualunque modifica, creo un'immagine del server che possa essere ripristinata in caso di disastro. Su OVH, Hetzner e Contabo questo si fa dalla console del provider (snapshot VPS) in 5-10 minuti. Su provider che non offrono snapshot, faccio un backup completo del filesystem con rsync su uno storage esterno. Per le strategie di backup avanzate che applico prima di operazioni rischiose su VPS, ho scritto una guida dedicata al [backup di VPS unmanaged su Hetzner, OVH, Contabo, Digital Ocean e Aruba](https://www.mauriziofonte.it/blog/post/backup-vps-unmanaged-strategie-avanzate.html). ### Passaggio 2: dry run e analisi dei pacchetti Prima di eseguire il vero upgrade, analizzo cosa verrà installato: ```bash # Simulazione: mostra cosa verrebbe aggiornato senza installare nulla apt-get upgrade --dry-run # Separare security updates dal resto apt-get upgrade -s 2>/dev/null | grep -i security # Verificare se ci sono pacchetti che richiedono rimozione (dist-upgrade) apt-get dist-upgrade --dry-run ``` Il dry run è il momento in cui scopri i problemi prima che diventino emergenze. Sul server del cliente piemontese, il dry run ha rivelato che il pacchetto `libapache2-mod-php8.1` sarebbe stato rimosso perché il server usava Nginx con PHP-FPM, non Apache - ma il pacchetto era rimasto installato come dipendenza residua. Un non-problema in questo caso, ma su un server con Apache sarebbe stato un downtime immediato. ### Passaggio 3: aggiornamento in due fasi La regola che non derogo mai: **prima i security patch, poi il resto**. Questo minimizza il rischio: se i security patch causano un problema, hai aggiornato solo 38 pacchetti su 247, il blast radius è contenuto. Se tutto funziona, procedi con il resto. ```bash # Fase 1: solo security updates apt-get upgrade -y -o Dir::Etc::SourceList=/etc/apt/sources.list.d/debian-security.list # Verifica che i servizi critici siano ancora attivi systemctl is-active nginx php8.1-fpm mysql # Fase 2: il resto degli aggiornamenti apt-get upgrade -y # Se ci sono pacchetti held back (trattenuti), valutare dist-upgrade apt-get dist-upgrade --dry-run ``` ### Passaggio 4: needrestart e riavvio servizi Dopo un aggiornamento, molti servizi continuano a eseguire in memoria il codice della versione precedente - il nuovo binario è su disco ma il processo in esecuzione usa ancora quello vecchio. `needrestart` è lo strumento che risolve questo problema: [identifica i servizi che necessitano un riavvio](https://wiki.debian.org/PeriodicUpdates) e può riavviarli automaticamente: ```bash # Installare needrestart se non presente apt-get install needrestart # Mostrare quali servizi necessitano restart needrestart -l # Riavviare i servizi automaticamente needrestart -ra ``` Sul server del cliente piemontese, dopo l'upgrade, `needrestart` ha identificato 6 servizi da riavviare: sshd, PHP-FPM, MySQL, Nginx, cron e systemd-resolved. Il riavvio di ciascuno è stato sequenziale e controllato - prima MySQL (il più critico, verifica con `mysqladmin ping`), poi PHP-FPM, poi Nginx, infine gli altri. Il downtime totale percepito dagli utenti: zero secondi, perché PHP-FPM e Nginx si riavviano in meno di un secondo con il graceful restart di systemd. Se il kernel è stato aggiornato - e dopo 14 mesi di arretrato lo era sicuramente - il file `/var/run/reboot-required` te lo segnala. Il reboot del server è l'unica operazione che richiede un downtime reale (30-90 secondi), e va pianificata in una finestra di basso traffico. Sul cliente piemontese l'ho schedulata per le 3 di notte, con un cron job che faceva `shutdown -r now` e un monitoring esterno che verificava il ritorno online entro 5 minuti. ### Cosa fare quando l'upgrade rompe qualcosa Sul server del cliente piemontese l'aggiornamento è andato liscio. Ma non sempre è così, e preparare il piano B è parte del protocollo. I problemi più comuni che ho incontrato su server Debian con stack LEMP: - **PHP-FPM non riparte dopo l'upgrade**: solitamente un conflitto di estensioni. Verificare con `php -m` che tutte le estensioni richieste da Laravel siano caricate, confrontando con il `composer check-platform-reqs` del progetto. Se manca un'estensione, `apt install php8.1-NOME` la reinstalla. - **MySQL non riparte**: quasi sempre un cambio nei parametri di configurazione tra minor version. Controllare `journalctl -u mysql -n 50` per l'errore specifico. Nella mia esperienza, il colpevole più frequente è un parametro deprecato nel `my.cnf` - su MySQL 8.0 capita spesso con `query_cache_type` o `innodb_file_format` che sono stati rimossi. - **Nginx rifiuta la configurazione**: raro su security update, ma possibile se vengono aggiornati moduli. `nginx -t` prima del restart mostra l'errore esatto. In tutti i casi, lo snapshot creato al passaggio 1 è la rete di sicurezza: un ripristino completo del VPS dallo snapshot richiede 5-10 minuti sulla console del provider, e riporta il server esattamente allo stato pre-upgrade. È il motivo per cui lo snapshot è il primo passaggio, non un optional. ### Passaggio 5: verifica applicativa Dopo l'aggiornamento, non mi fido del "sembra funzionare". Verifico in modo sistematico: ```bash # PHP-FPM risponde php -v && curl -s -o /dev/null -w "%{http_code}" http://localhost/health # MySQL è operativo mysqladmin ping && mysql -e "SELECT VERSION();" # Laravel risponde senza errori cd /var/www/app && php artisan --version php artisan migrate:status | tail -5 # Nessun errore nei log dopo l'upgrade tail -20 /var/www/app/storage/logs/laravel.log journalctl -u php8.1-fpm --since "1 hour ago" --no-pager | tail -20 ``` ## Mai più: unattended-upgrades per i security patch automatici Dopo aver riportato il server in ordine, il passo finale è fare in modo che la situazione non si ripresenti. L'installazione di `unattended-upgrades` su Debian automatizza l'applicazione dei security patch - e solo quelli, non gli aggiornamenti generici che potrebbero cambiare comportamento. La configurazione che applico su ogni server che gestisco per PMI è conservativa ma efficace: ```bash # Installare e abilitare apt-get install -y unattended-upgrades apt-listchanges dpkg-reconfigure -plow unattended-upgrades ``` ```text // /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Allowed-Origins { "${distro_id}:${distro_codename}-security"; }; // NON aggiornare automaticamente pacchetti critici Unattended-Upgrade::Package-Blacklist { "mysql-server"; "nginx"; }; // Upgrade interrompibile (minimizza il rischio di stato inconsistente) Unattended-Upgrade::MinimalSteps "true"; // Notifica via email solo se qualcosa cambia Unattended-Upgrade::Mail "it@azienda.it"; Unattended-Upgrade::MailReport "on-change"; // NON riavviare automaticamente (preferisco farlo in finestra controllata) Unattended-Upgrade::Automatic-Reboot "false"; ``` La configurazione di `apt-listchanges` è il complemento: ogni volta che `unattended-upgrades` applica un aggiornamento, ricevi via email il changelog del pacchetto aggiornato - così sai esattamente cosa è stato modificato senza dover controllare manualmente. Sui server dei clienti PMI configuro anche un check di Prometheus che monitora il file `/var/run/reboot-required`: se esiste, significa che un aggiornamento del kernel è stato installato ma il server non è stato ancora riavviato - e finché non lo riavvii, stai eseguendo il kernel vecchio con le vulnerabilità vecchie, anche se il pacchetto nuovo è su disco. L'alert che ho descritto nel mio articolo sul [monitoring proattivo con Prometheus e Grafana per Laravel su VPS](https://www.mauriziofonte.it/blog/post/monitoring-proattivo-laravel-vps-unmanaged-prometheus-grafana-alerting.html) include esattamente questo scenario. La blacklist di MySQL e Nginx è intenzionale: gli aggiornamenti di database e web server possono avere effetti collaterali su configurazioni custom (parametri di tuning, moduli caricati, formati di log) e preferisco applicarli manualmente dopo un dry run. I security patch del kernel, di OpenSSH, di OpenSSL e delle librerie di sistema vengono invece applicati automaticamente ogni notte - perché il rischio di lasciarli scoperti è sempre maggiore del rischio di applicarli. Per chi gestisce server Debian con applicazioni PHP e vuole completare l'hardening oltre gli aggiornamenti di sicurezza, ho scritto una guida dedicata all'[hardening di server Debian e Ubuntu per applicativi PHP delle PMI](https://www.mauriziofonte.it/blog/post/hardening-server-debian-ubuntu-applicativi-php-sicurezza-pmi.html) che copre PHP-FPM, permessi, security header e configurazione del web server. Se il tuo VPS non vede un `apt upgrade` da più di tre mesi, hai un debito di sicurezza che si accumula silenziosamente. Ogni settimana che passa senza applicare i security patch aumenta la superficie di attacco del tuo server - e il paradosso è che più aspetti, più l'aggiornamento diventa rischioso perché il delta tra il tuo stato e lo stato corrente cresce. La regola che do a ogni cliente PMI è semplice: i security patch si applicano automaticamente con `unattended-upgrades`, gli aggiornamenti generici dei pacchetti si pianificano mensilmente in una finestra di manutenzione concordata, il kernel si aggiorna trimestralmente con reboot programmato in orario notturno. Il costo di questa disciplina è vicino allo zero - mezza giornata iniziale per il setup, poi il sistema si mantiene da solo. [Contattami](https://www.mauriziofonte.it/pages/contattami) se hai bisogno di un audit dello stato di aggiornamento dei tuoi server: in mezza giornata verifico lo stato dei pacchetti, le CVE esposte e lo stato di `unattended-upgrades`, e ti consegno un piano di remediation con priorità e tempistiche. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteSubentro su codebase Laravel senza documentazione: il metodo in 48 ore per capire cosa hai ereditato1 Luglio 2025](https://www.mauriziofonte.it/blog/post/gestire-subentro-improvviso-sviluppatore-laravel.html)[Articolo successivo »Email transazionali di Laravel che finiscono in spam o non arrivano: diagnosi e fix su VPS unmanaged2 Luglio 2025](https://www.mauriziofonte.it/blog/post/smtp-urgente-vps-laravel.html) ### Articoli correlati a Server Debian fermo a 14 mesi fa: come aggiorno un VPS in produzione con Laravel senza rompere nulla - [Debian 13.5 e i point release: come gestisco gli aggiornamenti di un parco VPS in produzione](https://www.mauriziofonte.it/blog/post/debian-13-5-point-release-aggiornamenti-parco-vps-produzione.html) Debian 13.5 16 maggio 2026 porta fix di sicurezza e stabilità, incluso quello dell'escape nspawn in systemd 257. Come gestisco gli aggiornamenti · 29 Luglio 2026 ![Debian 13.5 e i point release: come gestisco gli aggiornamenti di un parco VPS in produzione](https://www.mauriziofonte.it/image/004960070-debian-13-5-point-release-aggiornamenti-parco-vps-produzione.jpg) - [Le 5 CVE che devi aver patchato sul VPS entro ottobre 2026](https://www.mauriziofonte.it/blog/post/cve-2026-da-patchare-vps-linux-ottobre.html) Due CVE del kernel Linux sono entrate nel catalogo delle vulnerabilità attivamente sfruttate della CISA nel 2026, e altre tre hanno exploit pubblici · 8 Ottobre 2026 ![Le 5 CVE che devi aver patchato sul VPS entro ottobre 2026](https://www.mauriziofonte.it/image/005660070-cve-2026-da-patchare-vps-linux-ottobre.jpg) - [regreSSHion (CVE-2024-6387) un anno e mezzo dopo: anatomia tecnica, lezioni dalla patching delle PMI e hardening SSH che applico oggi](https://www.mauriziofonte.it/blog/post/vulnerabilita-critica-openssh-analisi-tecnica-race-condition-protezione.html) regreSSHion CVE 2024 6387 ha riaperto un buco nella sshd di OpenSSH 18 anni dopo che era stato chiuso. Anatomia del race condition nel signal · 4 Giugno 2025 ![regreSSHion (CVE-2024-6387) un anno e mezzo dopo: anatomia tecnica, lezioni dalla patching delle PMI e hardening SSH che applico oggi](https://www.mauriziofonte.it/image/001620070-vulnerabilita-critica-openssh-analisi-tecnica-race-condition-protezione.jpg) - [Guida all'Aggiornamento da Debian 12 Bookworm a Debian 13 Trixie](https://www.mauriziofonte.it/blog/post/guida-aggiornamento-da-debian-12-bookworm-a-debian-13-trixie.html) Il tuo server Debian 12 "Bookworm" è stabile, ma il supporto di sicurezza standard è già scaduto e il sistema è entrato nel ciclo LTS. Debian · 25 Agosto 2025 ![Guida all'Aggiornamento da Debian 12 Bookworm a Debian 13 Trixie](https://www.mauriziofonte.it/image/002140070-guida-aggiornamento-da-debian-12-bookworm-a-debian-13-trixie.jpg) - [Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html) Senza un efficace hardening dei server, la tua azienda è vulnerabile a gravi attacchi informatici. Scopri perché implementare subito questa strategia · 22 Mag 2025 ![Hardening dei server: come proteggere la tua azienda da attacchi informatici devastanti](https://www.mauriziofonte.it/image/001250070-hardening-server-protezione-attacchi-informatici.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Server Debian fermo a 14 mesi fa: come aggiorno un VPS in produzione con Laravel senza rompere nulla", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/piano-urgente-sicurezza-debian-laravel.html Pubblicato: 2025-07-01 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.