Cette page a été traduite par l'API Cloud Translation.

Outil de transfert des opérations de sécurité Google pour Windows sur Docker

Ce document explique comment installer et configurer le redirecteur Google Security Operations pour Windows sur Docker.

Configuration requise

Vous trouverez ci-dessous des recommandations générales. Pour obtenir des recommandations spécifiques à votre système, contactez l'assistance Google chargée des opérations de sécurité.

Version de Windows Server: le redirecteur Google Security Operations est compatible avec Microsoft Windows Server 2022.
RAM: 1,5 Go pour chaque type de journal collecté. Par exemple, la détection et la réponse des points de terminaison (EDR), le DNS et le DHCP sont tous des types de journaux distincts. Vous aurez besoin de 4,5 Go de RAM pour collecter des données pour les trois. Pour obtenir la liste des analyseurs et des types de journaux par défaut compatibles, consultez la page Analyseurs par défaut compatibles.
Processeur: deux processeurs suffisent pour gérer moins de 10 000 événements par seconde (EPS) au total sur tous les types de données. Si vous prévoyez d'envoyer plus de 10 000 EPS, 4 à 6 processeurs sont nécessaires.
Disque: 100 Mo d'espace disque suffisent, quelle que soit la quantité de données traitées par le redirecteur d'opérations de sécurité Google. Vous pouvez mettre le disque en mémoire tampon en ajoutant les paramètres write_to_disk_buffer_enabled et write_to_disk_dir_path dans le fichier de configuration.

Exemple :
```
- <collector>:
     common:
         ...
         write_to_disk_buffer_enabled: true
         write_to_disk_dir_path: directory_path 
         ...
```

Plages d'adresses IP utilisées par Google

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

Vérifier la configuration du pare-feu

Si vous disposez de pare-feu ou de proxys authentifiés entre le conteneur de redirecteur Google Security Operations et Internet, ils exigent des règles pour autoriser l'accès aux hôtes Google Cloud suivants:

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

Pour vérifier la connectivité réseau à Google Cloud, procédez comme suit:

Démarrez Windows PowerShell avec des droits d'administrateur (cliquez sur Démarrer, saisissez PowerShell, effectuez un clic droit sur Windows PowerShell, puis cliquez sur Exécuter en tant qu'administrateur).

Exécutez la commande suivante :

C:\> test-netconnection <host> -port <port>

La commande renvoie que TcpTestSucceeded est true.

Exemple :

C:\> test-netconnection malachiteingestion-pa.googleapis.com -port 443
ComputerName     :  malachiteingestion-pa.googleapis.com
RemoteAddress    : 198.51.100.1
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 203.0.113.1
TcpTestSucceeded : True

Installer Docker sous Microsoft Windows

Cette section explique comment installer Docker sous Microsoft Windows à l'aide de l'interface de ligne de commande et de PowerShell.

Avantages du redirecteur Google pour les opérations de sécurité utilisant un conteneur:

Renforcer la sécurité grâce à l'isolation :
- L'environnement et les exigences du client n'affectent pas le redirecteur d'opérations de sécurité Google.
- Les exigences et l'environnement du redirecteur Google pour les opérations de sécurité n'affectent pas le client.
- Le mécanisme de distribution des conteneurs existe déjà. Il peut être privé et distinct pour Google Cloud et les clients. Pour en savoir plus, consultez la page Artifact Registry.

Procédez comme suit sur Microsoft Windows Server Core 2022.

Activez la fonctionnalité de conteneur Microsoft Windows.
```
Install-WindowsFeature containers -Restart
```

Exécutez la commande suivante en mode Administrateur PowerShell pour installer Docker CE:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/Windows-Containers/Main/helpful_tools/Install-DockerCE/install-docker-ce.ps1" -o install-docker-ce.ps1

.\install-docker-ce.ps1

