Sécuriser les échanges Agents GLPI <-> Serveur GLPI#
Afin de sécuriser les échanges entre vos agents et le serveur GLPI, plusieurs conseiles et méthodes sont possibles:
Man in the Middle / Spoofing DNS#
Cette attque consisterait à intercepter les requêtes envoyées et se faire passer pour le serveur GLPI légitime.
Pour éviter cela, il faut utiliser un serveur SSL et s'assurer que l'agent authentifie le serveur avec son certificat.
- Si le certificat du serveur est signé par une autorité de certification publique, il faut juste configurer l'agent avec une url en https.
- Si le certificat du serveur est privé, il faut fournir le certificat à l'agent via l'option ca-cert-file (il peut aussi être découvert dans le keystore de windows ou la keychain de 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 devrait servir qu'à déboguer les problèmes de communication SSL ou alors être utilisée une seule fois pour que l'agent affiche dans son journal l'empreinte du certificat ssl du serveur 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. Et dans ce cas, il faut configurer les options username et password de l'agent. Le seul problème dans ce cas, c'est qu'une machine compromise peut révéler l'utilisateur et le mot de passe à un attaquant et il pourrait alors injecter dans GLPI des inventaires ou des données bidon.
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é testée comme il faut et surtout elle est complexe à mettre en oeuvre car requiert une configuration Apache très avancée. Côté agent, c'est l'option ssl-cert-file qui porte cette possibilité. Mais cela ne change rien au problème de compromission du poste qui pourrait révéler le certificat client.
L'authentification bi-directionnelle est donc actuellement possible en faisant appel aux technologies évoquées.
Pour aller plus loin#
Les futures versions ameneront l'idée de permettre un enregistrement des 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 agent proxy. Le protocole JSON de l'inventaire natif a d'ailleurs é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 des tokens et des clés pour aider à contrer les attaques que tu évoques. Malheureusement, actuellement, ce genre de fonctionnalité, à developper dans l'agent et dans GLPI, est en recherche de financement. N'hésitez pas à nous contacter. Il devrait malgré tout y avoir de nouvelles possibilités d'authentification de l'agent dans un avenir pas trop lointain.
Concernant le détail des flux entre l'agent et le serveur: l'agent reste un client HTTP/HTTPS suivant le type d'url configurée. L'agent peut aussi être un serveur http, y compris pour le serveur GLPI pour pouvoir forcer l'exécution des tâches depuis GLPI et là, le port TCP par défaut 62354 a besoin d'être ouvert du serveur GLPI vers l'agent.