Gérer manuellement le fichier de configuration du forwarder

Compatible avec:

Cette page explique comment créer et modifier manuellement un fichier de configuration de transfert Google Security Operations. Pour configurer le forwarder via l'UI (recommandé), consultez la section Gérer les configurations du forwarder via l'UI Google SecOps.

Chaque forwarder Google SecOps déployé nécessite un fichier de configuration de forwarder. Un fichier de configuration de transfert spécifie les paramètres pour transférer les données vers votre instance Google SecOps.

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

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ées et les principaux attributs 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 via l'interface utilisateur.

  2. Enregistrez les deux fichiers dans le même répertoire en suivant 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 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 la section Définir des types de données dans votre fichier de configuration. Pour en savoir plus sur la personnalisation de chaque attribut, comme la compression de données ou la mise en mémoire tampon de disque, consultez la section Configurer les attributs clés dans le fichier de configuration.

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

Toutes les modifications apportées au fichier de configuration seront automatiquement appliquées par le transpondeur dans les 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 en deux parties 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 un système de gestion de configuration ouvert. Vous pouvez stocker le fichier FORWARDER_NAME_auth.conf directement sur la machine physique ou virtuelle exécutant le forwarder.

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

Le 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

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 dans un seul fichier

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

Convertir un fichier unique en 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 de fichier 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 de non-autorisation du fichier. Vous pouvez utiliser l'exemple de configuration pour référence. Veillez à 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 transpondeur Google SecOps pour ingérer différents types de données, qui sont transférés vers l'instance Google SecOps.

Données Splunk

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

  • Splunk interroge les données 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 forwarder 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 votre mot de passe sur la deuxième:

    cat creds.txt

