NexTool Solutions

Jede Login-Seite, die im Internet erreichbar ist, erhält Versuche, Passwörter zu erraten, und die des GLPI ist keine Ausnahme. Standardmäßig begrenzt GLPI nicht, wie oft jemand ein falsches Passwort eingeben darf. Security Guard, ein für NexTool-Kunden kostenloses Modul von NexTool, zählt die Fehlversuche beim Web-Login, in der API, bei CalDAV und bei der Passwort-Wiederherstellung, sperrt vorübergehend, wer das Limit überschreitet, und zeigt alles in einem Dashboard an, ohne den Benutzernamen im Klartext zu speichern.

Das Problem: Brute Force beim GLPI-Login

Brute Force ist der einfachste Angriff, den es gibt: Ein Bot probiert Kombinationen aus Benutzername und Passwort, bis er trifft. Bekannte Varianten sind Credential Stuffing (geleakte Passwörter anderer Dienste, die in Ihrem GLPI getestet werden) und Password Spraying (ein gängiges Passwort wie Mudar@123, das gleichzeitig an vielen Konten getestet wird). GLPI speichert die Tickets, das Inventar, die Verträge und die personenbezogenen Daten derjenigen, die Tickets erstellen. Ein kompromittiertes Technikerkonto öffnet all das.

Im Standard-GLPI akzeptiert der Web-Login unbegrenzt viele Versuche. Man kann am Netzwerkrand gegensteuern (WAF, fail2ban, das das Log des Webservers liest), aber diese Lösungen kennen GLPI nicht: Sie wissen nicht, ob der Versuch erfolgreich war, unterscheiden nicht zwischen Benutzer und IP und sperren oft versehentlich den Proxy des gesamten Unternehmens. Es fehlte ein Schutz innerhalb von GLPI selbst, der das tatsächliche Ergebnis des Logins versteht.

So funktioniert Security Guard

Bei eingeschaltetem Schutz prüft das Modul jeden Authentifizierungsversuch in den unten genannten Kanälen, protokolliert das Ergebnis, etwa Erfolg, Fehlschlag, Verweigert (Sperre), Ignoriert oder MFA ausstehend, und prüft die von Ihnen definierten Regeln. Wenn eine Regel greift, erhalten die nächsten Versuche dieses Schlüssels HTTP 429 in dem Format, das der Client versteht: eine Seite zur vorübergehenden Sperre im Browser, JSON in den APIs und Text bei CalDAV, bis die Frist abläuft oder ein Administrator die Sperre aufhebt. Solange die Sperre aktiv ist, werden abgewiesene Versuche nicht zu Ereignissen: Sie erhöhen nur den Zähler der Sperre.

• Web-Login: das Formular unter /front/login.php.
• REST-API (v1): initSession mit Login und Passwort, Basic Auth oder user_token. Bei user_token gibt es keinen Benutzer, daher zählen nur die Regeln nach IP. In GLPI 11 gilt auch der Pfad /api.php/v1.
• API v2 von GLPI 11: die Token-Anforderung unter /api.php/token mit Benutzername und Passwort.
• CalDAV (Basic Auth): Da sich der Kalender-Client bei jeder Synchronisierung authentifiziert, werden nur falsche Passwörter und verweigerte Zugriffe zu Ereignissen; der korrekte Zugriff wird nicht protokolliert.
• Passwort-Wiederherstellung (lostpassword.php): Jede Anforderung eines neuen Passworts zählt als Versuch, nach IP oder nach der angegebenen E-Mail-Adresse. GLPI antwortet bei richtiger und falscher E-Mail-Adresse gleich, daher begrenzt die Regel das Volumen der Anforderungen und verhindert Massenversand und das Durchsuchen von E-Mail-Adressen.
• MFA/TOTP-Code von GLPI 11: Die Versuche erscheinen in den Ereignissen, mit Erfolg und Fehlschlag, aber das Modul begrenzt den Code nicht, weil GLPI 11 selbst bereits nach mehreren Fehlversuchen sperrt.

In der Konsole bietet das Modul:

• Regeln nach Geltungsbereich: Jede Regel legt das Zeitfenster (in Minuten), das Fehlerlimit und die Sperrdauer fest. Der Geltungsbereich kann Benutzer, IP oder Benutzer + IP sein, mit Priorität zwischen den Regeln und optionalem Filter nach IP-Bereich (CIDR) oder Land. Im Feld Kanäle wählt die Regel, wo sie zählt: Web-Login, REST-API, API v2, CalDAV oder Passwort-Wiederherstellung. Eine neue Regel wird mit allen Kanälen markiert angelegt. Die Installation bringt zwei fertige, inaktive Regeln mit: Benutzer + IP (5 Fehlversuche in 15 Minuten, Sperre von 15 Minuten) und IP (30 Fehlversuche in 15 Minuten, Sperre von 30 Minuten).
• Ausnahmen: Benutzer, Gruppe, Profil, Netzwerk (CIDR) oder Land, die nie gesperrt werden, auch wenn eine Regel greift. Jede Ausnahme kann eine Gültigkeit mit Start- und Enddatum haben.
• GeoIP: Mit einer MaxMind-GeoLite2-Country-Datenbank, die direkt über die Oberfläche hochgeladen wird, ermittelt das Modul das Land jeder IP. Das speist das Dashboard und ermöglicht Regeln und Ausnahmen nach Land.
• Dashboard: Summen der letzten 24 Stunden nach Ergebnis, die Zeile „Letzte 24 Std., nach Kanal“, aktive Sperren, Regeln und Ausnahmen sowie die Top 10 der IPs, Benutzer (maskiert) und Länder mit den meisten Fehlversuchen und verweigerten Versuchen der letzten 7 Tage.
• Sperren: Liste der aktiven Sperren mit Schaltfläche zum Aufheben, Anlegen manueller Sperren und vollständiger Verlauf.
• Ereignisse: die bewerteten und klassifizierten Versuche, in der nativen Suche von GLPI, mit der Spalte Kanal und stets maskiertem Benutzer. Versuche, die während einer aktiven Sperre abgewiesen werden, erscheinen nur im Zähler der Sperre.
• Test: Simulatoren für die IP-Ermittlung und für Login-Versuche, die nichts speichern; beim Versuchssimulator lässt sich der Kanal wählen. Sie erfahren, was passieren würde, bevor Sie eine Regel aktivieren.

Ein Detail, das den Unterschied macht: Das Modul klassifiziert das tatsächliche Ergebnis des Versuchs anhand der Antwort, die GLPI zurückgegeben hat, und zählt den Versuch, sobald er beginnt. Ein Bot, der Dutzende Anfragen parallel abschickt, kann das Limit nicht durch eine Race Condition zwischen ihnen überschreiten.

Sichere Aktivierung, Schritt für Schritt

Security Guard startet ausgeschaltet: Der Schutz ist deaktiviert, und die beiden bei der Installation angelegten Regeln sind inaktiv. Die Installation des Moduls sperrt niemanden. Allerdings protokolliert das Modul bei ausgeschaltetem Schutz überhaupt nichts: „Erst beobachten, dann sperren“ funktioniert bei ausgeschaltetem Schalter nicht. Der sichere Weg ist, den Schutz bei noch inaktiven Regeln einzuschalten und den Reiter Test zu nutzen. Die folgende Reihenfolge ist wichtig, denn eine falsche Proxy-Konfiguration kann das gesamte Unternehmen sperren.

