NexTool Solutions

Tout écran de connexion exposé sur internet reçoit des tentatives pour deviner le mot de passe, et celui de GLPI ne fait pas exception. Par défaut, GLPI ne limite pas le nombre d'erreurs de mot de passe. Security Guard, module NexTool gratuit pour les clients NexTool, compte les échecs sur la connexion web, l'API, CalDAV et la récupération du mot de passe, bloque temporairement ceux qui dépassent la limite et affiche tout sur un tableau de bord, sans conserver le nom d'utilisateur en clair.

Le problème : la force brute sur la connexion GLPI

La force brute est l'attaque la plus simple qui soit : un robot essaie des combinaisons d'identifiant et de mot de passe jusqu'à trouver la bonne. Ses variantes connues sont le credential stuffing (des mots de passe divulgués ailleurs testés sur votre GLPI) et le password spraying (un mot de passe courant, comme Changer@123, testé sur de nombreux comptes à la fois). GLPI contient les tickets, l'inventaire, les contrats et les données personnelles de ceux qui ouvrent des tickets. Un compte de technicien compromis ouvre l'accès à tout cela.

Dans GLPI de base, la connexion web accepte les tentatives indéfiniment. On peut atténuer le risque en périphérie (WAF, fail2ban qui lit le journal du serveur web), mais ces outils ne connaissent pas GLPI : ils ne savent pas si la tentative a réussi, ne distinguent pas l'utilisateur de l'IP et bloquent souvent par erreur le proxy de toute l'entreprise. Il manquait une protection au sein même de GLPI, qui comprenne le résultat réel de la connexion.

Comment fonctionne Security Guard

Lorsque la protection est activée, le module examine chaque tentative d'authentification sur les canaux ci-dessous, enregistre le résultat, par exemple Succès, Échec, Refusé (blocage), Ignoré ou MFA en attente, et vérifie les règles que vous avez définies. Quand une règle est dépassée, les tentatives suivantes pour cette clé reçoivent un HTTP 429 dans le format que le client comprend : une page de blocage temporaire dans le navigateur, du JSON sur les API et du texte sur CalDAV, jusqu'à l'expiration du délai ou jusqu'à ce qu'un administrateur lève le blocage. Tant que le blocage est actif, les tentatives refusées ne deviennent pas des événements : elles s'ajoutent seulement au compteur du blocage.

• Connexion web : le formulaire sur /front/login.php.
• API REST (v1) : initSession avec identifiant et mot de passe, Basic Auth ou user_token. Avec user_token, il n'y a pas d'utilisateur : seules les règles par IP comptent. Sur GLPI 11, le chemin /api.php/v1 est aussi couvert.
• API v2 de GLPI 11 : la demande de jeton sur /api.php/token avec identifiant et mot de passe.
• CalDAV (Basic Auth) : comme le client d'agenda s'authentifie à chaque synchronisation, seuls les mots de passe erronés et les accès refusés deviennent des événements ; un accès correct n'enregistre rien.
• Récupération du mot de passe (lostpassword.php) : chaque demande de nouveau mot de passe compte comme une tentative, par IP ou par l'adresse e-mail saisie. GLPI répond de la même façon pour une adresse correcte ou non : la règle limite donc le volume de demandes et freine les envois en masse et le balayage d'adresses e-mail.
• Code MFA/TOTP de GLPI 11 : les tentatives apparaissent dans les événements, en succès comme en échec, mais le module ne limite pas le code, car GLPI 11 bloque déjà lui-même après plusieurs tentatives erronées.

Dans la console, le module propose :

• Règles par portée : chaque règle définit la fenêtre (en minutes), la limite d'échecs et la durée du blocage. La portée peut être Utilisateur, IP ou Utilisateur + IP, avec une priorité entre règles et un filtre facultatif par plage d'IP (CIDR) ou par pays. Dans le champ Canaux, chaque règle choisit où elle compte : connexion web, API REST, API v2, CalDAV ou récupération du mot de passe. Une nouvelle règle est créée avec tous les canaux cochés. L'installation crée deux règles prêtes à l'emploi, inactives : Utilisateur + IP (5 échecs en 15 minutes, blocage de 15 minutes) et IP (30 échecs en 15 minutes, blocage de 30 minutes).
• Exceptions : utilisateurs, groupes, profils, réseaux (CIDR) ou pays qui ne sont jamais bloqués, même si une règle se déclenche. Chaque exception peut avoir une période de validité avec date de début et de fin.
• GeoIP : avec une base MaxMind GeoLite2 Country importée depuis l'écran du module, celui-ci détermine le pays de chaque IP. Cela alimente le tableau de bord et permet des règles et des exceptions par pays.
• Tableau de bord : totaux des dernières 24 heures par résultat, une ligne des dernières 24 heures par canal, blocages, règles et exceptions actifs, et le top 10 des IP, utilisateurs (masqués) et pays cumulant le plus d'échecs et de tentatives refusées sur les 7 derniers jours.
• Blocages : la liste des blocages actifs avec un bouton de déblocage, la création de blocage manuel et l'historique complet.
• Événements : les tentatives évaluées et classées, dans la recherche native de GLPI, avec une colonne Canal et l'utilisateur toujours masqué. Les tentatives refusées pendant un blocage actif n'apparaissent que dans le compteur du blocage.
• Test : des simulateurs de résolution d'IP et de tentative de connexion qui n'enregistrent rien ; le simulateur de tentative permet de choisir le canal. Vous savez ce qui se passerait avant d'activer une règle.

