Résoudre les problèmes courants

Compatible avec :

Google SecOps SOAR

Ce document fournit un ensemble de conseils et de procédures pour vous aider à diagnostiquer et à résoudre les problèmes courants rencontrés lors du déploiement et de l'utilisation de l'agent distant Google Security Operations.

Problème de non-concordance des clés

Ce problème se produit lorsque les clés privées de Google Security Operations et de l'agent distant ne correspondent pas. Pour résoudre ce problème, assurez-vous que la clé des ressources de l'agent correspond à la clé du agent_db Siemplify.

Échec du connecteur distant

Si un connecteur distant échoue, procédez comme suit :

1. Vérifiez qu'une instance d'intégration est bien installée sur l'agent.
2. Vérifiez les journaux agentiques au niveau de l'erreur pour trouver d'éventuels échecs dans le processus de connexion.
3. Testez la même configuration de connecteur localement et vérifiez s'il y a des erreurs.

Échec de l'installation : OS hôte non compatible ou incompatibilités de fin de vie

Si les nouvelles installations ou les mises à niveau automatiques échouent en raison d'erreurs de suivi glibc et de blocages d'appels système, procédez comme suit :

1. Vérifiez que l'environnement hôte n'exécute pas un ancien système d'exploitation, qui pourrait ne pas disposer de hooks d'appel système modernes.
2. Réhébergez l'environnement de l'agent sur une distribution Linux d'entreprise avec la dernière version officielle.
3. Assurez-vous que l'hôte est une plate-forme compatible : Debian 12 (base officielle), RHEL 8.7 :

   Vérifiez /etc/os-release : exécutez la commande suivante et recherchez NAME= et VERSION_ID= :

   cat /etc/os-release

   • Pour Debian 12 : recherchez NAME="Debian GNU/Linux" et VERSION_ID="12".
   • Pour RHEL 8.7 : recherchez NAME="Red Hat Enterprise Linux" et VERSION_ID="8.7".

La configuration du conteneur extrait la couche opérationnelle précédente au lieu de la "dernière" compilation

Si l'exécution des commandes de configuration du conteneur extrait par inadvertance une couche opérationnelle précédente au lieu de la nouvelle version logicielle, exécutez les commandes suivantes pour extraire explicitement la dernière image :

• Pour Docker :

  docker pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

• Pour Podman :

  podman pull us-docker.pkg.dev/siem-ar-public/images/agent:latest

Pour vous assurer que le déploiement s'exécute sur la version logicielle la plus récente, extrayez toujours la dernière image avant d'exécuter la commande d'exécution de l'agent.

Échec du déploiement de l'agent Docker

Si le déploiement Docker échoue, procédez comme suit :

1. Supprimez le conteneur Docker :

   1. Exécutez la commande suivante pour lister les conteneurs en cours d'exécution :

      docker ps 

   2. Exécutez la commande suivante pour supprimer les conteneurs défaillants :

      docker rm -f container_id_or_name
2. Supprimez les images :

   1. Exécutez la commande suivante pour lister les images :

      docker images 

   2. Exécutez la commande suivante pour supprimer l'image :

      docker rmi image_id_or_name
3. Supprimez les volumes :

   1. Exécutez la commande suivante pour lister les volumes :

      docker volume ls

   2. Exécutez la commande suivante pour supprimer les volumes :

      docker volume rm volume_name
4. Redéployez l'agent. Pour en savoir plus, consultez Créer un agent à l'aide de Docker.

Agent bloqué à l'état "En attente de l'agent"

Si l'agent a bien été déployé, mais que l'état reste "En attente de l'agent", suivez ces étapes pour résoudre le problème :

1. Vérifier la connectivité de l'hôte : testez la connectivité Internet de la machine hôte de l'agent (par exemple, curl www.google.com ou ping 8.8.8.8). En cas d'échec, le problème est lié à la connexion Internet de l'hôte.

2. Vérifier la connectivité du conteneur : si le test de l'hôte réussit, entrez dans le shell du conteneur à l'aide de docker exec -it container_ID bash et vérifiez à nouveau la connectivité. Si le conteneur n'est pas connecté, redémarrez le service Docker sur la machine hôte (service docker restart).

   1. Exécutez la commande suivante :

      docker exec -it bash

   2. Vérifiez à nouveau la connectivité comme vous l'avez fait précédemment.
   3. Si vous n'avez pas de connectivité, exécutez la commande suivante pour redémarrer le service Docker à partir de la machine hôte (et non du conteneur) :

      service docker restart

   4. Exécutez la commande suivante pour redémarrer le conteneur :

      docker start

3. Rechercher les erreurs dans les journaux de conteneur

   Si l'étape précédente n'a pas résolu le problème et que l'état de l'agent est toujours "En attente de l'agent" après l'actualisation de la page Agent distant dans Google SecOps, reconnectez-vous au conteneur et récupérez les journaux.

   1. Recherchez les journaux dans le répertoire /var/log/SiemplifyAgent/.
   2. Recherchez d'éventuelles erreurs dans les fichiers journaux pour identifier la cause du problème.