Testez l'interface de ligne de commande Docker en exécutant la commande docker ps, qui renvoie la liste des conteneurs en cours d'exécution. Si la commande ne répertorie aucun conteneur en cours d'exécution, l'installation est réussie. Si Docker n'est pas installé correctement, une erreur s'affiche.

Pour en savoir plus, consultez le guide Premiers pas: Fenêtres de préparation pour les conteneurs.

Pour les déploiements d'entreprise, installez Mirantis Container Runtime, également appelé Docker EE.

Configurer le redirecteur Google Security Operations

Pour configurer le redirecteur Google Security Operations pour Windows sur Docker, consultez Gérer les configurations de redirecteur via l'interface utilisateur des opérations de sécurité Google.

Lorsque vous configurez le redirecteur Google pour les opérations de sécurité, assurez-vous que tous les chemins qu'il contient commencent par le préfixe "c:".

Toute modification apportée au fichier de configuration sera automatiquement appliquée par le redirecteur des opérations de sécurité Google dans un délai de cinq minutes.

Pour collecter des données de paquets à l'aide du redirecteur Google Security Operations pour Windows sur Docker, consultez la section Collecter les données des paquets.

Exécuter le redirecteur Google Security Operations dans le conteneur Docker

Si vous mettez à niveau le redirecteur Google Security Operations, commencez par nettoyer les exécutions précédentes de Docker. Dans l'exemple suivant, le nom du conteneur Docker est cfps.
```
docker stop cfps

docker rm cfps
```
Obtenez la dernière image Docker sur Google Cloud à l'aide de cette commande Docker pull.
```
docker pull gcr.io/chronicle-container/cf_production_stable_windows
```
Démarrez le redirecteur Google Security Operations à partir du conteneur Docker.
```
docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
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.

Remarque :Les numéros de port fournis dans l'exemple de code sont des exemples. Vous devez remplacer les numéros de port conformément à vos exigences.

Afficher les journaux du redirecteur

Pour afficher les journaux du redirecteur Google Security Operations, exécutez la commande suivante:

  sudo docker logs cfps

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

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

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

  sudo docker logs cfps -f

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

  sudo docker logs cfps &> logs.txt

Désinstaller le redirecteur Google Security Operations

Les commandes Docker suivantes vous permettent d'arrêter et de désinstaller ou de supprimer le redirecteur Google Security Operations.

Cette commande arrête le conteneur de redirecteur des opérations de sécurité Google:

  docker stop cfps

Cette commande supprime le conteneur de redirecteur Google Security Operations:

  docker rm cfps

Mettre à niveau le redirecteur Google pour les opérations de sécurité

Le redirecteur des opérations de sécurité Google pour Windows sur Docker est constamment mis à jour à l'aide d'un script shell dans l'image Docker. Il n'est donc pas nécessaire de fournir un exécutable pour cela.

Collecte des données

Les sections suivantes vous aident à configurer le redirecteur Opérations de sécurité Google pour qu'il ingère différents types de données, qui sont transférées à l'instance Opérations de sécurité Google.

Ne configurez pas de valeur supérieure à 1 Mo pour batch_n_bytes. Si vous configurez une valeur supérieure à 1 Mo, la valeur sera automatiquement réinitialisée à 1 Mo.

Collecter les données Splunk

Vous pouvez configurer le redirecteur des opérations de sécurité Google pour qu'il transfère vos données Splunk à la suite d'opérations de sécurité Google. Google Cloud configure le redirecteur des opérations de sécurité Google 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).
Les requêtes Splunk pour générer des données pour chacun des types de données requis (par exemple, index=dns)

FORWARDER_NAME.conf
output:
collectors:
  - splunk:
      common:
        enabled: true
        data_type: WINDOWS_DNS
        data_hint: "#fields ts      uid     id.orig_h       id.orig_p       id.resp_h         id.resp_p       proto   trans_id        query   qclass  qclass_name"
        batch_n_seconds: 10
        batch_n_bytes: 819200
      url: https://127.0.0.1:8089
      is_ignore_cert: true
      minimum_window_size: 10s
      maximum_window_size: 30s
      query_string: search index=* sourcetype=dns
      query_mode: realtime

Mettez vos identifiants de compte Splunk à la disposition du redirecteur d'opérations de sécurité Google. Pour ce faire, créez un fichier creds.txt.

Pour utiliser un fichier creds.txt:

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

Remarque :Assurez-vous que les identifiants sont stockés de manière sécurisée. Ne transférez pas vos identifiants Splunk à Google Cloud.
Indiquez votre nom d'utilisateur sur la première ligne et le mot de passe sur la deuxième:
```
cat creds.txt

myusername
mypassword
```
Pour utiliser le redirecteur Google Security Operations afin d'accéder à une instance Splunk, copiez le fichier creds.txt dans le répertoire de configuration (celui qui contient les fichiers de configuration). Exemple :
```
cp creds.txt c:/opt/chronicle/config/creds.txt
```
Vérifiez que le fichier creds.txt se trouve à son emplacement correct :
```
ls c:/opt/chronicle/config
```

Collecter des données syslog

Le redirecteur des opérations de sécurité Google peut faire office de 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 pour transférer ses données au redirecteur Opérations de sécurité Google. Vous pouvez contrôler les données exactes que le dispositif ou le serveur envoie au redirecteur Google Security Operations. Le redirecteur des opérations de sécurité Google peut alors transférer les données à la suite Opérations de sécurité Google.

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

Configurer rsyslog

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

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

Activer le protocole TLS pour les configurations syslog

Vous pouvez activer TLS pour la connexion syslog au redirecteur d'opérations de sécurité Google. Dans le fichier de configuration du système de transfert des opérations de sécurité Google (FORWARDER_NAME.conf), spécifiez l'emplacement du certificat et de la clé de certificat générés, comme indiqué dans l'exemple suivant:

certificat	`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 indiqué, modifiez le fichier de configuration du redirecteur Google Security Operations (FORWARDER_NAME.conf) comme suit:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "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"

Quelques points importants:

Vous pouvez configurer la taille de la mémoire tampon TCP. La taille de la mémoire tampon TCP par défaut est de 64 Ko.
La valeur par défaut et recommandée pour connection_timeout est de 60 secondes. Si la connexion est inactive pendant un certain temps, la connexion TCP est interrompue.
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 ou TLSv1_3.

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

Collecter les données des fichiers

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

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