Un détail qui fait la différence : le module classe le résultat réel de la tentative en examinant la réponse renvoyée par GLPI, et il compte la tentative dès qu'elle commence. Un robot qui envoie des dizaines de requêtes en parallèle ne peut pas dépasser la limite grâce à une course entre elles.

Activation sûre, étape par étape

Security Guard est livré désactivé : l'interrupteur de protection est coupé et les deux règles créées à l'installation sont inactives. Installer le module ne bloque personne. En revanche, protection désactivée, le module n'enregistre rien : impossible d'« observer avant de bloquer » avec l'interrupteur coupé. La voie sûre consiste à activer la protection avec les règles encore inactives et à utiliser l'onglet Test. L'ordre ci-dessous compte, car un mauvais réglage du proxy peut bloquer toute l'entreprise.

1. Installez et activez le module dans NexTool > Modules > Security Guard. La console se trouve dans NexTool > Security Guard.
2. Déclarez les proxys de confiance AVANT d'activer la protection. Dans l'onglet Paramètres, saisissez dans le champ Proxys de confiance (CIDR) le réseau du proxy inverse placé devant GLPI (Nginx, NPM, HAProxy, répartiteur de charge). Sans cela, le module ignore volontairement le header X-Forwarded-For (il peut être falsifié) et voit l'IP du proxy, pas celle de l'utilisateur.
3. Si GLPI est derrière Cloudflare, cliquez sur Ajouter les plages Cloudflare. Le bouton ajoute au champ les plages officielles du CDN, sans effacer ce qui s'y trouve et sans enregistrer tout seul. Conservez aussi le réseau de votre proxy local et enregistrez. Sans les plages Cloudflare, l'IP résolue serait celle de la bordure du CDN, partagée par des milliers de personnes.
4. Vérifiez le header d'IP. La valeur par défaut est X-Forwarded-For ; ne la changez que si votre proxy utilise X-Real-IP ou Forwarded.
5. Vérifiez la carte « IP de cette requête ». Elle affiche le REMOTE_ADDR, le header reçu et l'IP que le module résoudrait maintenant. L'IP résolue doit être celle de votre ordinateur, pas celle du proxy. Si l'alerte « Proxy probable non configuré » apparaît, arrêtez-vous et revenez à l'étape 2.
6. Activez la Protection contre la force brute avec les règles encore inactives. Sans règle active ni blocage manuel, personne n'est bloqué, et le Tableau de bord et l'onglet Événements commencent à afficher les tentatives classées. Utilisez l'onglet Test pour confirmer qu'une de vos tentatives normales ne serait pas bloquée.
7. Ensuite seulement, activez une règle de portée Utilisateur + IP dans l'onglet Règles, et vérifiez dans le champ Canaux où elle comptera. La règle prête à l'emploi prévoit 5 échecs en 15 minutes et un blocage de 15 minutes.

Bonnes pratiques

• Privilégiez la portée Utilisateur + IP. Elle arrête le robot qui s'acharne sur un compte depuis une adresse, sans effet de bord pour les autres utilisateurs.
• Prudence avec la portée Utilisateur seule. Elle permet à n'importe qui de bloquer le compte d'un collègue simplement en se trompant exprès de mot de passe. Si vous l'utilisez, prévoyez une limite haute et une durée courte.
• Prudence avec la portée IP seule derrière un NAT. Un bureau entier sort souvent par la même IP publique. Une règle par IP seule, avec une limite basse, pénalise tout le monde pour l'erreur d'un seul. Si vous l'utilisez, fixez une limite bien plus haute que celle de la règle Utilisateur + IP (la règle prête à l'emploi prévoit 30 échecs en 15 minutes).
• Créez les exceptions avec discernement. Le réseau du siège, un profil d'intégration ou un compte de supervision peuvent être exemptés, de préférence avec une période de validité.
• Prudence avec les intégrations par API. Un système intégré par l'API qui se trompe de mot de passe en boucle (un ancien mot de passe, par exemple) bloque sa propre IP. Déclarez son réseau en exception ou décochez ce canal dans la règle.
• Pour la récupération du mot de passe, fixez une limite plus haute que pour la connexion et privilégiez la portée IP ou Utilisateur + IP.
• Tenez la base GeoIP à jour. La mise à jour est manuelle ; la carte vous avertit quand la base a plus de 60 jours.