myusername
mypassword

  3. Pour utiliser le forwarder Google SecOps pour accéder à une instance Splunk, copiez le fichier creds.txt dans le répertoire de configuration (le même répertoire que celui 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 forwarder 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 transférer ses données vers le transpondeur Google SecOps. Vous pouvez contrôler les données que le serveur envoie au transpondeur, qui peut ensuite les transmettre à Google SecOps.

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 transpondeur Google SecOps accepte à la fois les connexions TCP et UDP.

Vous pouvez personnaliser la taille du 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 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 de journalisation TCP: dns.* @@192.168.0.12:10514

  • Trafic de journalisation 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 transpondeur Google SecOps. Dans le fichier de configuration du forwarder (FORWARDER_NAME.conf), spécifiez l'emplacement de votre propre certificat et de votre clé de certificat, comme illustré 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 :

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

Windows :

certificat c:/opt/chronicle/external/certs/client_generated_cert.pem
certificate_key c:/opt/chronicle/external/certs/client_generated_cert.key

Sur la base de l'exemple présenté, modifiez le fichier de configuration du forwarder (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 correspondre à 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 associé au conteneur Docker. Vous pouvez l'utiliser si vous souhaitez importer manuellement des journaux à partir d'un seul fichier journal.

Démarrez le transpondeur Google SecOps à partir du conteneur Docker pour mapper le volume de charge sur le 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 de plusieurs 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.

Sur la base de l'exemple, vous pouvez modifier la configuration du forwarder 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 d'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 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 renvoyées lors des redémarrages du forwarder. Cela entraîne une 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 forwarder réenvoie les lignes de journal manquantes.

poll (bool): le collecteur de fichiers utilise la bibliothèque Tail pour rechercher toute modification 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.

Données de paquet

Le forwarder 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 sous Linux. Pour en savoir plus sur libcap, consultez la page libcap - Linux manual page.

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

Google Cloud configure le forwarder 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 la section Filtres de paquets Berkeley.

Systèmes Windows

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

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

Exigences concernant un forwarder PCAP de capture de paquets:

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

  • Accordez des droits d'administrateur ou d'utilisateur racine au forwarder Google SecOps pour surveiller l'interface réseau.

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

Pour configurer un transfert 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 forwarder Google SecOps (le serveur ou la machine à l'écoute sur le port span) et envoyez la sortie à Google SecOps.

Vous pouvez également modifier le fichier de configuration. Recherchez 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

Résultat 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 de transport commence par \Device\Tcpip, tandis que la section pcap comparable commence par \Device\NPF.

Données du sujet Kafka

Le transfert Google Security Operations permet d'ingérer des données directement à partir de sujets Kafka. Vous pouvez déployer jusqu'à trois transmetteurs et extraire des données du même sujet Kafka en exploitant le concept de groupes de consommateurs pour un traitement efficace et parallèle. Pour en savoir plus, consultez la section Kafka. Pour en savoir plus sur les groupes de consommateurs Kafka, consultez Consommateur Kafka.

La configuration du forwarder suivante montre comment configurer le forwarder pour qu'il ingère les données des sujets 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 transpondeur Google SecOps peut capturer des données WebProxy directement à partir d'une interface réseau.

Linux

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

Modifiez la configuration du forwarder 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 forwarder peut capturer les données WebProxy à l'aide de Npcap et les envoyer à Google Cloud.

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

Avant d'exécuter un transfert 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 racine ou d'administrateur au forwarder 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 transpondeur 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 affiché après l'exécution de getmac.exe.

    Modifiez le fichier de configuration du forwarder 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 de clé dans le fichier de configuration

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

Paramètre 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 de disque ou de fichier. La valeur par défaut est 1073741824, soit 1 Go.
max_memory_buffer_bytes Nombre maximal d'octets pouvant être accumulés dans le tampon de mémoire. La valeur par défaut est 1073741824, soit 1 Go.
write_to_disk_dir_path Chemin d'accès à utiliser pour le tampon de fichier ou de disque.
write_to_disk_buffer_enabled Si la valeur est true, la mémoire tampon de disque est utilisée au lieu de la mémoire 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 quoi les données sont groupé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 groupé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 une liste complète des paramètres utilisés dans le fichier de configuration, consultez les sections Champs de configuration du forwarder et Champs de configuration du collecteur.

Compression des données

Par défaut, la compression des journaux est désactivée. Activer 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 journal.

Pour activer la compression des journaux, définissez le champ compression sur true dans le fichier de configuration du forwarder Google SecOps, comme illustré 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 de disque

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

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é dynamiquement, ajoutez ce qui suit dans la configuration du forwarder:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Si vous exécutez le forwarder à 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 avec son propre répertoire ou son propre volume pour éviter les conflits.

Exemple de configuration

La configuration suivante inclut une syntaxe permettant d'activer la mise en mémoire tampon de 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'expression régulière vous permettent de filtrer les journaux en faisant correspondre des formats aux données de journal brutes. 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 d'une correspondance est block. Vous pouvez spécifier des filtres avec un comportement allow. Si vous spécifiez un filtre allow, le transpondeur 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 ont la priorité sur les filtres allow.

Lorsque vous définissez des filtres, vous devez leur attribuer un nom. Les noms des filtres actifs seront signalés à Google SecOps via les métriques de santé du transpondeur. 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 noms en conflit. Si aucun filtre n'est défini au niveau de la racine ou du collecteur, tous les journaux sont autorisés.

Exemple de configuration

Dans la configuration du forwarder 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é 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 l'ensemble d'un forwarder ou dans un collecteur spécifique du forwarder. Si les deux sont présents, les libellés au niveau du collecteur remplacent les libellés au niveau du forwarder si les clés se chevauchent.

Exemple de configuration

Dans la configuration du forwarder 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 de segments réseau distincts et résoudre les conflits d'adresses IP qui se chevauchent. Tout espace de noms configuré pour le transpondeur s'affiche avec les composants associés dans l'interface utilisateur de Google SecOps. Vous pouvez également rechercher des espaces de noms à l'aide de la fonctionnalité de recherche Google SecOps.

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 du forwarder 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 forwarder. Ces options permettent de définir les durées de délai avant expiration et les codes d'état renvoyés en réponse aux vérifications de l'état reçues dans le planificateur de conteneurs et les déploiements basés sur l'orchestration, ainsi que par 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 forwarder.

  • 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 de préparation et vérifications d'état de l'équilibreur de charge

La configuration du forwarder 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 de configuration Description
server : graceful_timeout Durée pendant laquelle le forwarder renvoie une mauvaise vérification de l'état/de la préparation et accepte toujours de nouvelles connexions. Il s'agit également du délai d'attente 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 forwarder du pool.
server : drain_timeout Durée pendant laquelle le forwarder attend que les connexions actives se ferment automatiquement avant d'être fermées par le serveur.
server : 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 1 024 et 65 535.
server : http : host 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 le système local (0.0.0.0).
server : http : read_timeout Permet d'ajuster 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 à la fois read_timeout et read_header_timeout.
server : http : read_header_timeout Permet d'ajuster 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ête. La limite de délai de lecture de la connexion est réinitialisée après la lecture de l'en-tête.
server : http : write_timeout Permet d'ajuster 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. Il est réinitialisé lorsqu'un nouvel en-tête de requête est lu.
server : http : idle_timeout Permet d'ajuster 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 prochaine requête lorsque les connexions inactives sont activées. Si idle_timeout est nul, la valeur de read_timeout est utilisée. Si les deux sont nuls, read_header_timeout est utilisé.
routes : meta : ready_status Code d'état renvoyé par le transpondeur lorsqu'il est prêt à accepter le trafic dans l'une des situations suivantes:
  • La vérification de la préparation est reçue d'un planificateur ou d'un orchestrateur de conteneurs.
  • La vérification de l'état est reçue d'un équilibreur de charge classique.
routes : meta : unready_status Code d'état renvoyé par le forwarder lorsqu'il n'est pas prêt à accepter le trafic.
routes : meta : available_status Code d'état renvoyé par le transpondeur lorsqu'une vérification d'activité est reçue et que le transpondeur est disponible. Les planificateurs ou orchestrateurs de conteneurs envoient souvent des vérifications de l'état.