La Sua istanza di GLPI è esposta a vulnerabilità già catalogate senza che Lei lo sappia? Nella maggior parte dei parchi che assumiamo in manutenzione, nessuno sa dire subito quale CVE riguarda la versione in produzione né se PHP ha i flag di sicurezza corretti. Il modulo CVE Scan Vulnerabilità di NexTool incrocia la versione installata con basi pubbliche di CVE e verifica 19 punti critici dell'ambiente in pochi secondi, generando un Security Score visivo.
Il problema
I team di service desk che gestiscono GLPI raramente hanno un processo formale per tracciare le vulnerabilità legate alla versione in produzione. L'NVD (NIST) e il GitHub Advisory Database pubblicano CVE di continuo, ma seguirlo a mano, versione per versione, è impraticabile per chi apre e chiude anche ticket tutto il giorno.
Peggio: la versione del software è solo metà del rischio. L'ambiente PHP e la configurazione del server introducono falle silenziose - display_errors attivo in produzione che espone percorsi e stack trace, un cookie di sessione senza HttpOnly, l'assenza di Content-Security-Policy o di Strict-Transport-Security. Ognuno di questi dettagli è una superficie d'attacco che di solito emerge solo dopo l'incidente, quando è già tardi.
Come funziona CVE Scan
All'avvio della scansione, il modulo rileva la versione tramite la costante GLPI_VERSION e la incrocia con una base dinamica di CVE costruita da tre fonti:
- NVD / NIST - la fonte autorevole per il punteggio CVSS e i metadati ufficiali di ogni falla.
- GitHub Advisory Database - gli advisory pubblicati dal progetto GLPI stesso, con le versioni colpite e la versione che corregge ogni falla per linea di versione (come 10.0 e 11.0), oltre al link dell'advisory.
- Base statica di riserva - elenco integrato nel modulo con le falle critiche e alte, usato prima del primo aggiornamento della base e negli ambienti che non raggiungono né GitHub né l'NVD.
L'unione avviene per CVE ID: l'NVD prevale per il CVSS, GitHub fornisce gli intervalli di versione e i link di advisory. La base locale viene aggiornata ogni giorno da un'azione automatica e, su richiesta, dal pulsante Aggiorna database; la scansione in sé non interroga né GitHub né l'NVD, e se entrambe le fonti falliscono resta valida la base precedente. In parallelo all'incrocio delle CVE, il modulo esegue 19 verifiche di sicurezza dell'ambiente, raggruppate in cinque categorie: configurazione PHP (8 check), verifiche specifiche di GLPI (4, tra cui le password predefinite degli account di installazione), header HTTP (4), permessi dei file (2) e versione di PHP (1), che segnala un PHP fuori dal supporto di sicurezza. Il risultato diventa un Security Score da 0 a 100, con una fascia di colore - rosso per critico, giallo per moderato e verde per sano - e ogni voce mostra lo stato, la versione che corregge la falla e l'istruzione di correzione.
Ciò che vede e che GLPI nativo non mostra
| Punto verificato | GLPI nativo | Modulo CVE Scan |
|---|---|---|
| CVE della versione installata | Nessun avviso | Incrocia GLPI_VERSION con NVD e GitHub Advisory |
| Directory install/ dimenticata | Avviso nella schermata di login | Segnalato nello score quando l'installer risponde dal web, con istruzione di rimozione |
| display_errors in produzione | Non verifica | Check dedicato |
| Header CSP / HSTS / X-Frame-Options / X-Content-Type-Options | Non verifica | Quattro check di header HTTP |
| Permesso di config_db.php | Nessun avviso | Check dedicato |
| Evoluzione del rischio nel tempo | Assente | Security Score registrato a ogni scansione |
Cosa abbiamo imparato usandolo sul campo
In manutenzione, il check che fallisce più spesso in un ambiente cliente è session.cookie_secure - e quasi sempre la causa è fuori da GLPI. GLPI è dietro un reverse proxy che termina il TLS, quindi PHP vede la connessione come http e non marca il cookie come sicuro. La correzione non è in GLPI: è sistemare l'header X-Forwarded-Proto sul proxy e forzare HSTS al bordo. Il secondo più frequente è la directory install/ dimenticata dopo il setup. GLPI lo segnala nella schermata di login, ma su un parco di decine di istanze quell'avviso passa inosservato - è lo score consolidato che obbliga il team a guardare. Per questo trattiamo CVE Scan come un termometro, non come un verdetto: indica il punto, ma la decisione di correggere alla fonte giusta resta di chi gestisce l'ambiente.
Verificare gli stessi punti a mano
Prima di installare qualsiasi cosa, può riprodurre parte della diagnosi direttamente sul server. Questi sono esattamente alcuni dei punti che il modulo verifica in PHP e nel filesystem:
# Flag PHP verificati da CVE Scan (da eseguire sul server GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'
# Permesso del file delle credenziali del database: deve essere 400 o 440, mai 644
stat -c '%a %n' /var/www/glpi/config/config_db.php
# Directory di installazione che avrebbe dovuto essere rimossa dopo il setup
test -f /var/www/glpi/install/install.php && echo 'ALLARME: install/ ancora presente - rimuovere'
# Versione di PHP: avvisare se e a fine vita (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'Il modulo automatizza tutto questo, aggiunge l'incrocio con le basi di CVE e conserva lo storico - ma già eseguire i comandi qui sopra mostra perché l'audit manuale non scala oltre due o tre istanze.
Come attivarlo
- Installi il plugin NexTool sul Suo GLPI.
- Vada su Configurazione > NexTool > Moduli.
- Individui la scheda CVE Scan Vulnerabilità, clicchi su Installa e poi su Attiva.
- Apra il modulo e clicchi su Aggiorna database e poi su Eseguire la scansione nel Pannello.
- Opzionale: inserisca un token GitHub e una API Key NVD nella scheda di configurazione per aumentare i limiti di richiesta delle basi esterne.
Per chi è (e quando no)
È per amministratori GLPI che hanno bisogno di un audit di sicurezza rapido e ricorrente, team che affrontano audit interni o esterni e servono prove dello stato dell'ambiente, e responsabili che vogliono seguire la postura di sicurezza nel tempo tramite lo storico delle scansioni. Non è una bacchetta magica: non sostituisce un pentest, non corregge nulla da solo e non deve diventare una scusa per rimandare l'aggiornamento di GLPI. Se il Suo ambiente ha già uno scanner aziendale (Nessus, Qualys) puntato sullo stesso host, CVE Scan è un complemento leggero e specifico di GLPI, non un concorrente.
Compatibilità
- GLPI: 10.x e 11.x
- Piano: FREE
- Plugin: NexTool 6.11.0 o superiore
Prossimo passo
CVE Scan Vulnerabilità fa parte di NexTool, il plugin modulare per GLPI. Scopra gli altri moduli o parli con il team per una valutazione di sicurezza completa del Suo ambiente.
Revisionato dal team NexTool Solutions.