Confidentialité

Enregistrer les tentatives de connexion implique des données personnelles ; il vaut donc la peine de savoir exactement ce que le module conserve :

• Le nom d'utilisateur n'est jamais enregistré en clair. La corrélation utilise un HMAC-SHA256 avec une clé propre à l'installation, et l'écran n'affiche qu'un masque (première et dernière lettre). Pour les connexions réussies, l'événement conserve aussi l'ID de l'utilisateur dans GLPI.
• L'adresse e-mail saisie dans les demandes de nouveau mot de passe suit la même règle : elle n'est conservée que sous forme de HMAC, et l'écran n'affiche qu'un masque.
• L'IP et le pays sont enregistrés en clair, car ils sont l'objet même de la protection.
• Pour les événements, c'est vous qui fixez la durée de conservation : 90 jours par défaut, et 30 jours pour le journal d'administration. Le nettoyage est assuré par l'action automatique secguardmaintenance, toutes les 5 minutes, en mode externe : il dépend du cron de GLPI configuré sur le serveur.
• L'historique des blocages n'expire pas dans cette version et n'est supprimé que par l'action « Supprimer les données ».
• La désinstallation du module conserve les données ; leur suppression exige l'action explicite « Supprimer les données », soumise à un droit spécifique.

Droits par écran

Security Guard est une console réservée à l'administration. Les droits se trouvent dans Administration > Profils > onglet NexTool et varient selon l'écran :

• Tableau de bord : Voir le Tableau de bord ;
• Événements : Voir les Événements ;
• Blocages : Voir les Blocages, Lever les blocages et Créer un blocage manuel ;
• Règles : Voir les Règles et Gérer les Règles ;
• Exemptions : Voir les Exemptions et Gérer les Exemptions ;
• Paramètres et onglet Test : Configurer ;
• Journaux : Voir les journaux.

Une action exige toujours aussi le droit de voir l'écran : une personne qui a « Lever les blocages » sans « Voir les Blocages » ne débloque rien. Ainsi, l'équipe de premier niveau peut, par exemple, débloquer un utilisateur sans pouvoir toucher aux règles.

Limites de cette version

Soyons clairs : la version 0.2.0 couvre la connexion web, l'API REST, l'API v2 de GLPI 11, CalDAV et la récupération du mot de passe. Restent en dehors, ou couverts en partie :

• les connexions par SSO, SAML ou REMOTE_USER, qui ne passent pas par le mot de passe GLPI ;
• le code MFA/TOTP de GLPI 11 : les tentatives apparaissent dans les événements, mais le module ne limite pas le code, car GLPI 11 bloque déjà lui-même après plusieurs tentatives erronées.

Il n'y a pas non plus de notification de blocage : ni e-mail, ni alerte, ni webhook. Le suivi se fait dans la console, sur le Tableau de bord et dans les onglets Blocages et Événements.

Pour qui

Pour ceux qui publient GLPI sur internet à destination de techniciens externes, de clients ou de filiales ; pour les prestataires qui exploitent plusieurs GLPI et doivent démontrer le contrôle d'accès lors d'audits ; et pour ceux qui ont déjà vu, dans le journal du serveur web, des centaines de POST sur la connexion venant du même endroit.

Compatibilité

• Version : 0.2.0
• GLPI : 10 et 11 (le même artefact fonctionne sur les deux)
• Plugin : NexTool 6.22.0 ou supérieur
• Offre : Gratuit
• Langues : écrans en portugais (Brésil et Portugal), anglais (États-Unis et Royaume-Uni), espagnol (Espagne et Mexique), français, italien et allemand

Prochaine étape

Security Guard fait partie de NexTool, un écosystème de modules qui étend GLPI sans personnalisation de code. Consultez la page du module ou contactez l'équipe pour une démonstration.

Relu par l'équipe NexTool Solutions. Les captures d'écran proviennent d'un environnement GLPI réel avec le plugin NexTool ; les IP et les utilisateurs ont été remplacés par des plages de documentation et des masques.