Gérer manuellement le fichier de configuration du redirecteur

Cette page explique comment créer et modifier manuellement un fichier de configuration de redirecteur Google Security Operations. Pour configurer le redirecteur via l'interface utilisateur (recommandé), consultez Gérer les configurations de redirecteur via l'interface utilisateur Google SecOps.

Chaque transférateur Google SecOps déployé nécessite un fichier de configuration de transférateur. Un fichier de configuration du redirecteur spécifie les paramètres permettant de transférer les données vers votre instance Google SecOps.

Pour savoir comment installer et configurer le transmetteur Google SecOps, connaître la configuration système requise et obtenir des informations sur les paramètres de configuration, consultez Installer et configurer le transmetteur.

Avant de commencer

Avant de créer le fichier de configuration, planifiez votre implémentation en comprenant les types de données pouvant être ingérés et les attributs clés que vous devez définir dans le fichier de configuration.

Créer le fichier de configuration

Pour créer manuellement le fichier de configuration, procédez comme suit :

1. Téléchargez les fichiers de configuration depuis l'interface utilisateur.

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

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

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

3. Modifiez les fichiers pour inclure la configuration de votre instance de transfert.

   Pour en savoir plus sur les paramètres de chaque type de mécanisme d'ingestion, comme Splunk ou Syslog, consultez Définir des types de données dans votre fichier de configuration. Pour savoir comment personnaliser chaque attribut, comme la compression des données ou la mise en mémoire tampon sur disque, consultez Configurer les attributs clés dans le fichier de configuration.

4. Assurez-vous qu'il existe une entrée pour chaque entrée dans le fichier FORWARDER_NAME_auth.conf, même si l'entrée ne comporte pas de détails d'authentification correspondants. Ce paramètre est obligatoire pour mapper correctement les données.

Toutes les modifications apportées au fichier de configuration seront automatiquement appliquées par le transmetteur dans un délai de cinq minutes.

Exemples de configurations

Vous pouvez utiliser les fichiers de configuration suivants comme modèles pour créer les vôtres.

Exemple de configuration à deux fichiers

Ce système de fichiers stocke les identifiants d'authentification dans un fichier distinct pour renforcer la sécurité. Vous pouvez stocker le fichier FORWARDER_NAME.conf dans un dépôt de contrôle des versions ou dans n'importe quel 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.

L'exemple de code suivant montre le format des fichiers de configuration d'un redirecteur.

Le fichier FORWARDER_NAME.conf

output:
  url: {region}-chronicle.googleapis.com (for example: us-chronicle.googleapis.com)
  use_dataplane : true
  project_id: PROJECT_ID
  region: {region} (for example: {us})
  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

Le 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"

Exemple de configuration à fichier unique

output:
  url: us-chronicle.googleapis.com
  use_dataplane: true
  project_id: PROJECT_ID
  region: us
    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

Passer d'un système à un fichier à un système à deux fichiers

Si vous utilisez un seul fichier de configuration et que vous souhaitez passer au système à deux fichiers, procédez comme suit :

1. Créez une copie de votre fichier de configuration existant.

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 non liées à l'autorisation du fichier. Vous pouvez utiliser l'exemple de configuration comme référence. Assurez-vous de respecter la convention d'attribution de noms et les autres consignes mentionnées dans la section Personnaliser les configurations.

Définir des types de données dans votre fichier de configuration

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

Données Splunk

Vous pouvez configurer le transmetteur Google SecOps pour transférer vos données Splunk vers Google SecOps. Google Cloud configure le transmetteur Google SecOps 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).

• Requêtes Splunk permettant de 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 Google SecOps. 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. Placez 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 transmetteur Google SecOps afin d'accéder à une instance Splunk, copiez le fichier creds.txt dans le répertoire de configuration (le même répertoire où se trouvent les fichiers de configuration).

   Linux

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

   Windows

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

4. Vérifiez que le fichier creds.txt se trouve dans le répertoire prévu :

   Linux

     ls /opt/chronicle/config
   

   Windows

   ls c:/opt/chronicle/config
   

Données Syslog

