Résoudre les problèmes courants liés au transfert Linux

Compatible avec :

Ce document vous aide à identifier et à résoudre les problèmes courants que vous pouvez rencontrer lorsque vous utilisez le forwarder Linux Google Security Operations.

Le redirecteur ne démarre pas

Le redirecteur ne parvient pas à démarrer et est dans une boucle de redémarrage continu avec les éléments suivants : 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 bon chemin d'accès au fichier de configuration et de le mapper sur un dossier externe.

2e cause possible: SELinux est activé

  1. Vérifiez le fichier de configuration en accédant au conteneur sans démarrer le forwarder, puis exécutez 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 place dans un shell à partir du conteneur.

  2. Exécutez la commande suivante :

    ls -lrt /opt.chronicle/external/

    Si vous recevez une erreur d'autorisation refusée, cela signifie que le transfert ne peut pas ouvrir le fichier de configuration et donc pas démarrer.

Pour résoudre ce problème, procédez comme suit :

  1. Vérifiez l'état de SELinux en exécutant la commande suivante :

      sestatus

  2. Si l'état de SELinux est activé dans la sortie, exécutez la commande suivante pour le désactiver :

      setenforce 0

Les journaux n'atteignent pas le locataire Google Security Operations

Cause possible 1 : Résolution DNS

Vérifiez si l'hôte ne parvient pas à résoudre les adresses ou à accéder à Google Security Operations 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 Security Operations et le forwarder 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 de la mémoire tampon

Vérifiez s'il s'agit d'un problème de taille de 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 :

  1. Activez la compression dans le fichier de configuration du forwarder.

  2. Augmentez la taille de la mémoire tampon en mettant à jour les paramètres max_memory_buffer_bytes et max_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 le disque.

Le redirecteur et l'hôte ne reçoivent pas les journaux

Si l'hôte et le forwarder 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 indique que l'hôte n'est pas sur ce port. Consultez votre administrateur réseau.

Si le résultat de la commande indique que l'hôte écoute sur un port et que le redirecteur ne reçoit toujours pas de journaux, procédez comme suit:

  1. Pour arrêter Docker, exécutez la commande suivante:

    ​​docker stop cfps

  2. 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 que vous souhaitez de dépannage.

  3. Redémarrez votre service externe et vérifiez si le problème est résolu. Si le problème persistez, [contactez l'assistance Google Security Operations.

Le transfert ne reçoit pas les journaux, mais l'hôte les reçoit

Si l'hôte reçoit des journaux, mais pas le redirecteur, cela indique que le le redirecteur n'écoute pas sur le port spécifié dans le fichier de configuration.

Pour résoudre ce problème, procédez comme suit :

  1. Ouvrez deux fenêtres de terminal sur votre système, une pour configurer le redirecteur et un pour envoyer un message de test à l'hôte.

    1. Dans le premier terminal (le redirecteur), démarrez Docker sans démarrer le à l'aide de 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

    2. Spécifiez le port sur lequel le forwarder doit écouter :

      nc -l PORT

      Remplacez PORT par l'ID du port que vous souhaitez de dépannage.

  2. 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 que vous souhaitez de dépannage.

  3. Réexécutez la commande docker. Spécifiez l'indicateur -p avec les ports sur lesquels le transpondeur 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 système de transfert en exécutant la commande suivante:

  sudo docker logs cfps

La requête contient un argument non valide

Le fichier journal du redirecteur 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 que seuls des types de journaux valides sont ajoutés. 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 la section Types de journaux compatibles et analyseurs par défaut.

Serveur introuvable

Le fichier journal du transfert 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 redirecteur 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 redirecteur contient une clé secrète incorrecte. plus de détails. Contactez l'assistance Google Security Operations pour résoudre ce problème.

Le jeton doit être de courte durée

Le fichier journal du transfert 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. Réglez l'heure sur l'hôte ou essayez d'utiliser NTP pour synchroniser les horloges.

Fichier ou répertoire inexistant

Le fichier journal du redirecteur 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 transfert est démarré avec un mappage de disque incorrect. Utilisez le chemin d'accès complet du 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 de l'ID client à partir du fichier de configuration

Le fichier journal du transfert 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 si le fichier de configuration n'est pas présentes 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 le bon docker run est exécutée et que le fichier de configuration existe à l'adresse lieu 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 obtenir 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 forwarder, exécutez la commande suivante pour le configurer pour qu'il redémarre automatiquement :

    sudo docker run --restart=always `IMAGE_NAME`

    IMAGE_NAME correspond au nom de l'image du forwarder.

  • 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

    En cas de problème avec Docker, l'équipe d'assistance Google SecOps peut demander la sortie de cette commande pour vous aider à résoudre le problème.