Outil de transfert Chronicle pour Linux

Ce document explique comment installer et configurer le redirecteur sous Linux. Pour installer le redirecteur sous Windows, consultez la page Outil de transfert Windows.

Le redirecteur permet d'envoyer les journaux de l'environnement client à l'instance Chronicle. Elle est utilisée lorsque les clients souhaitent envoyer les journaux directement à Chronicle et ne souhaitent pas utiliser les buckets cloud pour ingérer les données, ou lorsque le type de journal ne dispose pas d'une ingestion native via une API tierce. Le redirecteur peut être utilisé comme solution prête à être déployée au lieu d'incorporer manuellement l'API d'ingestion.

Vous pouvez installer le redirecteur sur diverses distributions Linux, y compris Debian, Ubuntu, Red Hat et Suse. Google Cloud fournit le logiciel à l'aide d'un conteneur Docker. Vous pouvez exécuter et gérer le conteneur Docker sur une machine physique ou virtuelle exécutant Linux.

Configuration requise

Vous trouverez ci-dessous des recommandations générales. Pour obtenir des recommandations spécifiques à votre système, contactez l'assistance Chronicle.

  • RAM : 1 Go pour chaque type de données collectées (collecteur) accepté par Chronicle pour l'ingestion. Par exemple, si vous avez spécifié quatre collecteurs différents, vous avez besoin de 4 Go de RAM pour collecter les données de ces quatre collecteurs.

  • Processeur : 2 processeurs suffisent pour gérer moins de 10 000 événements par seconde (EPS) (au total pour tous les types de données). Si vous prévoyez de transférer plus de 10 000 EPS, provisionnez 4 à 6 processeurs.

  • Disque : 100 Mo d'espace disque suffisent, quelle que soit la quantité de données traitées par le redirecteur Chronicle. Si vous devez mettre en mémoire tampon les messages en attente sur le disque plutôt que sur la mémoire, consultez la section Mise en mémoire tampon du disque. Par défaut, le redirecteur Chronicle effectue la mise en mémoire tampon dans la mémoire.

Plages d'adresses IP utilisées par Google

Vous aurez peut-être besoin que la plage d'adresses IP s'ouvre lors de la configuration d'un système de transfert, par exemple lors de la configuration de votre pare-feu. Google ne peut pas fournir une liste spécifique d'adresses IP. Toutefois, vous pouvez obtenir des plages d'adresses IP Google.

Vérifier la configuration du pare-feu

Tous les pare-feu ou proxys authentifiés situés entre le conteneur de redirecteur Chronicle et Internet nécessitent des règles pour ouvrir l'accès aux hôtes suivants:

Type de connexion Destination Port
TCP malachiteingestion-pa.googleapis.com 443
TCP asia-northeast1-malachiteingestion-pa.googleapis.com 443
TCP asia-south1-malachiteingestion-pa.googleapis.com 443
TCP asia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP australia-southeast1-malachiteingestion-pa.googleapis.com 443
TCP europe-malachiteingestion-pa.googleapis.com 443
TCP europe-west2-malachiteingestion-pa.googleapis.com 443
TCP europe-west3-malachiteingestion-pa.googleapis.com 443
TCP europe-west6-malachiteingestion-pa.googleapis.com 443
TCP me-central2-malachiteingestion-pa.googleapis.com 443
TCP me-west1-malachiteingestion-pa.googleapis.com 443
TCP northamerica-northeast2-malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Personnaliser les fichiers de configuration

Google Cloud adapte les fichiers de configuration à l'instance de redirecteur avec des métadonnées spécifiques, comme indiqué dans la section de sortie. Vous pouvez télécharger le fichier de configuration selon vos besoins et inclure des informations sur les types de journaux à ingérer dans la section des collecteurs. Pour en savoir plus sur les paramètres de configuration, consultez la documentation de référence sur les paramètres de configuration.

Configurer le redirecteur Linux

Pour configurer le redirecteur Linux via l'interface utilisateur, consultez Gérer les configurations de redirecteur via l'interface utilisateur Chronicle.

Pour configurer manuellement le redirecteur Linux, procédez comme suit:

  1. Créez une copie du modèle de fichier de configuration fourni avec le logiciel.

  2. Téléchargez le fichier de configuration via l'interface utilisateur.

  3. Enregistrez les deux fichiers dans le même répertoire en respectant la convention d'attribution de noms suivante:

    FORWARDER_NAME.conf : utilisez ce fichier pour définir les paramètres de configuration liés à l'ingestion de journaux.

    FORWARDER_NAME_auth.conf : utilisez ce fichier pour définir les identifiants d'autorisation.

  4. Modifiez les fichiers pour inclure la configuration de votre instance de redirecteur. Utilisez les exemples fournis dans ce document comme référence.

  5. Assurez-vous qu'une entrée existe pour chaque entrée du fichier FORWARDER_NAME_auth.conf, même si l'entrée ne contient pas d'informations d'authentification correspondantes. Cela est nécessaire pour mapper correctement les données.

Toute modification apportée au fichier de configuration est automatiquement appliquée par le redirecteur dans un délai de 5 minutes.

Exemple de configuration

L'exemple de code suivant montre le format des fichiers de configuration d'un redirecteur. Pour en savoir plus sur les paramètres de chaque type de mécanisme d'ingestion, tel que Splunk ou Syslog, consultez la page Collecter des données.

Fichier FORWARDER_NAME.conf

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: COLLECTOR_ID \
    customer_id: CUSTOMER_ID \

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DNS"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      tcp_buffer_size: 524288

Fichier FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\\"PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/example-account-1%40example-account.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
  - syslog:
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"

Ce système de deux fichiers vous permet de stocker les identifiants d'authentification dans un fichier distinct pour une sécurité renforcée. Vous pouvez stocker le fichier FORWARDER_NAME.conf dans un dépôt de contrôle des versions ou dans tout système de gestion de configuration ouvert. Vous pouvez stocker le fichier FORWARDER_NAME_auth.conf directement dans la machine physique ou virtuelle exécutant le redirecteur.

Exemple de configuration (fichier unique)

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: "COLLECTOR_ID" \
    customer_id: "CUSTOMER_ID" \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DNS"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288

Si vous utilisez le fichier de configuration unique et souhaitez passer aux deux systèmes de fichiers, procédez comme suit:

  1. Créez une copie de votre configuration existante.
  2. Enregistrez un fichier sous le nom FORWARDER_NAME.conf et supprimez les identifiants d'autorisation du fichier.
  3. Enregistrez l'autre fichier sous le nom FORWARDER_NAME_auth.conf et supprimez toutes les données ne nécessitant pas d'autorisation. Utilisez les exemples de fichiers de configuration fournis dans ce guide comme référence.
  4. Veillez à respecter la convention d'attribution de noms et les autres consignes mentionnées dans la section Personnaliser les fichiers de configuration.

Installer Docker

L'installation de Docker dépend de l'environnement hôte. Vous pouvez installer Docker sur différents systèmes d'exploitation hôtes. Google Cloud fournit une documentation limitée pour vous aider à installer Docker sur plusieurs des distributions Linux les plus courantes. Cependant, Docker est Open Source et toute la documentation nécessaire est déjà disponible. Pour obtenir des instructions sur l'installation de Docker, consultez la documentation de Docker.

Une fois Docker installé sur votre système, le processus d'installation du redirecteur Chronicle est semblable à celui de n'importe quel type de distribution Linux.

Pour vérifier si Docker est correctement installé sur votre système, exécutez la commande suivante (droits élevés):

   docker ps

La réponse suivante indique que Docker a été installé correctement:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Commandes Docker utiles

  • Vous pouvez recueillir 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

    Résultat :

    Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service

  • Lorsque vous démarrez un redirecteur, exécutez la commande suivante pour qu'il se redémarre automatiquement:

    sudo docker run --restart=always `IMAGE_NAME`

    IMAGE_NAME est le 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

    Résultat :

    ● 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 Chronicle peut demander le résultat de cette commande pour vous aider et résoudre le problème.

Installer le redirecteur sous Linux

Cette section explique comment installer le redirecteur Chronicle à l'aide d'un conteneur Docker sur un système Linux.

Étape 1. Télécharger, transférer et installer les fichiers de configuration du redirecteur

Chronicle fournit des fichiers de configuration de redirecteur propres à votre système d'exploitation (Linux ou Windows). Vous pouvez télécharger le fichier de configuration selon vos besoins. Une fois les étapes suivantes effectuées, transférez les fichiers de configuration de votre ordinateur portable vers le répertoire /opt/chronicle/config du redirecteur, dans le répertoire d'accueil de l'utilisateur.

  1. Connectez-vous à l'hôte du redirecteur Linux via un terminal.

  2. Créez un utilisateur sur l'hôte du redirecteur Linux. 

      adduser USERNAME
  passwd USERNAME
  usermod -aG wheel USERNAME

  3. Accédez au répertoire d'accueil du nouvel utilisateur qui exécute le conteneur Docker.

  4. Créez un répertoire pour stocker les fichiers de configuration du redirecteur Chronicle: 

      mkdir /opt/chronicle/config

  5. Changez de répertoire. 

      cd /opt/chronicle/config

  6. Une fois les fichiers transférés, assurez-vous qu'ils se trouvent dans le répertoire /opt/chronicle/config: 

      ls -l

Étape 2. Exécuter le redirecteur dans le conteneur Docker

Vous pouvez suivre les procédures suivantes pour démarrer le redirecteur Chronicle pour la première fois et pour effectuer une mise à niveau vers la dernière version du conteneur Chronicle:

Les options --log-opt sont disponibles depuis la version Docker 1.13. Ces options limitent la taille des fichiers journaux du conteneur et doivent être utilisées tant que votre version de Docker les accepte.

  1. Si vous effectuez une mise à niveau, commencez par nettoyer toutes les exécutions Docker précédentes. Dans l'exemple suivant, le nom du conteneur Docker est cfps. Obtenez la dernière image Docker à partir de Google Cloud à l'aide de la commande docker pull, comme indiqué ci-dessous.

    docker stop cfps

    docker rm cfps

  2. Procurez-vous la dernière image Docker à partir de Google Cloud:

    docker pull gcr.io/chronicle-container/cf_production_stable

  3. Démarrez le redirecteur Chronicle à partir du conteneur Docker:

    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

Afficher les journaux du redirecteur

Pour afficher les journaux du redirecteur Chronicle, exécutez la commande suivante:

  sudo docker logs cfps

Pour afficher le chemin d'accès au fichier dans lequel les journaux sont stockés, exécutez la commande suivante:

docker inspect --format='{{.LogPath}}' CONTAINER_NAME

Pour afficher les journaux d'exécution en direct, exécutez la commande suivante:

  sudo docker logs cfps -f

Pour stocker les journaux dans un fichier, exécutez la commande suivante:

  sudo docker logs cfps &> logs.txt

Désinstaller le redirecteur

Les commandes Docker suivantes vous aident à arrêter et à désinstaller ou à supprimer le redirecteur Chronicle.

Pour arrêter ou désinstaller le conteneur du redirecteur:

    docker stop cfps

Pour supprimer le conteneur du redirecteur:

    docker rm cfps

Mettre à jour le redirecteur

Le redirecteur Chronicle se compose de deux parties et est mis à niveau comme suit:

  • Le groupe de redirecteur est mis à jour automatiquement et aucun redémarrage n'est nécessaire.

  • Image Docker du redirecteur : est mise à jour manuellement après l'arrêt du redirecteur existant et le démarrage d'une nouvelle instance comme indiqué à l'étape 2.

Installer le redirecteur derrière un proxy

Cette section explique comment installer le redirecteur Chronicle derrière un proxy.

  1. Configurez votre ordinateur pour qu'il utilise le proxy.

    1. Ajoutez les lignes suivantes à votre fichier /etc/resolv.conf:

      nameserver = 10.0.0.1
nameserver = 10.0.0.2

    2. Définissez les variables d'environnement suivantes :

      $HTTP_PROXY = http://proxy.example.com:80
