Wazuh-ansible: l'enregistrement de l'agent wazuh ne doit pas déléguer_à localhost
Le contexte
Lorsque l'agent s'enregistre, l'API appelle pour obtenir des informations à son sujet. delete_to: localhost .
Problème
Lorsque le gestionnaire wazuh se trouve derrière un pare-feu qui n'autorise pas l'accès du contrôleur ansible au port API 55000, l'appel expirera et l'enregistrement échouera.
singuliere
Tous les 4 commentaires
Il semble que cette délégation ait été ajoutée ici :
https://github.com/wazuh/wazuh-ansible/commit/6cb6d3bda84c65508881e293e3403dae94ff24cc#diff -f382f2db5d2e651b16fc4b92ec32e988R90
La tâche Linux | Create the agent key via rest-API faisait auparavant la même chose. Cela a également été modifié depuis. Je pense que c'était juste raté.
paulcalabro
le 8 janv. 2019
Salut @singuliere et @paulcalabro Je suis le seul responsable de ce code. :)
Si vous continuez et supprimez cette ligne, vous supposez que le client que vous essayez d'enregistrer est capable d'atteindre le wazuh-api.
À mon humble avis, du point de vue de la sécurité, il est préférable de permettre au contrôleur ansible d'atteindre le wazuh-api plutôt que de laisser chaque client se connecter à l'api. L'API doit être protégée et isolée des hôtes gérés car elle peut être utilisée pour des opérations malveillantes.
Par exemple. dans mon entreprise, nos clients wazuh ne peuvent pas accéder à l'API car le gestionnaire s'exécute sur un réseau protégé derrière un pare-feu ; dans ce cas, votre logique d'enregistrement ne fonctionnera pas pour notre scénario.
Ce que nous pouvons faire, c'est laisser l'utilisateur choisir le type de logique d'enregistrement souhaité (ansible-manager -> wazuh-API ou wazuh-client -> wazuh-API).
Laissez-moi réfléchir à une solution appropriée... :thinking:
angystardust
le 8 janv. 2019
C'est un bon argument pour le garder. Je pense que je m'attendais à ce que l'enregistrement se produise de la part de l'agent en raison du fonctionnement de l'enregistrement authd. Mais, votre approche est plus sûre. Si cela pouvait être configuré pour répondre aux contraintes de mise en réseau, ce serait l'idéal.
paulcalabro
le 8 janv. 2019
@angystardust merci pour l'explication, c'est parfaitement logique. Il est actuellement incohérent (car 689bb8ff35b38fa8258f82db219a4d2565dc5239 a supprimé un délégué_to et pas l'autre) et j'ai supposé à tort que la bonne solution était celle correspondant à mon propre cas d'utilisation.
Étant donné que @paulcalabro semble être d'accord avec l'idée de le rendre configurable, je modifierai la demande d'extraction en conséquence.
singuliere
le 9 janv. 2019
Questions connexes
singuliere
·
13Commentaires
SitoRBJ
·
4Commentaires
dragospe
·
3Commentaires
paulcalabro
·
5Commentaires
NiftyMist
·
5Commentaires
Commentaire le plus utile
Salut @singuliere et @paulcalabro Je suis le seul responsable de ce code. :)
Si vous continuez et supprimez cette ligne, vous supposez que le client que vous essayez d'enregistrer est capable d'atteindre le wazuh-api.
À mon humble avis, du point de vue de la sécurité, il est préférable de permettre au contrôleur ansible d'atteindre le wazuh-api plutôt que de laisser chaque client se connecter à l'api. L'API doit être protégée et isolée des hôtes gérés car elle peut être utilisée pour des opérations malveillantes.
Par exemple. dans mon entreprise, nos clients wazuh ne peuvent pas accéder à l'API car le gestionnaire s'exécute sur un réseau protégé derrière un pare-feu ; dans ce cas, votre logique d'enregistrement ne fonctionnera pas pour notre scénario.
Ce que nous pouvons faire, c'est laisser l'utilisateur choisir le type de logique d'enregistrement souhaité (ansible-manager -> wazuh-API ou wazuh-client -> wazuh-API).
Laissez-moi réfléchir à une solution appropriée... :thinking: