[General]

[homebrewtainy]

Your question

Hello / Good evening g-bougard,
Hello / Good evening everyone.

translated from Google Translate

I don't know if this is the right place to bring up this subject, but is there a guideline regarding securing GLPI-Agent connections?

This subject has apparently been the subject of a thread on the forum, but I don't think I have found an answer.

Situation :

• A GLPI is hosted “On Premise” and exposed, in HTTPS with a public authority SSL/TLS certificate (DigiCert… Sectigo… GlobalSign) by an Apache server, on the Internet.

• Anyone with an account can connect to it, from wherever they are (no public IP filtering, no VPN, etc.)...
  I am waiting for OTP – 2FA in the Core with great attention.

• The GLPI-Agent are deployed on the computers (desktop or laptop) of the different Entities (multi structures / multi sites) in service execution mode.

Need :
How to “secure” JSON (or XML) “injections” to Inventory front-ends, whatever they may be:

• native (/front/inventory.php)
• legacy (/plugins/glpiinventory/)
• marketplace (/marketplace/glpiinventory/)

It is easy to do (via the Apache VHOST) a “Location Deny” to the native inventory URL to be certain that only the GLPIInventory plugin will be accessed.

Afterwards, it is of course authentication by client certificate (coming from an internal CA this time) on Apache from the GLPI-Agent request which would be the privileged access control mechanism.

But if for the native inventory, a single front-end PHP file would need to be protected, for the GLPIInventory plugin it seems more delicate.

What are the entry points requested by a GLPI-Agent to which we could or should control access without preventing the operation of the entire WEB part of the plugin (/glpiinventory/front/*).

I don't know the question presented here is well structured, but overall... how GLPI Network Cloud instances are protected against possible illegitimate JSON injection?

Thanks in advance for a little enlightenment :-)

[homebrewtainy]

Sorry...

While browsing the discussion topics again, I just came across this one: #271

I will read it carefully.

However, I remain with my final question:

• How GLPI Cloud Network instances are protected and especially which entry points of the GLPIInventory plugin must be secured and which ones do not need it?

Sincerely

[g-bougard]

Hi @homebrewtainy

the question is clear enough.

First about frontends url, you have still pointed all the primary entry points. But you can add few ones which are specific to Collect, ESX & Deploy tasks. These entry points are used to retrieve the jobs to run after the agent is notified the server has such jobs for him. If you don't use these tasks, you can ignore them:

• for Collect task: /(plugins or marketplace)/glpiinventory/b/collect
• for ESX task: /(plugins or marketplace)/glpiinventory/b/esx
• for Deploy task: /(plugins or marketplace)/glpiinventory/b/deploy

So yes, the first method is to implement Basic authentication on all these pages. And this is the protection we can use for GLPI Cloud Network instances.

You can also secure these pages by configuring SSL client certificate authentication. On the agent-side, you will have to deploy the certificate in a file and configure agent to use ssl-cert-file option with the path to this certificate file.

[homebrewtainy]

Hi @g-bougard,

Thank you for this exchange.
It's always a pleasure !

After having parsed the content of the GIPIInventory plugin, should we also control access (ideally by CA_cert client authent) to this file:
/front/communication.php

It seems to be the fallback for the basic inventory within the plugin as well as for compatibility with Fusion?
I'm go(ing) off course?

[g-bougard]

You're right, /front/communication.php is indeed used and included from plugin index page when an agent submits an inventory to the plugin index page. If you prefer, you can configure agent to use this front in url, but this may make troubles when using collect, ESX or Deploy tasks. This is why this kind of URL is not recommended. That trouble may be fixed using the "Agent Base URL" configuration in GLPI entities administration, available in the "Assets" tab of an entity. Just using the plugin base url is just more friendly ;-)

So you can simply reject requests to that frontend to not trusted client and be sure to configure your agent with the plugin base url. By default, the agent won't try to access this frontend unless you tell it to do.

[homebrewtainy]

Thank you very much @g-bougard

I'll try to set this all straight.

As much as securing the /front/inventory.php for the native inventory alone seems affordable to me either by Basic Authentication or by SSL Client Cert Authentication.

However, securing the plugin requires more careful brainstorming!

Especially since the deployed GLPI is behind an Apache reverse-poxy.

A little work to do :-)