$HTTPS_PROXY = https://proxy.example.com:80

  2. Configurez Docker pour utiliser le proxy.

    1. Créez un répertoire "systemd" pour le service Docker.

      mkdir /etc/systemd/system/docker.service.d

    2. Créez un fichier /etc/systemd/system/docker.service.d/http-proxy.conf qui ajoute les variables d'environnement HTTP_PROXY et HTTPS_PROXY.

      [Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Environment="HTTPS_PROXY=https://proxy.example.com:80/"

    3. Supprimez les modifications.

      $ sudo systemctl daemon-reload

    4. Vérifiez que la configuration a été chargée.

      $ sudo systemctl show --property Environment docker
Environment=HTTP_PROXY=http://proxy.example.com:80/
Environment=HTTPS_PROXY=https://proxy.example.com:80/

    5. Redémarrez Docker.

      $ sudo systemctl restart docker

  3. Procurez-vous la dernière image Docker du redirecteur Chronicle à partir de Google Cloud.

    docker pull gcr.io/chronicle-container/cf_production_stable

  4. Exécutez le conteneur de redirecteur Chronicle en ajoutant des variables d'environnement proxy.

    docker run \
--env HTTP_PROXY="http://proxy.example.com:80/" \
--env HTTPS_PROXY="https://proxy.example.com:80/" \
--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

Collecter des données

Les sections suivantes vous aident à configurer le redirecteur Chronicle pour ingérer différents types de données qui sont transférées à l'instance Chronicle.

Collecter les données Splunk

Vous pouvez configurer le redirecteur Chronicle pour transférer vos données Splunk vers Chronicle. Google Cloud configure le redirecteur Chronicle avec les informations suivantes pour transférer vos données depuis Splunk:

  • URL de l'API REST Splunk (par exemple, https://10.0.113.15:8089).

  • Des requêtes Splunk pour générer des données pour chacun des types de données requis (par exemple, index=dns).

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime
  • Mettez les identifiants de votre compte Splunk à la disposition du redirecteur Chronicle. Pour ce faire, créez un fichier creds.txt.

Pour utiliser un fichier creds.txt:

  1. Créez un fichier local pour vos identifiants Splunk et nommez-le creds.txt.

  2. Indiquez votre nom d'utilisateur sur la première ligne et le mot de passe sur la deuxième:

    cat creds.txt

myusername
mypassword

  3. Pour utiliser le redirecteur Chronicle afin d'accéder à une instance Splunk, copiez le fichier creds.txt dans le répertoire de configuration (celui qui contient les fichiers de configuration). Exemple :

    cp creds.txt /opt/chronicle/config/creds.txt

  4. Vérifiez que le fichier creds.txt se trouve à son emplacement correct: 

    ls /opt/chronicle/config

Collecter des données syslog

Le redirecteur Chronicle peut fonctionner comme un serveur Syslog. Vous pouvez configurer n'importe quel dispositif ou serveur compatible avec l'envoi de données syslog sur une connexion TCP ou UDP pour transférer leurs données au redirecteur Chronicle. Vous pouvez contrôler les données exactes que le dispositif ou le serveur envoie au redirecteur Chronicle. Le redirecteur Chronicle peut ensuite transférer les données à Chronicle.

Le fichier de configuration FORWARDER_NAME.conf (fourni par Google Cloud) spécifie les ports à surveiller pour chaque type de données transférées (par exemple, le port 10514). Par défaut, le redirecteur Chronicle accepte les connexions TCP et UDP.

Configurer rsyslog

Pour configurer rsyslog, vous devez spécifier une cible pour chaque port (par exemple, chaque type de données). Consultez la documentation de votre système pour connaître la syntaxe correcte. Les exemples suivants illustrent la configuration de la cible rsyslog:

  • Trafic des journaux TCP: dns.* @@192.168.0.12:10514

  • Trafic des journaux UDP: dns.* @192.168.0.12:10514

Activer le protocole TLS pour les configurations syslog

Vous pouvez activer TLS pour la connexion Syslog au redirecteur Chronicle. Dans le fichier de configuration du redirecteur Chronicle (FORWARDER_NAME.conf), spécifiez l'emplacement du certificat et de la clé de certificat générés, comme indiqué dans l'exemple suivant:

certificat "/opt/chronicle/external/certs/client_generated_cert.pem"
certificate_key "/opt/chronicle/external/certs/client_generated_cert.key"

Sur la base de l'exemple indiqué, modifiez le fichier de configuration du redirecteur Chronicle (FORWARDER_NAME.conf) comme suit:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

Quelques points importants à noter:

  • Vous pouvez configurer la taille de la mémoire tampon TCP. La taille de la mémoire tampon TCP par défaut est de 64 Ko.

  • La valeur par défaut et recommandée pour connection_timeout est de 60 secondes. La connexion TCP est interrompue si la connexion est inactive pendant un certain temps.

  • La version TLS minimale est comparée à la version TLS de la requête d'entrée. La version TLS de la requête d'entrée doit être supérieure à la version TLS minimale. La version minimale de TLS doit correspondre à l'une des valeurs suivantes: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Vous pouvez créer un répertoire de certificats dans le répertoire de configuration et y stocker les fichiers de certificats.

Collecter les données des fichiers

Un collecteur de fichiers est conçu pour récupérer les journaux d'un fichier. Le fichier doit être lié au conteneur Docker.

Utilisez cette option si vous souhaitez importer manuellement les journaux à partir d'un seul fichier journal. Cela permet de remplir les journaux pour un fichier journal particulier.

Démarrez le redirecteur Chronicle à partir du conteneur Docker:

  docker run \
    --name cfps \
    --log-opt max-size=100m \
    --log-opt max-file=10 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Cette commande docker run est essentielle pour mapper le volume de chargement au conteneur.

Sur la base de cet exemple, vous devez modifier la configuration du redirecteur Chronicle (fichier FORWARDER_NAME.conf) comme suit. Le fichier sample.txt doit être présent dans le dossier /var/log/crowdstrike/falconhostclient.

 collectors:
  - file:
       common:
         enabled: true
         data_type: CS_EDR
         data_hint:
         batch_n_seconds: 10
         batch_n_bytes: 1048576
       file_path: /opt/chronicle/edr/sample.txt
       filter:

Configurations d'indicateurs

skip_seek_to_end (bool): cet indicateur est défini sur false par défaut et l'entrée de fichier n'envoie que de nouvelles lignes de journal en entrée. Si vous définissez cette valeur sur true, toutes les lignes de journal précédentes sont à nouveau envoyées lors des redémarrages du redirecteur. Cela provoque la duplication des journaux. Définir cet indicateur sur true est utile dans certaines situations (par exemple, en cas de panne), car le redémarrage du redirecteur renvoie à nouveau les lignes de journal manquantes.

poll (bool): le collecteur de fichiers utilise la bibliothèque Tail pour rechercher d'éventuelles modifications dans le système de fichiers. En définissant cet indicateur sur true, la bibliothèque Tail utilise la méthode d'interrogation au lieu de la méthode de notification par défaut.

Collecter les données des paquets

Le redirecteur Chronicle peut capturer des paquets directement à partir d'une interface réseau à l'aide de libcap sous Linux. Pour en savoir plus sur libcap, consultez la page du manuel Linux libcap.

Les paquets sont capturés et envoyés à Chronicle au lieu des entrées de journal. La capture de paquets est gérée uniquement à partir d'une interface locale. Pour activer la capture de paquets pour votre système, contactez l'assistance Chronicle.

Google Cloud configure le redirecteur Chronicle avec l'expression BPF (Berkeley Packet Filter) utilisée lors de la capture de paquets (par exemple, sur le port 53 et non sur "localhost"). Pour plus d'informations, consultez la section Filtres de paquets de Berkeley.

Collecter les données du sujet Kafka

Vous pouvez ingérer les données des sujets Kafka de la même manière que dans syslog. Les groupes de consommateurs permettent de déployer jusqu'à trois redirecteurs et d'extraire des données du même sujet Kafka. Pour en savoir plus, consultez Kafka.

Pour en savoir plus sur les groupes de consommateurs Kafka, consultez la page https://docs.confluent.io/platform/current/clients/consumer.html.

Exemple de configuration: entrée Kafka

La configuration de redirecteur suivante montre comment le configurer pour ingérer les données des sujets Kafka.

Fichier FORWARDER_NAME.conf

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "/path/to/cert.pem"
        certificate_key: "/path/to/cert.key"
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Fichier FORWARDER_NAME_auth.conf

collectors:
- kafka:
      username: user
      password: password
- syslog:

Collecter des données WebProxy

Le redirecteur Chronicle peut capturer les données WebProxy directement à partir d'une interface réseau à l'aide de libcap sous Linux. Pour en savoir plus sur libcap, consultez la page du manuel Linux libcap. Pour activer la capture de données WebProxy pour votre système, contactez l'assistance Chronicle.

Modifiez la configuration du redirecteur Chronicle (fichier FORWARDER_NAME.conf) comme suit:

- webproxy:
      common:
        enabled : true
        data_type: <Your LogType>
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: any
      bpf: tcp and dst port 80

Personnaliser les configurations

Le tableau suivant répertorie les paramètres importants utilisés dans le fichier de configuration du redirecteur.

Paramètres Description
data_type Type de données de journal que le collecteur peut collecter et traiter.
métadonnées Métadonnées, qui remplacent les métadonnées globales.
max_file_buffer_bytes Nombre maximal d'octets pouvant être accumulés dans le tampon du disque ou du fichier. La valeur par défaut est 1073741824, soit 1 Go.
max_memory_buffer_bytes Nombre maximal d'octets pouvant être accumulés dans la mémoire tampon. La valeur par défaut est 1073741824, soit 1 Go.
write_to_disk_dir_path Chemin d'accès à utiliser pour le fichier ou le tampon de disque.
write_to_disk_buffer_enabled Si la valeur est true, le tampon de disque est utilisé à la place du tampon de mémoire. La valeur par défaut est false.
batch_n_bytes Nombre maximal d'octets pouvant être accumulés par le collecteur, après lesquels les données sont regroupées. La valeur par défaut est 1048576, soit 1 Mo.
batch_n_seconds Nombre de secondes après lesquelles les données collectées par le collecteur sont regroupées. La valeur par défaut est de 11 secondes.
data_hint Format de données que le collecteur peut recevoir (généralement l'en-tête du fichier journal qui décrit le format).

Pour obtenir la liste complète des paramètres utilisés dans le fichier de configuration, consultez Champs de configuration du système de transfert et Champs de configuration du collecteur.

Activer/Désactiver la compression des données

La compression des journaux réduit la consommation de la bande passante réseau lors du transfert des journaux vers Chronicle. Cependant, la compression peut entraîner une augmentation de l'utilisation du processeur. Le compromis entre l'utilisation du processeur et la bande passante dépend de nombreux facteurs, y compris du type de données de journal, de la compressibilité de ces données, de la disponibilité des cycles de processeur sur l'hôte qui exécute le redirecteur et de la nécessité de réduire la consommation de bande passante réseau.

Par exemple, les journaux textuels se compressent bien et peuvent faire des économies substantielles en bande passante avec une faible utilisation du processeur. Toutefois, les charges utiles chiffrées des paquets bruts ne sont pas correctement compressées et entraînent une utilisation plus élevée du processeur.

Par défaut, la compression des journaux est désactivée. L'activation de la compression des journaux peut réduire la consommation de bande passante. Toutefois, l'activation de la compression des journaux peut également augmenter l'utilisation du processeur. Faites attention au compromis.

Pour activer la compression des journaux, définissez le champ compression sur true dans le fichier de configuration du redirecteur Chronicle, comme indiqué dans l'exemple suivant:

Fichier FORWARDER_NAME.conf

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

Fichier FORWARDER_NAME_auth.conf

output:
  identity:
    secret_key: |
    {
     "type": "service_account",
...
    }

Configurer la mise en mémoire tampon sur le disque

La mise en mémoire tampon sur le disque vous permet de mettre en mémoire tampon les messages en attente sur le disque plutôt que sur la mémoire. Les messages en attente peuvent être stockés si le redirecteur ou l'hôte sous-jacent plante. Sachez que l'activation de la mise en mémoire tampon du disque peut affecter les performances.

Si la mise en mémoire tampon du disque est désactivée, le redirecteur utilise 1 Go de mémoire (RAM) pour chaque type de journal (par exemple, par connecteur). Spécifiez le paramètre de configuration max_memory_buffer_bytes. La mémoire maximale autorisée est de 4 Go.

Vous pouvez configurer la mise en mémoire tampon automatique pour utiliser un tampon partagé dynamiquement entre les collecteurs, ce qui permet de mieux gérer les pics de trafic. Pour activer le tampon partagé dynamique, ajoutez les éléments suivants dans la configuration du système de transfert:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Si la mise en mémoire tampon automatique du disque est activée, mais que target_memory_utilization n'est pas défini, la valeur par défaut 70 est utilisée.

Si vous exécutez le redirecteur à l'aide de Docker, Google vous recommande d'installer un volume distinct de votre volume de configuration à des fins d'isolation. En outre, chaque entrée doit être isolée avec son propre répertoire ou volume pour éviter les conflits.

Exemple de configuration: mise en mémoire tampon du disque

La configuration suivante inclut la syntaxe permettant d'activer la mise en mémoire tampon du disque:

collectors:
- syslog:
    common:
      write_to_disk_buffer_enabled: true
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Définir des filtres d'expressions régulières

Les filtres d'expression régulière vous permettent de filtrer les journaux en fonction des correspondances d'expressions régulières avec les journaux bruts.

Les filtres utilisent la syntaxe RE2 décrite ici : https://github.com/google/re2/wiki/Syntax

Les filtres doivent inclure une expression régulière et, éventuellement, définir un comportement en cas de correspondance. Le comportement par défaut en cas de correspondance est le blocage (vous pouvez également le configurer explicitement en tant que bloc).

Vous pouvez également spécifier des filtres avec le comportement allow. Si vous spécifiez un filtre allow, le redirecteur bloque tous les journaux qui ne correspondent à aucun filtre allow.

Il est possible de définir un nombre arbitraire de filtres. Les filtres de bloc sont prioritaires sur les filtres allow.

Lorsque des filtres sont définis, un nom doit leur être attribué. Les noms des filtres actifs seront transmis à Chronicle via les métriques d'état de Forwarder. Les filtres définis à la racine de la configuration sont fusionnés avec les filtres définis au niveau du collecteur. Les filtres au niveau du collecteur sont prioritaires en cas de conflit de noms. Si aucun filtre n'est défini au niveau racine ou au niveau du collecteur, le comportement consiste à tout autoriser.

Exemple de configuration: filtres d'expressions régulières

Dans la configuration de redirecteur suivante, les journaux WINEVTLOG qui ne correspondent pas au filtre racine (allow_filter) sont bloqués. Compte tenu de l'expression régulière, le filtre n'autorise que les journaux dont les priorités sont comprises entre 0 et 99. Toutefois, tous les journaux NIX_SYSTEM contenant "foo" ou "bar" sont bloqués, malgré la allow_filter. En effet, les filtres utilisent un opérateur logique "OR". Tous les journaux sont traités jusqu'à ce qu'un filtre soit déclenché.

regex_filters:
  allow_filter:
    regexp: ^<[1-9][0-9]?$>.*$
    behavior_on_match: allow
collectors:
- syslog:
    common:
      regex_filters:
        block_filter_1:
          regexp: ^.*foo.*$
          behavior_on_match: block
        block_filter_2:
          regexp: ^.*bar.*$
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurer des étiquettes arbitraires

Les étiquettes permettent d'associer des métadonnées arbitraires aux journaux à l'aide de paires clé/valeur. Les libellés peuvent être configurés pour l'ensemble d'un redirecteur ou dans un collecteur spécifique d'un redirecteur. Si les deux sont fournis, les libellés sont fusionnés avec les clés du collecteur. Elles prévalent sur les clés du redirecteur si les clés se chevauchent.

Exemple de configuration: étiquettes arbitraires

Dans la configuration de redirecteur suivante, les paires clé/valeur "foo=bar" et "meow=mix" sont toutes deux associées aux journaux WINEVTLOG, tandis que les paires clé/valeur "foo=baz" et "meow=mix" sont associées aux journaux NIX_SYSTEM.

metadata:
  labels:
    foo: bar
    meow: mix
collectors:
syslog:
    common:
      metadata:
        labels:
          foo: baz
          meow: mix
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Configurer des espaces de noms

Utilisez des étiquettes d'espace de noms pour identifier les journaux de segments réseau distincts et délimiter les conflits d'adresses IP qui se chevauchent. Vous pouvez configurer un libellé d'espace de noms pour un redirecteur entier ou dans un collecteur spécifique du redirecteur. Si les deux sont inclus, l'espace de noms du collecteur spécifique est prioritaire.

Tout espace de noms configuré pour le redirecteur apparaît avec les éléments associés dans l'interface utilisateur Chronicle. Vous pouvez également rechercher des espaces de noms à l'aide de la fonctionnalité Recherche Chronicle.

Pour savoir comment afficher les espaces de noms dans l'interface utilisateur Chronicle, cliquez ici.

Exemple de configuration: espaces de noms

Dans la configuration de redirecteur suivante, les journaux WINEVTLOG sont associés à l'espace de noms FORWARDER et les journaux NIX_SYSTEM à l'espace de noms CORPORATE.

metadata:
  namespace: FORWARDER
collectors:
- syslog:
      common:
        metadata:
          namespace: CORPORATE
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      tcp_address: 0.0.0.0:30000
      connection_timeout_sec: 60
- syslog:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: WINEVTLOG
        enabled: true
      tcp_address: 0.0.0.0:30001
      connection_timeout_sec: 60

Configurer l'équilibrage de charge et les options de haute disponibilité

Le redirecteur Chronicle pour Linux peut être déployé dans un environnement dans lequel un équilibreur de charge de couche 4 est installé entre la source de données et les instances du redirecteur. Cela permet à un client de distribuer la collecte de journaux sur plusieurs redirecteurs ou d'envoyer les journaux à un autre redirecteur en cas d'échec de l'un d'entre eux. Cette fonctionnalité n'est compatible qu'avec le type de collection syslog.

Le redirecteur Linux inclut un serveur HTTP intégré qui répond aux vérifications d'état HTTP de l'équilibreur de charge. Le serveur HTTP permet également de s'assurer que les journaux ne sont pas perdus au démarrage ou à l'arrêt d'un redirecteur.

Configurez le serveur HTTP, l'équilibrage de charge et les options de haute disponibilité dans la section server du fichier de configuration du redirecteur. Ces options permettent de définir des durées de délai avant expiration et des codes d'état renvoyés en réponse aux vérifications de l'état reçues dans les déploiements utilisant le planificateur de conteneurs et les déploiements basés sur l'orchestration, ainsi que par les équilibreurs de charge traditionnels.

Utilisez les chemins d'URL suivants pour les vérifications d'état, d'aptitude et d'activité. Les valeurs <host:port> sont définies dans la configuration du redirecteur.

  • http://<host:port>/meta/available: vérifications de l'activité pour les planificateurs ou les orchestrateurs de conteneurs.
  • http://<host:port>/meta/ready: vérifications d'aptitude et vérifications d'état classiques de l'équilibreur de charge.

La configuration de redirecteur suivante est un exemple d'équilibrage de charge et de haute disponibilité:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
Chemin d'accès à la configuration Description
serveur : Grace_timeout Durée pendant laquelle le redirecteur renvoie une vérification d'aptitude/d'état incorrecte et accepte toujours de nouvelles connexions. C'est également le temps d'attente entre la réception d'un signal pour s'arrêter et le début réel de l'arrêt du serveur lui-même. Cela laisse à l'équilibreur de charge le temps de supprimer le redirecteur du pool.
serveur : drain_timeout Durée pendant laquelle le redirecteur attend que les connexions actives se ferment automatiquement avant d'être fermées par le serveur.
serveur : http : port Numéro de port que le serveur HTTP écoute pour les vérifications d'état provenant de l'équilibreur de charge. Doit être comprise entre 1024 et 65 535.
serveur : http : hôte Adresse IP, ou nom d'hôte pouvant être résolu en adresses IP, que le serveur doit écouter. Si ce champ est vide, la valeur par défaut est "local system" (0.0.0.0).
serveur : http : read_timeout Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour lire l'intégralité de la requête, à la fois l'en-tête et le corps. Vous pouvez définir read_timeout et read_header_timeout.
serveur : http : read_header_timeout Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour lire les en-têtes de requêtes. Le délai de lecture de la connexion est réinitialisé après la lecture de l'en-tête.
serveur : http : write_timeout Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour envoyer une réponse. Elle est réinitialisée lorsqu'un nouvel en-tête de requête est lu.
serveur : http : inactif_timeout Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Délai maximal d'attente pour la requête suivante lorsque les connexions inactives sont activées. Si la valeur "idle_timeout" est nulle, la valeur de "read_timeout" est utilisée. Si les deux valeurs sont égales à zéro, read_header_timeout est utilisé.
routes : méta : ready_status Code d'état renvoyé par le redirecteur lorsqu'il est prêt à accepter le trafic dans l'une des situations suivantes:
  • La vérification d'aptitude est envoyée par un planificateur ou un orchestre de conteneurs.
  • La vérification de l'état est reçue par un équilibreur de charge traditionnel.
routes : méta : unready_status Code d'état renvoyé par le redirecteur lorsqu'il n'est pas prêt à accepter le trafic.
routes : méta : available_status Code d'état renvoyé par le redirecteur lorsqu'une vérification d'activité est reçue et qu'il est disponible. Les programmeurs ou orchestrateurs de conteneurs envoient souvent des vérifications d'activité.

Questions fréquentes

Comment mettre à jour mon redirecteur ?

Le redirecteur Linux est constamment mis à jour via un script shell dans l'image Docker. Pour mettre à jour l'image Docker, exécutez le redirecteur.

Qu'est-ce qu'un conteneur Docker ?

  • Les conteneurs Docker sont comme des machines virtuelles qui renforcent la sécurité, l'isolation et la gestion des ressources.

  • Les machines virtuelles disposent à la fois d'un espace privilégié (noyau Linux) et d'un espace utilisateur (tous les éléments avec lesquels vous interagissez: libc, python, ls, tcpdump, etc.).

  • Les conteneurs ne disposent que d'un espace utilisateur (tous les éléments avec lesquels vous interagissez: libc, Python, ls, tcpdump, etc.) et dépendent de l'espace de privilèges de l'hôte.

Pourquoi distribuer le redirecteur Chronicle à l'aide d'un conteneur ?

  • Renforcer la sécurité grâce à l'isolation :
    • L'environnement et les exigences du client n'affectent pas le redirecteur Chronicle.
    • Les exigences et l'environnement de redirecteur Chronicle n'affectent pas le client.
    • Le mécanisme de distribution de conteneurs existe déjà. Il peut être privé et distinct pour Google Cloud et les clients. https://cloud.google.com/container-registry/

Pourquoi uniquement Linux pour les conteneurs ? Qu'en est-il de Windows ?

  • Les conteneurs ont d'abord été développés pour Linux et sont prêts pour la production.

  • La compatibilité Windows avec les conteneurs est en cours. Les conteneurs sont disponibles pour Windows Server 2016 et Windows 10.

Avez-vous besoin d'apprendre les commandes Docker avancées ?

  • Le redirecteur Chronicle utilise un seul conteneur. Il n'est donc pas nécessaire de vous familiariser avec Swarm, l'orchestration ou d'autres concepts ou commandes avancés de Docker.