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

Compatible avec :

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é

  1. 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.

  2. 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 :

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

      sestatus
    
  2. 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 :

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

  2. Augmentez la taille du tampon en modifiant 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 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 :

  1. Arrêtez Docker en exécutant 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 pour lequel vous souhaitez résoudre les problèmes.

  3. 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 :

  1. 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.

    1. 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
      
    2. 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.

  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 pour lequel vous souhaitez résoudre les problèmes.

  3. 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.