Securing exchanges between GLPI agents <-> GLPI server
To secure exchanges between your agents and the GLPI server, several tips and methods are available:
Man in the Middle / Spoofing DNS
This method consists in intercepting requests and pretending to be the legitimate GLPI server.
To avoid this, use an SSL server and ensure that the agent authenticates the server with its certificate.
If the server's certificate is signed by a public certification authority, just configure the agent with an https url.
If the server's certificate is private, you need to provide the agent with the certificate via the ca-cert-file option (it can also be found in the windows keystore or MacOSX keychain) or a fingerprint of the certificate via the ssl-fingerprint option and, above all, never activate the no-ssl-check option. This last option should only be used to debug SSL communication problems, or only once, so that the agent displays the server's ssl certificate fingerprint in its log to indicate how to configure the ssl-fingerprint option.
Password authentication
It is also possible to add password authentication. In this case, you need to configure the agent's username and password options. The only problem in this case is that a compromised machine could reveal the user and password to an attacker, who could then inject bogus inventory or data into GLPI.
SSL certificate authentication
There's also the possibility of defining authentication by client ssl certificate, but this solution has never been properly tested, and above all it's complex to implement because it requires very advanced Apache configuration. On the agent side, it's the ssl-cert-file option that supports this possibility. But this doesn't change the problem of compromising the workstation that could reveal the client certificate.
Bi-directional authentication is therefore currently possible using the technologies mentioned above.
Going further
Future versions will include the idea of registering agents with a password or token dedicated to this phase, and enabling the agent and server to negotiate an exchange of private keys in order to authenticate and encrypt exchanges, including in an http flow and possibly even through a proxy agent. The JSON protocol of the native inventory has been designed to remain open to this kind of functionality. This functionality would enable direct bi-directional authentication and the possibility of managing an expiry, renewal or revocation policy for tokens and keys to help counter the attacks you mention. Unfortunately, this kind of functionality, to be developed in the agent and in GLPI, is currently seeking funding. Please don't hesitate to contact us. Nevertheless, there should be new authentication possibilities for the agent in the not too distant future.
Regarding the detailed flows between agent and server: the agent remains an HTTP/HTTPS client, depending on the type of url configured. The agent can also be an http server, including for the GLPI server to force execution of tasks from GLPI, and here the default TCP port 62354 needs to be opened from the GLPI server to the agent.
References
Last updated
Was this helpful?