Démarrez le redirecteur Google Security Operations à partir du conteneur Docker:

  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/falconhoseclient:c:/opt/chronicle/edr `
     gcr.io/chronicle-container/cf_production_stable

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.

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 Google Opérations de sécurité (fichier FORWARDER_NAME.conf) comme suit. Le fichier sample.txt doit être présent dans le dossier /var/log/crowdstrike/falconhostclient.

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

Configurations d'indicateurs

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

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

Collecter les données des paquets

Le redirecteur des opérations de sécurité Google peut capturer des paquets directement à partir d'une interface réseau à l'aide de Npcap sur les systèmes Windows.

Les paquets sont capturés et envoyés à Google Cloud à la place des entrées de journal. La capture s'effectue uniquement à partir d'une interface locale.

Contactez l'assistance Opérations de sécurité Google pour mettre à jour le fichier de configuration du redirecteur Google d'opérations de sécurité afin qu'il accepte la capture de paquets.

Pour exécuter un redirecteur de capture de paquets (PCAP), vous avez besoin des éléments suivants:

Installez Npcap sur l'hôte Microsoft Windows.
Accordez au système de transfert Google des opérations de sécurité des droits racine ou d'administrateur pour surveiller l'interface réseau.
Aucune option de ligne de commande n'est nécessaire.
Sur l'installation 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 Security Operations (soit le serveur, soit la machine qui écoute le port span), puis envoyez le résultat à la suite Opérations de sécurité Google.

Vous pouvez également modifier le fichier de configuration. Localisez la section PCAP et remplacez la valeur GUID affichée à côté de l'interface avec le GUID affiché lors de l'exécution de 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

Voici le 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}

Et enfin, voici la 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

Collecter les données du sujet Kafka

Vous pouvez ingérer les données des sujets Kafka de la même manière que dans syslog. Les groupes grand public vous permettent de déployer jusqu'à trois redirecteurs d'opérations de sécurité Google 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 l'article Groupes de consommateurs Kafka.

Exemple de configuration: entrée Kafka

La configuration suivante du redirecteur Google Security Operations montre comment configurer le redirecteur Google Security Operations pour ingérer les données des sujets Kafka.

Fichier FORWARDER_NAME.conf

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      topic: example-topic
      group_id: chronicle-forwarder
      timeout: 60s
      brokers: ["broker-1:9092", "broker-2:9093"]
      tls:
        insecureSkipVerify: true
        certificate: "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:

Collecter des données WebProxy

Le redirecteur d'opérations de sécurité Google peut capturer les données WebProxy directement à partir d'une interface réseau à l'aide de Npcap et les envoyer à Google Cloud.

Pour activer la capture de données WebProxy pour votre système, contactez l'assistance dédiée aux opérations de sécurité Google.

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

Installez Npcap sur l'hôte Microsoft Windows. Activez le mode de compatibilité WinPcap pendant l'installation.
Accordez des droits racine ou d'administrateur au redirecteur Google Security Operations afin de surveiller l'interface réseau.
Pour configurer un redirecteur WebProxy, Google Cloud a besoin du GUID de l'interface utilisée pour capturer les paquets WebProxy.

Exécutez getmac.exe sur la machine sur laquelle vous souhaitez installer le redirecteur d'opérations de sécurité Google et envoyez le résultat à la suite Opérations de sécurité Google. 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 redirecteur Google pour les opérations de sécurité (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
```

Personnaliser les configurations

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

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

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

Activer/Désactiver la compression des données

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

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

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

Pour activer la compression des journaux, définissez le champ compression sur true dans le fichier de configuration du redirecteur Google pour les opérations de sécurité, comme indiqué dans l'exemple suivant:

Fichier FORWARDER_NAME.conf

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

Le fichier FORWARDER_NAME_auth.conf

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

Configurer la mise en mémoire tampon sur le disque

La mise en mémoire tampon sur le disque vous permet de mettre en mémoire tampon les messages en attente sur le disque plutôt que sur la mémoire. Les messages en attente peuvent être stockés en cas de plantage du redirecteur d'opérations de sécurité Google ou de plantage de l'hôte sous-jacent. 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 Google Security Operations utilise 1 Go de mémoire (RAM) pour chaque type de journal (par exemple, pour chaque connecteur). Spécifiez le paramètre de configuration max_memory_buffer_bytes. La mémoire maximale autorisée est de 4 Go.

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

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

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

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

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

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

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

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

Les filtres utilisent la syntax 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 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 des opérations de sécurité Google bloque tous les journaux qui ne correspondent à aucun filtre allow.

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

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

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

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

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

Configurer des étiquettes arbitraires

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

Exemple de configuration: étiquettes arbitraires

Dans la configuration suivante du redirecteur d'opérations de sécurité Google, 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

Configurer des espaces de noms

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

Tout espace de noms configuré pour le redirecteur Google Security Operations apparaît avec les éléments associés dans l'interface utilisateur des opérations de sécurité Google. Vous pouvez également rechercher des espaces de noms à l'aide de la fonctionnalité Google Security Operations Search.

Pour savoir comment afficher les espaces de noms dans l'interface utilisateur de la suite Opérations de sécurité de Google, cliquez ici.

Exemple de configuration: espaces de noms

