Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Installer et configurer le redirecteur sous Linux

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

Le service de transfert sert à envoyer des journaux depuis l'environnement client vers l'instance Chronicle. Elle est utilisée lorsque les clients souhaitent envoyer les journaux directement à Chronicle et qu'ils ne souhaitent pas utiliser les buckets cloud pour ingérer des données, ou lorsque le type de journal n'a pas d'ingestion native via une API tierce. Le redirecteur peut être utilisé comme solution prête à déployer, au lieu d'intégrer 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

Voici 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 Par exemple, la détection et la réponse au niveau des points de terminaison (EDR), les paramètres DNS et DHCP sont tous des types de données distincts. Vous avez besoin de 3 Go de RAM pour collecter des données.

  • Processeur : deux processeurs sont suffisants pour gérer moins de 10 000 événements par seconde (EPS,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 suffisant, quelle que soit la quantité de données géré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 Mise en mémoire tampon du disque. Le redirecteur Chronicle se met en mémoire tampon par défaut.

Vérifier la configuration du pare-feu

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

Type de connexion Destination Port
TCP malachiteingestion-pa.googleapis.com 443
TCP malachiteingestion-europe-backstory.googleapis.com 443
TCP malachiteingestion-asia-southeast1-backstory.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP storage.googleapis.com 443

Personnaliser les fichiers de configuration

Contactez votre représentant Chronicle pour obtenir les modèles de fichiers de configuration.

Google Cloud adapte les fichiers de configuration à l'instance de transfert à l'aide de métadonnées spécifiques, comme indiqué dans la section des résultats. Vous pouvez modifier les fichiers 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, contactez l'assistance Chronicle.

Pour configurer le redirecteur Linux:

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

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

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

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

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

  4. Vérifiez qu'il existe une entrée pour chaque entrée du fichier AUTH_CREDENTIALS.conf, même si l'entrée ne contient pas les informations d'authentification correspondantes. Cette opération est nécessaire pour mapper correctement les données.

Exemple de configuration

L'exemple de code suivant montre le format des fichiers de configuration d'une instance de transfert.

Le fichier CONFIG_SETTINGS.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
enable_auto_update: false

Le fichier AUTH_CREDENTIALS.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"

La configuration liée à des entrées spécifiques est mentionnée dans leurs sections individuelles de ce document.

Ces deux systèmes de fichiers vous permettent de stocker vos identifiants d'authentification dans des fichiers distincts pour une sécurité renforcée. Vous pouvez stocker votre fichier de configuration dans un dépôt Git privé ou dans n'importe quel système de gestion de configuration ouvert et récupérer les identifiants directement dans la machine virtuelle sur laquelle vous exécutez 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
enable_auto_update: false

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

  1. Créez une copie de votre configuration existante.
  2. Enregistrez un fichier sous le nom CONFIG_SETTINGS.conf et supprimez les identifiants d'autorisation du fichier.
  3. Enregistrez l'autre fichier sous le nom AUTH_CREDENTIALS.conf et supprimez toutes les données sans autorisation du fichier. 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 populaires. Toutefois, 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 Docker.

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

Pour vérifier que 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é correctement installé:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Vous pouvez collecter des informations supplémentaires sur l'installation de Docker à l'aide de la commande suivante:

    docker info
  

Si vous rencontrez des problèmes avec Docker, l'équipe d'assistance Chronicle peut demander le résultat de cette commande pour vous aider à 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.

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

Google Cloud fournit des fichiers de configuration de redirecteur spécifiques à votre système d'exploitation (Linux ou Windows). Téléchargez les fichiers à partir du lien fourni par votre représentant Chronicle dans un répertoire local de votre ordinateur portable (par exemple, un répertoire nommé Chronicle). Une fois les étapes suivantes effectuées, transférez les fichiers de configuration depuis 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 le terminal.

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

      adduser USERNAME
      passwd USERNAME
      usermod -aG wheel USERNAME
    

  3. Passez 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. Changer d'annuaire.

      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 la mise à niveau vers la dernière version du conteneur Chronicle:

Les options --log-opt sont disponibles depuis 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 auprès de Google Cloud à l'aide de la commande docker pull, comme indiqué ci-dessous.

    docker stop cfps
    
    docker rm cfps
    
  2. Obtenez la dernière image Docker auprès 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
    

Désinstaller le redirecteur

Les commandes Docker suivantes vous permettent d'arrêter, de désinstaller ou de supprimer le redirecteur Chronicle.

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

    docker stop cfps
  

Pour supprimer le conteneur de redirecteur:

    docker rm cfps
  

Mettre à jour le redirecteur

Le redirecteur Chronicle comporte deux parties et est mis à niveau comme suit:

  • Forwarder Bundle : est automatiquement mis à jour et aucun redémarrage n'est nécessaire.

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

Collecter des données

Les sections suivantes vous aident à configurer le redirecteur Chronicle pour transférer différents types de données.

Collecter les données Splunk

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

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

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

Vous devez mettre vos identifiants de compte Splunk à la disposition du redirecteur Chronicle.

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

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

  cat creds-file

  myusername
  mypassword

Pour les clients qui utilisent le redirecteur Chronicle pour accéder à une instance Splunk, copiez le fichier creds.txt dans le répertoire de configuration (le même répertoire que les fichiers de configuration). Exemple :

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

Vérifiez que le fichier creds.txt est situé à l'emplacement approprié:

  ls /opt/chronicle/config
- 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: 10
      maximum_window_size: 30
      user: admin
      password: letmeinaA1!
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size:période minimale transmise à la requête Splunk. La valeur par défaut est de 10 secondes. Ce paramètre est utilisé pour le réglage si l'exigence consiste à modifier la fréquence d'interrogation du serveur Splunk lorsque le redirecteur est à l'état stable. De plus, en cas de retard, l'appel d'API Splunk peut être effectué plusieurs fois.

maximum_window_size:période maximale transmise à la requête Splunk. La valeur par défaut est de 30 secondes. Ce paramètre est utilisé pour les réglages en cas de retard ou si des données supplémentaires sont nécessaires par requête.

Modifiez ce paramètre (égal ou supérieur à) lorsque vous modifiez le paramètre minimal. Des retards peuvent se produire si un appel de requête Splunk prend plus de temps que maximum_window_size.

Collecter les données syslog

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

Le fichier de configuration CONFIG_SETTINGS.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, pour 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 du journal TCP: dns.* @192.168.0.12:10514

  • Trafic du journal 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 (CONFIG_SETTINGS.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"
certificat_clé "/opt/chronicle/external/certs/client_generated_cert.key"

Sur la base de l'exemple affiché, modifiez le fichier de configuration du redirecteur Chronicle (CONFIG_SETTINGS.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:

  • Vous pouvez configurer la taille de la mémoire tampon TCP. La taille par défaut du tampon TCP 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 elle est inactive pendant une durée déterminée.

  • 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 sous le répertoire de configuration et y stocker les fichiers de certificat.

Collecter les données du fichier

Utilisez cette option si vous souhaitez importer manuellement des journaux à partir d'un seul fichier journal. Cela peut être utilisé pour remplir les journaux d'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/falconhoseclient:/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 CONFIG_SETTINGS.conf) comme suit:

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

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 Manuels sur libcap – Linux.

Les paquets sont capturés et envoyés à Chronicle au lieu d'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 de filtre de paquets Berkeley (BPF, Berkeley Packet Filter) utilisé pour capturer des paquets (par exemple, le port 53 et non localhost). Pour en savoir plus, consultez la section Filtres de paquets Berkeley.

Collecter des données à partir 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 sont utilisés pour vous permettre 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 les pages suivantes : https://docs.confluent.io/platform/current/clients/consumer.html

Exemple de configuration: entrée Kafka

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

Le fichier CONFIG_SETTINGS.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

Le fichier AUTH_CREDENTIALS.conf

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

Personnaliser les configurations facultatives

Activer/Désactiver la compression des données

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

Par exemple, les journaux texte se compressent bien et peuvent réduire considérablement la bande passante tout en consommant peu de ressources processeur. Cependant, les charges utiles chiffrées des paquets bruts ne se compriment pas bien et augmentent l'utilisation 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. Tenez compte du 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:

Le fichier CONFIG_SETTINGS.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
...

Le fichier AUTH_CREDENTIALS.conf

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

Configurer la mise en mémoire tampon du disque

La mise en mémoire tampon du 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 au cas où le redirecteur plante 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 connecteur, par exemple). Spécifiez le paramètre de configuration max_memory_buffer_bytes. La mémoire maximale autorisée est de 4 Go.

