Ist Ihre GLPI-Instanz bereits katalogisierten Schwachstellen ausgesetzt, ohne dass Sie es wissen? In den meisten Landschaften, die wir in den Betrieb übernehmen, kann niemand auf Anhieb sagen, welche CVE die produktive Version betrifft oder ob PHP mit den richtigen Sicherheitsflags läuft. Das Modul CVE Scan Vulnerabilidades von NexTool gleicht die installierte Version mit öffentlichen CVE-Datenbanken ab und prüft in Sekunden 19 kritische Punkte der Umgebung, woraus ein visueller Security Score entsteht.
Das Problem
Service-Desk-Teams, die GLPI betreiben, haben selten einen formalen Prozess, um die Schwachstellen der produktiven Version zu verfolgen. NVD (NIST) und die GitHub Advisory Database veröffentlichen laufend CVEs, aber diese manuell, Version für Version, zu verfolgen, ist für ein Team, das den ganzen Tag Tickets eröffnet und schließt, nicht machbar.
Schlimmer noch: Die Softwareversion ist nur die Hälfte des Risikos. Die PHP-Umgebung und die Serverkonfiguration bringen stille Lücken mit sich - display_errors in Produktion aktiviert, wodurch Pfade und Stack Traces preisgegeben werden, Sitzungscookies ohne HttpOnly, fehlende Content-Security-Policy oder Strict-Transport-Security. Jedes dieser Details ist eine Angriffsfläche, die meist erst nach dem Sicherheitsvorfall auffällt, wenn es bereits zu spät ist.
So funktioniert CVE Scan
Beim Ausführen des Scans erkennt das Modul die Version über die Konstante GLPI_VERSION und gleicht sie mit einer dynamischen CVE-Datenbank ab, die aus drei Quellen aufgebaut wird:
- NVD / NIST - maßgebliche Quelle für die CVSS-Bewertung und die offiziellen Metadaten jeder Lücke.
- GitHub Advisory Database - die vom GLPI-Projekt selbst veröffentlichten Advisories mit den betroffenen Versionen und der Version, die jede Lücke je Versionslinie (etwa 10.0 und 11.0) behebt, sowie dem Link zum Advisory.
- Statische Fallback-Datenbank - eine im Modul eingebettete Liste mit den kritischen und hohen Lücken, die vor der ersten Aktualisierung der Datenbank und in Umgebungen ohne Zugang zu GitHub und NVD verwendet wird.
Die Zusammenführung erfolgt anhand der CVE-ID: NVD hat beim CVSS Vorrang, GitHub liefert die Versionsbereiche und die Advisory-Links. Die lokale Datenbank wird täglich durch eine automatische Aktion aktualisiert und bei Bedarf über die Schaltfläche Datenbank aktualisieren; der Scan selbst fragt weder GitHub noch NVD ab, und wenn beide Quellen ausfallen, bleibt die vorherige Datenbank gültig. Parallel zum CVE-Abgleich führt das Modul 19 Sicherheitsprüfungen der Umgebung durch, gruppiert in fünf Kategorien: PHP-Konfiguration (8 Prüfungen), GLPI-spezifische Prüfungen (4, darunter die Standardpasswörter der Installationskonten), HTTP-Header (4), Dateiberechtigungen (2) und PHP-Version (1), die auf PHP außerhalb des Sicherheitssupports hinweist. Das Ergebnis ist ein Security Score von 0 bis 100 mit Farbstufe - Rot für kritisch, Gelb für mittel und Grün für gesund -, und jeder Eintrag zeigt den Status, die Version, die die Lücke behebt, und die Anleitung zur Behebung.
Was es sieht, das natives GLPI nicht zeigt
| Geprüfter Punkt | Natives GLPI | Modul CVE Scan |
|---|---|---|
| CVEs der installierten Version | Kein Hinweis | Gleicht GLPI_VERSION mit NVD und GitHub Advisory ab |
| Vergessenes Verzeichnis install/ | Hinweis auf der Anmeldeseite | Im Score markiert, wenn der Installer über das Web erreichbar ist, mit Anleitung zur Entfernung |
| display_errors in Produktion | Keine Prüfung | Eigene Prüfung |
| Header CSP / HSTS / X-Frame-Options / X-Content-Type-Options | Keine Prüfung | Vier HTTP-Header-Prüfungen |
| Berechtigung von config_db.php | Kein Hinweis | Eigene Prüfung |
| Entwicklung des Risikos über die Zeit | Nicht vorhanden | Security Score bei jedem Scan gespeichert |
Was wir im Praxiseinsatz gelernt haben
Im Betrieb fällt in Kundenumgebungen am häufigsten die Prüfung session.cookie_secure durch - und die Ursache liegt fast immer außerhalb von GLPI. GLPI steht hinter einem Reverse Proxy, der TLS terminiert, daher sieht PHP die Verbindung als http und markiert das Cookie nicht als sicher. Die Korrektur erfolgt nicht im GLPI: Sie besteht darin, den Header X-Forwarded-Proto im Proxy korrekt zu setzen und HSTS am Edge zu erzwingen. Der zweite Spitzenreiter ist das nach dem Setup vergessene Verzeichnis install/. GLPI weist auf der Anmeldeseite zwar darauf hin, doch in Landschaften mit Dutzenden Instanzen geht dieser Hinweis unter - erst der konsolidierte Score zwingt das Team hinzusehen. Deshalb behandeln wir CVE Scan als Thermometer, nicht als Urteil: Es zeigt die Stelle, aber die Entscheidung, an der richtigen Quelle zu korrigieren, bleibt beim Betriebsteam.
Dieselben Punkte von Hand prüfen
Noch bevor Sie etwas installieren, können Sie einen Teil der Diagnose direkt auf dem Server nachvollziehen. Dies sind genau einige der Punkte, die das Modul in PHP und im Dateisystem prüft:
# Flags de PHP que o CVE Scan audita (rodar no servidor do GLPI)
php -i | grep -Ei 'display_errors|expose_php|allow_url_include|cookie_httponly|cookie_secure'
# Permissao do arquivo de credenciais do banco: deve ser 400 ou 440, nunca 644
stat -c '%a %n' /var/www/glpi/config/config_db.php
# Diretorio de instalacao que deveria ter sido removido apos o setup
test -f /var/www/glpi/install/install.php && echo 'ALERTA: install/ ainda presente - remover'
# Versao do PHP: alertar se estiver em fim de vida (EOL)
php -r 'echo PHP_VERSION, PHP_EOL;'Das Modul automatisiert dies, ergänzt den Abgleich mit den CVE-Datenbanken und speichert die Historie - aber schon die obigen Befehle zeigen, warum die manuelle Prüfung bei mehr als zwei oder drei Instanzen nicht skaliert.
Aktivierung
- Installieren Sie das NexTool-Plugin in Ihrem GLPI.
- Öffnen Sie Einrichtung > NexTool > Module.
- Suchen Sie die Karte CVE Scan Vulnerabilidades, klicken Sie auf Installieren und anschließend auf Aktivieren.
- Öffnen Sie das Modul und klicken Sie im Dashboard auf Datenbank aktualisieren und danach auf Scan ausführen.
- Optional: Hinterlegen Sie auf dem Reiter Einstellungen einen GitHub-Token und einen NVD-API-Key, um die Anfragelimits der externen Datenbanken zu erhöhen.
Für wen es geeignet ist (und wann nicht)
Es eignet sich für GLPI-Administratoren, die eine schnelle und wiederkehrende Sicherheitsprüfung brauchen, für Teams, die interne oder externe Audits durchlaufen und den Zustand der Umgebung belegen müssen, und für Führungskräfte, die die Entwicklung der Sicherheitslage anhand der Scan-Historie verfolgen möchten. Es ist kein Allheilmittel: Es ersetzt keinen Pentest, behebt nichts von selbst und sollte nicht zur Ausrede werden, das GLPI-Update aufzuschieben. Wenn Ihre Umgebung bereits einen Unternehmensscanner (Nessus, Qualys) auf denselben Host richtet, ist CVE Scan eine leichtgewichtige, GLPI-spezifische Ergänzung, kein Konkurrent.
Kompatibilität
- GLPI: 10.x und 11.x
- Plan: FREE
- Plugin: NexTool 6.11.0 oder höher
Nächster Schritt
CVE Scan Vulnerabilidades ist Teil von NexTool, dem modularen Plugin für GLPI. Lernen Sie die weiteren Module kennen oder sprechen Sie mit dem Team über eine vollständige Sicherheitsbewertung Ihrer Umgebung.
Geprüft vom Team der NexTool Solutions.