Dans la configuration suivante du redirecteur d'opérations de sécurité Google, 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 d'opérations de sécurité Google pour Windows sur Docker peut être déployé dans un environnement dans lequel un équilibreur de charge de couche 4 est installé entre la source de données et les instances de redirecteur des opérations de sécurité Google. Cela vous permet de répartir la collecte des journaux entre plusieurs redirecteurs d'opérations de sécurité Google ou d'envoyer les journaux à un autre redirecteur d'opérations de sécurité Google en cas d'échec. Cette fonctionnalité n'est compatible qu'avec le type de collection syslog.

Le redirecteur d'opérations de sécurité Google pour Windows sur Docker inclut un serveur HTTP intégré qui répond aux vérifications d'état HTTP de l'équilibreur de charge. Le serveur HTTP permet également de s'assurer que les journaux ne sont pas perdus lors du démarrage ou de l'arrêt d'un redirecteur Google Security Operations.

Configurez le serveur HTTP, l'équilibrage de charge et les options de haute disponibilité dans la section server du fichier de configuration du redirecteur Google Security Operations. 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 d'état reçues dans le planificateur de conteneurs et les déploiements basés sur l'orchestration, ainsi que dans les équilibreurs de charge classiques.

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 système de transfert des opérations de sécurité Google.

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

La configuration suivante du redirecteur Google pour les opérations de sécurité est un exemple d'équilibrage de charge et de haute disponibilité:

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503

Chemin d'accès à la configuration	Description
serveur : Grace_timeout	Durée pendant laquelle le redirecteur des opérations de sécurité Google renvoie une vérification d'aptitude/d'état insatisfaisante et accepte toujours de nouvelles connexions. C'est également le temps d'attente entre la réception d'un signal pour s'arrêter et le début réel de l'arrêt du serveur lui-même. Cela laisse à l'équilibreur de charge le temps de supprimer le redirecteur Google Security Operations du pool.
serveur : drain_timeout	Durée pendant laquelle le redirecteur des opérations de sécurité Google attend que les connexions actives se ferment spontanément avant d'être fermées par le serveur.
serveur : http : port	Numéro de port que le serveur HTTP écoute pour les vérifications d'état provenant de l'équilibreur de charge. Doit être comprise entre 1024 et 65 535.
serveur : http : hôte	Adresse IP, ou nom d'hôte pouvant être résolu en adresses IP, que le serveur doit écouter. Si ce champ est vide, la valeur par défaut est "local system" (0.0.0.0).
serveur : http : read_timeout	Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour lire l'intégralité de la requête, à la fois l'en-tête et le corps. Vous pouvez définir read_timeout et read_header_timeout.
serveur : http : read_header_timeout	Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour lire les en-têtes de requêtes. Le délai de lecture de la connexion est réinitialisé après la lecture de l'en-tête.
serveur : http : write_timeout	Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Durée maximale autorisée pour envoyer une réponse. Elle est réinitialisée lorsqu'un nouvel en-tête de requête est lu.
serveur : http : inactif_timeout	Permet de régler le serveur HTTP. En règle générale, il n'est pas nécessaire de modifier le paramètre par défaut. Délai maximal d'attente pour la requête suivante lorsque les connexions inactives sont activées. Si la valeur "idle_timeout" est nulle, la valeur de "read_timeout" est utilisée. Si les deux valeurs sont égales à zéro, read_header_timeout est utilisé.
routes : méta : ready_status	Code d'état renvoyé par le redirecteur des opérations de sécurité Google lorsqu'il est prêt à accepter le trafic dans l'une des situations suivantes: La vérification d'aptitude est reçue d'un programmeur ou d'un orchestre de conteneurs, tel que Kubernetes. La vérification de l'état est reçue par un équilibreur de charge traditionnel.
routes : méta : unready_status	Code d'état renvoyé par le redirecteur des opérations de sécurité Google lorsqu'il n'est pas prêt à accepter le trafic.
routes : méta : available_status	Code d'état renvoyé par le redirecteur des opérations de sécurité Google lorsqu'une vérification d'activité est reçue et que le redirecteur des opérations de sécurité Google est disponible. Les programmeurs/orchestrations de conteneurs tels que Kubernetes envoient souvent des vérifications d'activité.