Si vous exécutez le redirecteur à l'aide de Docker, nous vous recommandons 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 une syntaxe permettant 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'expression régulière

Les filtres d'expressions régulières vous permettent de filtrer les journaux en fonction des correspondances d'expressions régulières par rapport aux journaux bruts.

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

Les filtres doivent inclure une expression régulière et, éventuellement, définir un comportement en cas de correspondance. Le comportement par défaut d'une 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 pas à au moins un filtre allow.

Il est possible de définir un nombre arbitraire de filtres. Les filtres de blocage ont priorité sur les filtres de allow.

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

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

Dans la configuration du redirecteur suivant, 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 la priorité est comprise entre 0 et 99. Toutefois, tous les journaux NIX_SYSTEM contenant "&&39;bar 'bar'" sont bloqués, malgré le allow_filter. En effet, les filtres utilisent un OU logique. 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 libellés permettent d'associer des métadonnées arbitraires aux journaux à l'aide de paires clé/valeur. Les étiquettes peuvent être configurées pour un redirecteur complet ou dans le collecteur spécifique d'un redirecteur. Si les deux sont fournis, les étiquettes sont fusionnées avec les clés du collecteur à la place des clés du redirecteur si celles-ci se chevauchent.

Exemple de configuration: étiquettes arbitraires

