Sécuriser les échanges entre agents GLPI <-> serveur GLPI
Pour sécuriser les échanges entre vos agents et le serveur GLPI, plusieurs conseils et méthodes sont disponibles :
Man in the Middle / Spoofing DNS
Cette méthode consiste à intercepter les requêtes et à se faire passer pour le serveur GLPI légitime.
Pour éviter cela, utilisez un serveur SSL et assurez-vous que l'agent authentifie le serveur avec son certificat.
Si le certificat du serveur est signé par une autorité de certification publique, configurez simplement l'agent avec une url https.
Si le certificat du serveur est privé, vous devez fournir l'agent avec le certificat via l'option ca-cert-file (il peut aussi se trouver dans le keystore windows ou le trousseau MacOSX) ou une empreinte du certificat via l'option ssl-fingerprint et, surtout, ne jamais activer l'option no-ssl-check. Cette dernière option ne doit être utilisée que pour déboguer les problèmes de communication SSL, ou seulement une fois, afin que l'agent affiche l'empreinte du certificat ssl du serveur dans son log pour indiquer comment configurer l'option ssl-fingerprint.
Authentification par mot de passe
Il est aussi possible d'ajouter une authentification par mot de passe. Dans ce cas, vous devez configurer les options username et password de l'agent. Le seul problème dans ce cas est qu'une machine compromise pourrait révéler l'utilisateur et le mot de passe à un attaquant, qui pourrait alors injecter un inventaire ou des données bidon dans GLPI.
Authentification par certificat SSL
Il y a aussi la possibilité de définir une authentification par certificat ssl client, mais cette solution n'a jamais été correctement testée, et surtout elle est complexe à mettre en œuvre car elle nécessite une configuration Apache très avancée. Côté agent, c'est l'option ssl-cert-file qui supporte cette possibilité. Mais cela ne change pas le problème de compromission du poste de travail qui pourrait révéler le certificat client.
L'authentification bi-directionnelle est donc actuellement possible en utilisant les technologies mentionnées ci-dessus.
Aller plus loin
Les versions futures incluront l'idée d'enregistrer les agents avec un mot de passe ou token dédié à cette phase, et permettre à l'agent et au serveur de négocier un échange de clés privées afin d'authentifier et chiffrer les échanges, y compris dans un flux http et éventuellement même à travers un proxy agent. Le protocole JSON de l'inventaire natif a été conçu pour rester ouvert à ce genre de fonctionnalité. Cette fonctionnalité permettrait une authentification bi-directionnelle directe et la possibilité de gérer une politique d'expiration, de renouvellement ou de révocation pour les tokens et clés afin d'aider à contrer les attaques que vous mentionnez. Malheureusement, ce genre de fonctionnalité, à développer dans l'agent et dans GLPI, cherche actuellement des financements. N'hésitez pas à nous contacter. Néanmoins, il devrait y avoir de nouvelles possibilités d'authentification pour l'agent dans un avenir pas trop lointain.
Concernant les flux détaillés entre agent et serveur : l'agent reste un client HTTP/HTTPS, selon le type d'url configurée. L'agent peut aussi être un serveur http, y compris pour que le serveur GLPI force l'exécution de tâches depuis GLPI, et ici le port TCP par défaut 62354 doit être ouvert depuis le serveur GLPI vers l'agent.
Références
Last updated
Was this helpful?