Résoudre les problèmes courants liés au transmetteur Linux
Ce document vous aide à identifier et à résoudre les problèmes courants que vous pouvez rencontrer lors de l'utilisation du redirecteur Linux Google Security Operations.
Le transitaire ne démarre pas
Le transmetteur ne parvient pas à démarrer et se trouve dans une boucle de redémarrage continu avec l'erreur suivante dans les journaux :
F0510 06:17:39.013603 202 main_linux.go:153] open /opt/chronicle/external/*.conf: no such file or directory
Cause possible 1 : Mappage incorrect dans le fichier de configuration
Pour résoudre ce problème, assurez-vous de transmettre le chemin d'accès correct au fichier de configuration et de le mapper à un dossier externe.
Cause possible 2 : SELinux est activé
Vérifiez le fichier de configuration en accédant au conteneur sans démarrer le transmetteur et en exécutant la commande suivante :
docker run --name cfps --log-opt max-size=100m --log-opt max-file=10 --net=host -v ~/configuration:/opt/chronicle/external --entrypoint=/bin/bash \ -it gcr.io/chronicle-container/cf_production_
Cette commande vous permettra d'accéder à un shell depuis le conteneur.
Exécutez la commande suivante :
ls -lrt /opt.chronicle/external/
Si vous recevez une erreur d'autorisation refusée, cela signifie que le transmetteur ne peut pas ouvrir le fichier de configuration et, par conséquent, ne peut pas démarrer.
Pour résoudre ce problème, procédez comme suit :
Vérifiez l'état de SELinux en exécutant la commande suivante :
sestatus
Si l'état SELinux est activé dans le résultat, exécutez la commande suivante pour le désactiver :
setenforce 0
Journaux n'atteignant pas le locataire Google SecOps
Cause possible 1 : Résolution DNS
Vérifiez si l'hôte ne parvient pas à résoudre les adresses ni à contacter Google SecOps en exécutant la commande suivante :
nslookup malachiteingestion-pa.googleapis.com
Si la commande échoue, contactez votre équipe réseau pour résoudre le problème.
Cause possible 2 : Pare-feu
Vérifiez si le pare-feu local bloque la communication entre Google SecOps et le redirecteur en exécutant la commande suivante :
firewall-cmd --state
Si le pare-feu est activé, désactivez-le en exécutant la commande suivante :
systemctl stop firewalld
Cause possible 3 : Taille du tampon
Vérifiez s'il s'agit d'un problème de taille de mémoire tampon en recherchant l'erreur suivante dans les journaux :
Memory ceiling (1073741824) reached, freeing a batch from the backlog
Pour résoudre ce problème, procédez comme suit :
Activez la compression dans le fichier de configuration du transmetteur.
Augmentez la taille du tampon en modifiant les paramètres
max_memory_buffer_bytes
etmax_file_buffer_bytes
dans le fichier de configuration. Ces paramètres indiquent le tampon des lots en attente stockés dans la mémoire ou sur le disque.
Le transitaire et l'hôte ne reçoivent pas les journaux
Si l'hôte et le redirecteur ne reçoivent pas de journaux, vérifiez l'état du port en exécutant la commande suivante pour chaque port :
netstat -a | grep PORT
Remplacez PORT
par l'ID du port que vous souhaitez vérifier.
Si la commande ne donne aucun résultat, cela signifie que l'hôte n'écoute pas sur ce port. Vous devez alors consulter votre administrateur réseau.
Si le résultat de la commande indique que l'hôte écoute sur un port et que le transmetteur ne reçoit toujours pas de journaux, procédez comme suit :
Arrêtez Docker en exécutant la commande suivante :
docker stop cfps
Exécutez l'une des commandes suivantes en fonction de la configuration de votre réseau.
Pour TCP :
nc -l PORT
Pour UDP :
nc -l -u PORT
Remplacez
PORT
par l'ID du port pour lequel vous souhaitez résoudre les problèmes.Redémarrez votre service externe et vérifiez si le problème est résolu. Si le problème persiste, [contactez l'assistance Google SecOps.
Le redirecteur ne reçoit pas les journaux, mais l'hôte les reçoit
Si l'hôte reçoit des journaux, mais pas le transmetteur, cela indique que le transmetteur n'écoute pas le port spécifié dans le fichier de configuration.
Pour résoudre ce problème, procédez comme suit :
Ouvrez deux fenêtres de terminal sur votre système : une pour configurer le redirecteur et une pour envoyer un message de test à l'hôte.
Dans le premier terminal (transmetteur), démarrez Docker sans démarrer le transmetteur en exécutant la commande suivante :
docker run \ --name cfps \ --log-opt max-size=100m \ --log-opt max-file=10 \ --net=host \ -v ~/config:/opt/chronicle/external \ --entrypoint=/bin/bash \ -it gcr.io/chronicle-container/cf_production_stable
Spécifiez le port sur lequel le redirecteur doit écouter :
nc -l PORT
Remplacez
PORT
par l'ID du port pour lequel vous souhaitez résoudre les problèmes.
Sur le deuxième terminal (hôte), envoyez le message de test sur le port en exécutant la commande suivante :
echo "test message" | nc localhost PORT
Remplacez
PORT
par l'ID du port pour lequel vous souhaitez résoudre les problèmes.Exécutez à nouveau la commande
docker
. Spécifiez l'indicateur-p
avec les ports sur lesquels le redirecteur doit écouter en exécutant la commande suivante :docker run \ --detach \ –name cfps \ --restart=always \ --log-opt max-size=100m \ --log-opt max-file=10 --net=host \ —v /root/config:/opt/chronicle/external \ -p 11500:11800 \ gcr.io/chronicle-container/cf_production_stable
Erreurs courantes dans le fichier journal du redirecteur
Vous pouvez afficher les journaux du redirecteur en exécutant la commande suivante :
sudo docker logs cfps
La requête contient un argument non valide
Le fichier journal du transitaire affiche le message d'erreur suivant :
I0912 18:04:15.187321 333 uploader.go:181] Sent batch error: rpc error: code = InvalidArgument desc = Request contains an invalid argument.
E0912 18:04:15.410572 333 batcher.go:345] [2_syslog_CISCO_FIREWALL-tid-0] Error exporting batch: rpc error: code = InvalidArgument desc = Request contains an invalid argument.
I0912 18:04:15.964923 333 uploader.go:181] Sent batch error: rpc error: code = InvalidArgument desc = Request contains an invalid argument.
Solution :
Cette erreur peut se produire lorsqu'un type de journal non valide est ajouté. Assurez-vous d'ajouter uniquement des types de journaux valides. Dans l'exemple de message d'erreur, CISCO\_FIREWALL
n'est pas un type de journal valide. Pour obtenir la liste des types de journaux valides, consultez Types de journaux et analyseurs par défaut acceptés.
Impossible de trouver le serveur
Le fichier journal du transitaire affiche le message d'erreur suivant :
{"log":"Failure: Unable to find the server at accounts.google.com.\n","stream":"stderr","time":"2019-06-12T18:26:53.858804303Z"}`
{"log":"+ [[ 1 -ne 0 ]]\n","stream":"stderr","time":"2019-06-12T18:26:53.919837669Z"}
{"log":"+ err 'ERROR: Problem accessing the Chronicle bundle.'\n","stream":"stderr","time":"2019-06-12T18:26:53.919877852Z"}
Solution :
Contactez votre équipe réseau pour vous assurer que le réseau fonctionne.
Signature JWT non valide
Le fichier journal du transitaire affiche le message d'erreur suivant :
E0330 17:05:28.728021 162 stats_manager.go:85] send(): rpc error: code = Unauthenticated desc = transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
E0404 17:05:28.729012 474 memory.go:483] [1_syslog_FORTINET_FIREWAL-tid-0] Error exporting batch: rpc error: code = Unauthenticated desc = transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
Solution :
Cette erreur peut se produire lorsqu'un fichier de configuration du transmetteur contient des informations incorrectes sur la clé secrète. Contactez l'assistance Google SecOps pour résoudre ce problème.
Le jeton doit être un jeton de courte durée
Le fichier journal du transitaire affiche le message d'erreur suivant :
token: 400 Bad Request Response:
{"error":"invalid_grant","error_description":"Invalid JWT: Token must be a
short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim."} I0412 05:14:16.539060 480
malachite.go:212] Sent batch error: rpc error: code = Unauthenticated desc =
transport: OAuth 2.0: cannot fetch token: 400 Bad Request Response:
{"error":"invalid_grant","error_description":"Invalid JWT: Token must be a
short-lived token (60 minutes)
Solution :
Cette erreur peut se produire lorsque les horloges système de l'hôte et du serveur ne sont pas synchronisées. Ajustez l'heure sur l'hôte ou essayez d'utiliser NTP pour synchroniser les horloges.
Fichier ou répertoire inexistant
Le fichier journal du transitaire affiche le message d'erreur suivant :
++ cat '/opt/chronicle/external/*.conf'
cat: '/opt/chronicle/external/*.conf': No such file or directory
Solution :
Cette erreur peut se produire lorsque le redirecteur est démarré avec un mappage de lecteur incorrect. Utilisez le chemin d'accès complet au répertoire dans le fichier de configuration (vous pouvez obtenir le chemin d'accès en exécutant la commande pwd
).
Échec de la récupération du numéro client à partir du fichier de configuration
Le fichier journal du transitaire affiche le message d'erreur suivant :
+ err 'ERROR: Failed to retrieve customer ID from configuration file.'
++ date +%Y-%m-%dT%H:%M:%S%z
+ echo '[2023-06-28T09:53:21+0000]: ERROR: Failed to retrieve customer ID from configuration file.'
[2023-06-28T09:53:21+0000]: ERROR: Failed to retrieve customer ID from configuration file.
+ err '==> Please contact the Chronicle support team.'
Solution :
Cette erreur est due à un mappage incorrect ou à l'absence du fichier de configuration dans le répertoire. Utilisez le chemin d'accès complet au répertoire dans le fichier de configuration (vous pouvez obtenir le chemin d'accès en exécutant la commande pwd
). Assurez-vous que la commande docker run
correcte est exécutée et que le fichier de configuration existe à l'emplacement suivant :
gcr.io/chronicle-container/cf_production_stable
L'exemple de code suivant montre la commande docker run
:
docker run \
--detach \
--name cfps \
--restart=always \
--log-opt max-size=100m \
--log-opt max-file=10 \
--net=host \
-v /opt/chronicle/config:/opt/chronicle/external \
gcr.io/chronicle-container/cf_production_stable
Commandes Docker utiles
Vous pouvez collecter des informations supplémentaires sur l'installation de Docker à l'aide de la commande suivante :
docker info
Le service Docker peut être désactivé par défaut. Pour vérifier s'il est désactivé, exécutez la commande suivante :
systemctl is-enabled docker
Pour activer le service Docker et le démarrer immédiatement, exécutez l'une des commandes suivantes :
sudo systemctl enable --now docker
sudo systemctl enable /usr/lib/systemd/system/docker.service
Sortie :
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service
Lorsque vous démarrez un transmetteur, exécutez la commande suivante pour le configurer afin qu'il redémarre automatiquement :
sudo docker run --restart=always `IMAGE_NAME`
IMAGE_NAME
correspond au nom de l'image du redirecteur.Pour vérifier l'état et les détails du service Docker, exécutez la commande suivante :
sudo systemctl status docker
Sortie :
● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago TriggeredBy: ● docker.socket Docs: https://docs.docker.com Main PID: 263 (dockerd) Tasks: 20 Memory: 100.4M CGroup: /system.slice/docker.service └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock" Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine
Si vous rencontrez des problèmes avec Docker, l'équipe d'assistance Google SecOps peut vous demander le résultat de cette commande pour vous aider à résoudre le problème.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.