Dans la configuration du redirecteur suivante, les paires "clé" et "clé" et "valeur" sont toutes les deux associées aux journaux WINEVTLOG, tandis que les paires "clé" et "valeur" 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 les libellés d'espace de noms pour identifier les journaux provenant de segments de réseau distincts et éviter les conflits d'adresses IP qui se chevauchent. Vous pouvez configurer un libellé d'espace de noms pour l'ensemble d'un redirecteur ou dans un collecteur spécifique du redirecteur. Si les deux sont inclus, l'espace de noms du collecteur 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é de 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 du redirecteur suivante, les journaux WINEVTLOG sont associés à l'espace de noms FORWARDER, et les journaux NIX_SYSTEM sont associés à 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 où un équilibreur de charge de couche 4 est installé entre la source de données et les instances de redirecteur. Cela permet à un client de distribuer la collecte de journaux sur plusieurs redirecteurs ou d'envoyer des journaux à un autre redirecteur en cas d'échec. Cette fonctionnalité n'est compatible qu'avec le type de collection syslog.

Le redirecteur Linux comprend 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 garantir que les journaux ne seront pas perdus au démarrage ou à l'arrêt d'un redirecteur.

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

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

  • http://<host:port>/meta/available: vérifications de l'activité pour les programmeurs/orchestrateurs de conteneurs, tels que Kubernetes.
  • http://<host:port>/meta/ready: vérifications de l'aptitude et des vérifications d'état traditionnelles de l'équilibreur de charge.

La configuration du redirecteur suivante est un exemple pour l'équilibrage de charge et la 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 de la configuration Description
serveur : Grace_timeout Durée pendant laquelle le redirecteur renvoie une vérification d'aptitude ou d'état incorrecte et accepte toujours les nouvelles connexions. Il s'agit également du temps entre la réception d'un signal d'arrêt et le début de l'arrêt du serveur lui-même. Cela permet à l'équilibreur de charge de supprimer le redirecteur du pool.
serveur : drain_timeout Durée pendant laquelle le redirecteur attend la fermeture active des connexions actives avant d'être fermé par le serveur.
serveur : http : port Numéro de port sur lequel le serveur HTTP écoute les vérifications d'état de l'équilibreur de charge. Doit être compris entre 1024 et 65535.
serveur : http : hôte Adresse IP, ou nom d'hôte qui peut être résolu en adresses IP, que le serveur doit écouter. Si ce champ est vide, la valeur par défaut est "0.0.0.0" (système local).
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 la requête entière, à la fois dans l'en-tête et dans le corps. Vous pouvez définir à la fois "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. La lecture du délai est réinitialisée 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 d'envoi d'une réponse. Il est réinitialisé lors de la lecture d'un nouvel en-tête de requête.
serveur : http : inactive_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 d'attente de la requête suivante lorsque les connexions inactives sont activées. Si "id_timeout" est nul, la valeur "read_timeout" est utilisée. Si les deux sont nuls, le paramètre read_header_timeout est utilisé.
routes : meta : 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 programmeur ou un organisateur de conteneurs, tel que Kubernetes.
  • La vérification de l'état provient d'un équilibreur de charge traditionnel.
routes : meta : unready_status Code d'état renvoyé par le redirecteur lorsqu'il n'est pas prêt à accepter le trafic.
routes : meta : available_status Code d'état renvoyé par le redirecteur lorsqu'une vérification d'activité est reçue et que le redirecteur est disponible. Les programmeurs/orchestrateurs de conteneurs tels que Kubernetes envoient souvent des vérifications de vivacité.

Questions fréquentes

Comment mettre à jour mon redirecteur ?

Le redirecteur Windows n'est pas constamment mis à jour, car peu de clients l'utilisent. Le redirecteur Linux est constamment mis à jour via un script shell dans l'image Docker. Il n'est donc pas nécessaire de fournir un fichier exécutable pour cela. Toutefois, si un client ouvre une demande d'assistance pour obtenir le dernier fichier exécutable Windows pour le redirecteur, l'équipe d'assistance lui fournit un fichier EXE via le portail d'assistance.

Qu'est-ce qu'un conteneur Docker ?

  • Les conteneurs Docker sont comme des machines virtuelles qui offrent une sécurité, une isolation et une gestion des ressources supplémentaires.

  • Les machines virtuelles disposent 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 ?

  • Améliorer la sécurité grâce à l'isolation :
    • L'environnement client et les exigences n'ont aucune incidence sur le redirecteur Chronicle.
    • L'environnement de transfert Chronicle et les exigences n'affectent pas le client.
    • Ce mécanisme de distribution des conteneurs existe déjà et 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é des conteneurs avec Windows 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. Vous n'avez donc pas besoin d'en savoir plus sur Swarm, l'orchestration, Kubernetes, ni sur les autres concepts ou commandes Docker avancés.