Problèmes de réseau DNS

Si le conteneur rencontre des échecs de résolution DNS ou des problèmes de connectivité réseau, ajoutez --network host à la commande docker run. Le mode réseau hôte permet au conteneur de partager directement la pile réseau et la configuration DNS de la machine hôte.

Remarque : Le mode réseau hôte ne fonctionne qu'avec un seul agent par machine hôte.

Échec du chargement de l'image Docker (le transfert IP4 est désactivé)

Si une erreur s'affiche dans la CLI lorsque vous essayez de charger une image Docker (système) ou un agent Google SecOps, il est possible que le transfert IP4 soit désactivé. Pour l'activer et redémarrer votre agent, procédez comme suit :

1. Ajoutez la ligne suivante au fichier /etc/sysctl.conf :

   net.ipv4.ip_forward=1 Notez que vous devrez utiliser un éditeur de fichiers (comme nano, par exemple : yum install nano -y
   

2. Exécutez la commande suivante pour redémarrer le service réseau :

   systemctl restart network

3. Exécutez la commande suivante pour redémarrer le service Docker :

   sudo systemctl restart docker

4. Exécutez la commande suivante pour vérifier si le conteneur est en cours d'exécution :

   docker ps

5. Si le conteneur n'est pas en cours d'exécution, exécutez la commande suivante pour lister tous les conteneurs (y compris ceux qui sont arrêtés) :

   docker ps -a

6. Si le conteneur est listé, mais arrêté, exécutez la commande suivante pour le démarrer :

   docker start container_id_or_name
7. Si l'agent ou le système ne s'exécute toujours pas après le redémarrage de Docker et du conteneur :

   1. Exécutez la commande suivante pour arrêter le conteneur :

      docker stop container_id_or_name

   2. Exécutez la commande suivante pour supprimer le conteneur :

      docker rm container_id_or_name

   3. Exécutez la commande suivante pour supprimer l'image :

      docker rmi image_name
   4. Chargez à nouveau l'image.

Erreur après l'arrêt ou le redémarrage de l'agent

Exécutez la commande suivante pour forcer le démarrage de l'agent d'installation :
systemctl start supervisord

Exécutez la commande suivante pour forcer le démarrage de l'agent Docker :
docker start

Échec des tâches de l'agent distant sur les environnements renforcés

Lorsque vous déployez un agent distant sur un hôte Linux renforcé tel que RHEL 8, les tâches de l'agent (y compris l'enregistrement ou la mise à niveau d'une intégration, ou l'exécution de connecteurs et d'actions) peuvent échouer ou expirer dans l'interface utilisateur, tandis que l'état de l'agent reste Actif. Ce problème se produit lorsque l'application de la sécurité de l'OS hôte (par exemple, SELinux en mode Enforcing, AppArmor ou un logiciel de sécurité des points de terminaison) bloque les commandes de l'OS exécutées par l'agent dans le conteneur.

Pour résoudre ce problème, l'agent distant doit être exempté des règles d'application de la sécurité de l'hôte qui bloquent ses commandes d'OS. Pour diagnostiquer et résoudre le problème, procédez comme suit :

1. Vérifiez si SELinux est en mode Enforcing sur la machine hôte :

   getenforce
   sestatus
   

   Pour vérifier si /var/log/audit/audit.log contient des commandes récemment bloquées ou des opérations refusées sans renvoyer l'intégralité du fichier journal, exécutez la commande suivante :

   sudo grep -i "denied" /var/log/audit/audit.log | tail -n 50
   

   Vous pouvez également inspecter les journaux de sécurité de votre point de terminaison sur l'hôte pour détecter les opérations bloquées liées aux processus du conteneur de l'agent.

2. Excluez l'agent distant de la stratégie de sécurité de blocage sur l'hôte :

   • Pour les déploiements conteneurisés (Docker ou Podman), excluez l'intégralité du conteneur de l'agent distant lors de son premier démarrage en ajoutant --security-opt label=disable (pour SELinux) ou --security-opt apparmor=unconfined (pour AppArmor) à votre commande docker run ou podman run.
   • Configurez des règles de stratégie SELinux personnalisées, des profils AppArmor ou des exemptions de sécurité des points de terminaison de l'hôte pour les répertoires de l'agent distant (/opt/SiemplifyAgent, /home/siemplify_agent/agent_source et /var/log/SiemplifyAgent) et les exécutables (/usr/local/bin/python3.11, /usr/local/bin/pip3 et /usr/bin/supervisord) afin que les commandes de l'OS ne soient pas bloquées.

3. Si vous ne pouvez pas configurer d'exemption SELinux ciblée, définissez SELinux en mode Permissive de manière persistante lors des redémarrages en définissant SELINUX=permissive dans /etc/selinux/config sur l'hôte.

   S'il n'est pas possible de modifier /etc/selinux/config ou si vous devez appliquer la modification immédiatement sans redémarrer, exécutez la commande suivante pour passer temporairement SELinux en mode Permissive :

   sudo setenforce 0
   

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.