1. Installieren und aktivieren Sie das Modul unter NexTool > Module > Security Guard. Die Konsole befindet sich unter NexTool > Security Guard.
2. Konfigurieren Sie die vertrauenswürdigen Proxys, BEVOR Sie den Schutz einschalten. Tragen Sie im Reiter Einstellungen im Feld Vertrauenswürdige Proxys (CIDR) das Netzwerk des Reverse Proxys ein, der vor dem GLPI steht (Nginx, NPM, HAProxy, Load Balancer). Ohne diese Angabe ignoriert das Modul den Header X-Forwarded-For absichtlich (er kann gefälscht werden) und sieht die IP des Proxys, nicht die des Benutzers.
3. Wenn das GLPI hinter Cloudflare steht, klicken Sie auf Cloudflare-Bereiche hinzufügen. Die Schaltfläche ergänzt das Feld um die offiziellen Bereiche des CDN, ohne vorhandene Einträge zu löschen und ohne selbst zu speichern. Behalten Sie auch das Netzwerk Ihres lokalen Proxys bei und speichern Sie. Ohne die Cloudflare-Bereiche wäre die ermittelte IP der Rand des CDN, den Tausende Menschen gemeinsam nutzen.
4. Prüfen Sie den IP-Header. Standard ist X-Forwarded-For; ändern Sie ihn nur, wenn Ihr Proxy X-Real-IP oder Forwarded verwendet.
5. Prüfen Sie die Karte „IP dieser Anfrage“. Sie zeigt die REMOTE_ADDR, den empfangenen Header und die IP, die das Modul jetzt ermitteln würde. Die ermittelte IP muss die Ihres Computers sein, nicht die des Proxys. Wenn die Warnung „Wahrscheinlicher Proxy nicht konfiguriert“ erscheint, halten Sie an und kehren Sie zu Schritt 2 zurück.
6. Schalten Sie den Schutz gegen Brute Force bei noch inaktiven Regeln ein. Ohne aktive Regel und ohne manuelle Sperre wird niemand gesperrt, und das Dashboard sowie der Reiter Ereignisse zeigen nun die klassifizierten Versuche. Bestätigen Sie mit dem Reiter Test, dass ein normaler Versuch von Ihnen nicht gesperrt würde.
7. Aktivieren Sie erst dann eine Regel mit Geltungsbereich Benutzer + IP im Reiter Regeln und prüfen Sie im Feld Kanäle, wo sie zählen wird. Die fertige Regel ist mit 5 Fehlversuchen in 15 Minuten und einer Sperre von 15 Minuten voreingestellt.

Bewährte Vorgehensweisen

• Bevorzugen Sie den Geltungsbereich Benutzer + IP. Er erfasst den Bot, der von einer Adresse aus ein Konto bearbeitet, ohne Nebenwirkungen für die anderen Benutzer.
• Vorsicht mit dem Geltungsbereich Benutzer allein. Er ermöglicht es jedem, das Konto eines Kollegen zu sperren, indem er absichtlich dessen Passwort falsch eingibt. Wenn Sie ihn verwenden, dann mit hohem Limit und kurzer Dauer.
• Vorsicht mit dem Geltungsbereich IP allein hinter NAT. Ein ganzes Büro geht oft über dieselbe öffentliche IP ins Internet. Eine reine IP-Regel mit niedrigem Limit bestraft alle für den Fehler eines Einzelnen. Wenn Sie sie verwenden, setzen Sie das Limit deutlich höher als bei der Regel Benutzer + IP (die fertige Regel ist mit 30 Fehlversuchen in 15 Minuten voreingestellt).
• Legen Sie Ausnahmen mit Bedacht an. Das Netzwerk der Zentrale, ein Integrationsprofil oder ein Monitoring-Konto können als Ausnahme eingetragen werden, vorzugsweise mit Gültigkeitszeitraum.
• Vorsicht mit Integrationen über die API. Ein über die API angebundenes System, das in einer Schleife das falsche Passwort verwendet (zum Beispiel ein altes Passwort), sperrt seine eigene IP. Tragen Sie dessen Netzwerk als Ausnahme ein oder deaktivieren Sie diesen Kanal in der Regel.
• Verwenden Sie bei der Passwort-Wiederherstellung ein höheres Limit als beim Login und bevorzugen Sie den Geltungsbereich IP oder Benutzer + IP.
• Halten Sie die GeoIP-Datenbank aktuell. Die Aktualisierung erfolgt manuell; die Karte warnt, wenn die Datenbank älter als 60 Tage ist.

Datenschutz

Das Protokollieren von Login-Versuchen betrifft personenbezogene Daten, daher sollten Sie genau wissen, was das Modul speichert:

• Der Benutzername wird nie im Klartext gespeichert. Die Korrelation erfolgt über einen HMAC-SHA256 mit einem eigenen Schlüssel der Installation, und die Oberfläche zeigt nur eine Maske (erster und letzter Buchstabe). Bei erfolgreichen Logins speichert das Ereignis zusätzlich die Benutzer-ID im GLPI.
• Die bei Anforderungen eines neuen Passworts angegebene E-Mail-Adresse folgt derselben Regel: Sie wird nur als HMAC gespeichert, und die Oberfläche zeigt nur eine Maske.
• IP und Land werden im Klartext gespeichert, weil sie der eigentliche Gegenstand des Schutzes sind.
• Bei den Ereignissen legen Sie die Aufbewahrungsfrist selbst fest: standardmäßig 90 Tage und 30 Tage für das Administrationslog. Die Bereinigung übernimmt die automatische Aktion secguardmaintenance alle 5 Minuten im externen Modus: Sie setzt voraus, dass der GLPI-Cron auf dem Server eingerichtet ist.
• In dieser Version läuft der Verlauf der Sperren nicht ab; er wird nur mit der Aktion „Daten löschen“ entfernt.
• Die Deinstallation des Moduls bewahrt die Daten; das Löschen erfordert die ausdrückliche Aktion „Daten löschen“ mit eigener Berechtigung.

Berechtigungen pro Bildschirm

Security Guard ist eine reine Administrationskonsole. Die Rechte befinden sich unter Verwaltung > Profile > Reiter NexTool und unterscheiden sich je nach Bildschirm:

• Dashboard: Dashboard anzeigen;
• Ereignisse: Ereignisse anzeigen;
• Sperren: Sperren anzeigen, Sperren aufheben und Manuelle Sperre anlegen;
• Regeln: Regeln anzeigen und Regeln verwalten;
• Ausnahmen: Ausnahmen anzeigen und Ausnahmen verwalten;
• Einstellungen und Reiter Test: Konfigurieren;
• Logs: Logs anzeigen.

Eine Aktion erfordert immer auch das Recht, den Bildschirm zu sehen: Wer nur „Sperren aufheben“ ohne „Sperren anzeigen“ hat, kann nichts aufheben. So kann das First-Level-Team zum Beispiel einen gesperrten Benutzer freigeben, ohne die Regeln ändern zu können.

Einschränkungen dieser Version

Um es direkt zu sagen: Version 0.2.0 deckt den Web-Login, die REST-API, die API v2 von GLPI 11, CalDAV und die Passwort-Wiederherstellung ab. Weiterhin nicht oder nur teilweise abgedeckt sind:

• Logins per SSO, SAML oder REMOTE_USER, die nicht über das GLPI-Passwort laufen;
• der MFA/TOTP-Code von GLPI 11: Die Versuche erscheinen in den Ereignissen, aber das Modul begrenzt den Code nicht, weil GLPI 11 selbst bereits nach mehreren Fehlversuchen sperrt.

Außerdem gibt es keine Benachrichtigung über Sperren: weder E-Mail noch Warnung noch Webhook. Die Überwachung erfolgt über die Konsole, im Dashboard und in den Reitern Sperren und Ereignisse.

Für wen es geeignet ist

Für alle, die GLPI im Internet für externe Techniker, Kunden oder Niederlassungen bereitstellen; für Dienstleister, die mehrere GLPIs betreiben und bei Audits eine Zugriffskontrolle nachweisen müssen; und für alle, die im Log des Webservers schon Hunderte POSTs auf den Login von derselben Quelle gesehen haben.

Kompatibilität

• Version: 0.2.0
• GLPI: 10 und 11 (dasselbe Artefakt läuft auf beiden)
• Plugin: NexTool 6.22.0 oder höher
• Plan: Kostenlos
• Sprachen: Oberflächen auf Portugiesisch (Brasilien und Portugal), Englisch (USA und Vereinigtes Königreich), Spanisch (Spanien und Mexiko), Französisch, Italienisch und Deutsch

Nächster Schritt

Security Guard ist Teil von NexTool, einem Ökosystem von Modulen, um GLPI ohne Code-Anpassungen zu erweitern. Sehen Sie sich die Seite des Moduls an oder sprechen Sie mit dem Team für eine Demonstration.

Geprüft vom Team von NexTool Solutions. Die Screenshots stammen aus der realen GLPI-Umgebung mit dem NexTool-Plugin; IPs und Benutzer wurden durch Dokumentationsbereiche und Masken ersetzt.