Un redirecteur peut fonctionner comme un serveur Syslog. Vous pouvez configurer n'importe quel serveur compatible avec l'envoi de données Syslog via une connexion TCP ou UDP pour qu'il transfère ses données au transmetteur Google SecOps. Vous pouvez contrôler les données que le serveur envoie au transitaire, qui peut ensuite les transférer vers Google SecOps.

Le fichier de configuration FORWARDER_NAME.conf (fourni parGoogle 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 Google SecOps accepte les connexions TCP et UDP.

Vous pouvez personnaliser la taille du tampon TCP. La taille de 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 elle est inactive pendant plus de 60 secondes.

Configurer rsyslog

Pour configurer rsyslog, vous devez spécifier une cible pour chaque port (par exemple, chaque type de données). Les exemples suivants illustrent la configuration de la cible rsyslog :

• Trafic du journal TCP : dns.* @@192.168.0.12:10514

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

Pour en savoir plus, consultez la documentation de votre système.

Activer TLS pour les configurations Syslog

Vous pouvez activer TLS pour la connexion Syslog au redirecteur Google SecOps. Dans le fichier de configuration du redirecteur (FORWARDER_NAME.conf), spécifiez l'emplacement de votre propre certificat et clé de certificat générés, comme indiqué dans l'exemple suivant. Vous pouvez créer un répertoire certs sous le répertoire configuration et y stocker les fichiers de certificat.

Linux :

Windows :

En vous basant sur l'exemple ci-dessus, modifiez le fichier de configuration du redirecteur (FORWARDER_NAME.conf) comme suit :

Linux :

 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"

Windows :

  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: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

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

Données des fichiers

Un collecteur de fichiers est conçu pour extraire les journaux d'un fichier lié au conteneur Docker. Vous pouvez l'utiliser si vous souhaitez importer manuellement des journaux à partir d'un seul fichier journal.

Démarrez le transmetteur Google SecOps à partir du conteneur Docker pour mapper le volume de charge au conteneur :

Linux

     docker run 

       --detach 

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

Windows

  docker run `
    --name cfps `
    --log-opt max-size=100m `
    --log-opt max-file=10 `
    -p 10514:10514 `
    -v c:/opt/chronicle/config:c:/opt/chronicle/external `
    -v c:/var/log/crowdstrike/falconhostclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable_windows

Vous pouvez ajouter plusieurs ports à l'aide de plusieurs options ou plages. Par exemple, -p 3001:3000 -p 2023:2022 ou -p 7000-8000:7000-8000. Les numéros de port fournis dans l'exemple de code sont des exemples. Remplacez les numéros de port selon vos besoins.

En vous basant sur l'exemple, vous pouvez modifier la configuration du redirecteur Google SecOps (fichier FORWARDER_NAME.conf) comme suit :

Linux

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:

Windows

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

Le fichier sample.txt doit être présent dans le dossier /var/log/crowdstrike/falconhostclient.

Configurations des indicateurs

skip_seek_to_end (bool) : cette option est définie sur false par défaut, et l'entrée de fichier n'envoie que les nouvelles lignes de journaux en entrée. Si vous définissez cette valeur sur true, toutes les lignes de journaux précédentes seront renvoyées lors des redémarrages du transmetteur. Cela entraîne 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 les lignes de journaux manquantes.

poll (bool) : le collecteur de fichiers utilise la bibliothèque Tail pour vérifier les modifications apportées au système de fichiers. En définissant ce flag sur true, la bibliothèque Tail utilise la méthode d'interrogation au lieu de la méthode de notification par défaut.

Données de paquets

Le transmetteur Google SecOps peut capturer des paquets au lieu d'entrées de journal, directement à partir d'une interface réseau.

Systèmes Linux

Le redirecteur Google SecOps peut capturer des paquets à l'aide de libcap sur Linux. Pour en savoir plus sur libcap, consultez la page de manuel libcap pour Linux.

Au lieu d'entrées de journaux, les paquets réseau bruts sont capturés et envoyés à Google SecOps. Cette capture est limitée à une interface locale. Pour activer la capture de paquets pour votre système, contactez l'assistance Google SecOps.

Google SecOps configure le redirecteur Google SecOps avec l'expression Berkeley Packet Filter (BPF) utilisée lors de la capture de paquets (par exemple, le port 53 et non localhost). Pour en savoir plus, consultez Filtres de paquets Berkeley.

Systèmes Windows

Le transmetteur Google SecOps peut capturer des paquets à l'aide de Npcap sur les systèmes Windows.

Au lieu d'entrées de journaux, les paquets réseau bruts sont capturés et envoyés à Google SecOps. Cette capture est limitée à une interface locale. Pour configurer votre redirecteur Google SecOps pour la capture de paquets, contactez l'assistance Google SecOps.

Conditions requises pour un transmetteur PCAP de capture de paquets :

• Installez Npcap sur l'hôte Microsoft Windows.

• Accordez à l'agent de transfert Google SecOps des droits root ou d'administrateur pour surveiller l'interface réseau.

• Lors de l'installation de Npcap, activez le mode de compatibilité WinPcap.

Pour configurer un redirecteur PCAP, Google Cloud a besoin du GUID de l'interface utilisée pour capturer les paquets. Exécutez getmac.exe sur la machine sur laquelle vous prévoyez d'installer le redirecteur Google SecOps (serveur ou machine à l'écoute sur le port de span), puis envoyez le résultat à Google SecOps.

Vous pouvez également modifier le fichier de configuration. Localisez la section PCAP et remplacez la valeur GUID existante par le GUID obtenu en exécutant getmac.exe.

Par exemple, voici une section PCAP d'origine :

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{1A7E7C8B-DD7B-4E13-9637-0437AB1A12FE}
      bpf: udp port 53

Sortie de l'exécution de getmac.exe :

C:\>getmac.exe
  Physical Address    Transport Name
  ===========================================================================
  A4-73-9F-ED-E1-82   \Device\Tcpip_{2E0E9440-ABFF-4E5B-B43C-E188FCAD1234}

Section "PCAP" révisée avec le nouveau GUID :

- pcap:
      common:
        enabled: true
        data_type: PCAP_DNS
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
      bpf: udp port 53

La sortie getmac.exe pour le nom du transport commence par \Device\Tcpip, tandis que la section pcap comparable commence par \Device\NPF.

Données du sujet Kafka

Le transmetteur Google SecOps permet d'ingérer des données directement à partir de sujets Kafka. Vous pouvez déployer jusqu'à trois répartiteurs et extraire des données du même sujet Kafka en tirant parti du concept de groupes de consommateurs pour un traitement efficace et parallèle. Pour en savoir plus, consultez Kafka. Pour en savoir plus sur les groupes de consommateurs Kafka, consultez Consommateur Kafka.

La configuration du redirecteur suivante montre comment configurer le redirecteur pour ingérer les données des thèmes Kafka.

Linux

Le 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
   

Le fichier FORWARDER_NAME_auth.conf

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

Windows

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: "c:/path/to/cert.pem"
        certificate_key: "c:/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:

Données WebProxy

Le transmetteur Google SecOps peut capturer les données WebProxy directement à partir d'une interface réseau.

Linux

Le transmetteur Google SecOps peut capturer les données WebProxy à l'aide de libcap sur Linux. Pour en savoir plus sur libcap, consultez la page de manuel libcap pour Linux. Pour activer la capture de données WebProxy pour votre système, contactez l'assistance Google SecOps.

Modifiez la configuration du redirecteur Google SecOps (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

Windows

Le redirecteur peut capturer les données WebProxy à l'aide de Npcap et les envoyer à Google Cloud.

Pour activer la capture de données WebProxy pour votre système, contactez l'assistance Google SecOps.

Avant d'exécuter un transmetteur WebProxy, procédez comme suit :

1. Installez Npcap sur l'hôte Microsoft Windows. Activez le mode de compatibilité WinPcap lors de l'installation.

2. Accordez des droits root ou d'administrateur au redirecteur pour surveiller l'interface réseau.

3. Obtenez le GUID de l'interface utilisée pour capturer les paquets WebProxy.

   Exécutez getmac.exe sur la machine sur laquelle vous souhaitez installer le transmetteur Google SecOps et envoyez la sortie à Google SecOps. Vous pouvez également modifier le fichier de configuration. Recherchez la section "WebProxy" et remplacez le GUID affiché à côté de l'interface par celui qui s'affiche après l'exécution de getmac.exe.

   Modifiez le fichier de configuration du redirecteur Google SecOps (FORWARDER_NAME.conf) comme suit :

     - webproxy:
       common:
           enabled : true
           data_type: <Your LogType>
           batch_n_seconds: 10
           batch_n_bytes: 1048576
         interface: \Device\NPF_{2E0E9440-ABFF-4E5B-B43C-E188FCAD9734}
         bpf: tcp and dst port 80
   

Configurer les attributs clés dans le fichier de configuration

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

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

Compression des données

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. Évaluez le compromis en fonction de votre environnement et des données de journaux.

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

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

Le fichier FORWARDER_NAME_auth.conf

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

Mise en mémoire tampon sur disque

La mise en mémoire tampon sur disque vous permet de mettre en mémoire tampon les messages en attente sur le disque plutôt que dans la mémoire.

Vous pouvez configurer la mise en mémoire tampon automatique pour utiliser un tampon partagé de manière dynamique entre les collecteurs, ce qui permet de mieux gérer les pics de trafic. Pour activer le tampon partagé de manière dynamique, ajoutez les éléments suivants à la configuration de votre transmetteur :

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 transmetteur à l'aide de Docker, nous vous recommandons de monter un volume distinct de votre volume de configuration à des fins d'isolation. De plus, chaque entrée doit être isolée dans son propre répertoire ou volume pour éviter les conflits.

Exemple de configuration

La configuration suivante inclut la syntaxe permettant d'activer la mise en mémoire tampon sur 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

Filtres d'expressions régulières

Les filtres d'expressions régulières vous permettent de filtrer les journaux en faisant correspondre des modèles aux données brutes des journaux. Les filtres utilisent la syntaxe RE2. 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 block. Vous pouvez spécifier des filtres avec le comportement allow. Si vous spécifiez un filtre allow, le transmetteur bloque tous les journaux qui ne correspondent pas à au moins un filtre allow.

Vous pouvez définir un nombre arbitraire de filtres. Les filtres Block sont prioritaires par rapport aux filtres allow.

Lorsque des filtres sont définis, ils doivent être associés à un nom. Les noms des filtres actifs seront communiqués à Google SecOps via les métriques sur l'état du redirecteur. 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 sont prioritaires en cas de noms conflictuels. Si aucun filtre n'est défini au niveau de la racine ou du collecteur, le comportement consiste à autoriser tous les journaux.

Exemple de configuration

Dans la configuration de transfert 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 la priorité est comprise entre 0 et 99. Toutefois, tous les journaux NIX_SYSTEM contenant "foo" ou "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

Libellés arbitraires

Les libellés permettent d'associer des métadonnées personnalisées aux journaux à l'aide de paires clé/valeur. Vous pouvez configurer des libellés pour un transmetteur entier ou dans un collecteur spécifique du transmetteur. Si les deux sont présents, les libellés au niveau du collecteur remplacent ceux au niveau du transmetteur si les clés se chevauchent.

Exemple de configuration

Dans la configuration de transfert suivante, les paires clé/valeur "foo=bar" et "meow=mix" sont toutes deux associées aux journaux WINEVTLOG, et 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

Espaces de noms

Vous pouvez utiliser des libellés d'espace de noms pour identifier les journaux provenant de segments de réseau distincts et résoudre les conflits d'adresses IP qui se chevauchent. Tout espace de noms configuré pour le redirecteur s'affiche avec les composants associés dans l'interface utilisateur Google SecOps. Vous pouvez également rechercher des espaces de noms à l'aide de la fonctionnalité Recherche SecOps de Google.

Pour savoir comment afficher les espaces de noms dans l'interface utilisateur Google SecOps, consultez Espaces de noms des composants.

Exemple de configuration

Dans la configuration de transfert 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

Options d'équilibrage de charge et de haute disponibilité

Vous pouvez configurer le serveur HTTP, l'équilibrage de charge et les options de haute disponibilité dans la section "server" du fichier de configuration du transmetteur. 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 de santé reçues dans les déploiements basés sur l'orchestration et le planificateur de conteneurs, ainsi que depuis les équilibreurs de charge.

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

• http://<host:port>/meta/available : vérifications de l'activité pour les planificateurs ou orchestrateurs de conteneurs
• http://<host:port>/meta/ready : Vérifications de l'état de préparation et vérifications d'état 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

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.