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

Le redirecteur Google Security Operations 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 Security Operations.

Version 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 auriez 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 Analyseurs par défaut compatibles.
Processeur: deux processeurs suffisent pour gérer moins de 10 000 événements par seconde (EPS) au total pour tous les types de données. Si vous prévoyez d'envoyer plus de 10 000 EPS, quatre à six processeurs sont nécessaires.
Disque: 100 Mo d'espace disque sont suffisants, quelle que soit la quantité de données traitées par le redirecteur Google Security Operations. 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 lorsque vous configurez un redirecteur Google Security Operations, par exemple lorsque vous configurez 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, vous devez définir 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	europe-west12-malachiteingestion-pa.googleapis.com	443
TCP	me-central1-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 les 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 Security Operations avec un conteneur:

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

Suivez la procédure ci-dessous 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 liste aucun conteneur en cours d'exécution, l'installation réussit. Si Docker n'est pas installé correctement, une erreur s'affiche.

Pour en savoir plus, consultez Premiers pas: préparer des fenêtres pour les conteneurs.

Pour les déploiements d'entreprise, installez l'environnement d'exécution de conteneurs Mirantis, é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 du redirecteur via l'interface utilisateur Google Security Operations.

Lorsque vous configurez le redirecteur Google Security Operations, assurez-vous que tous les chemins qu'il contient commencent par le préfixe "c:".

Toutes les modifications apportées au fichier de configuration sont automatiquement appliquées par le redirecteur Google Security Operations 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 des données de 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 Docker précédentes. Dans l'exemple suivant, le nom du conteneur Docker est cfps.
```
docker stop cfps

docker rm cfps
```
Obtenez la dernière image Docker à partir de 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 de plusieurs 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 selon vos besoins.

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 en cours d'exécution, 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, de désinstaller ou de supprimer le redirecteur Google Security Operations.

Cette commande arrête le conteneur de redirecteur Google Security Operations:

  docker stop cfps

Cette commande supprime le conteneur de redirecteur Google Security Operations:

  docker rm cfps

Mettre à niveau le redirecteur Google Security Operations

Le redirecteur Google Security Operations 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 Google Security Operations pour ingérer différents types de données, lesquelles sont transférées à l'instance Google Security Operations.

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

Collecter des données Splunk

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

URL de l'API REST de Splunk (par exemple, https://10.0.113.15:8089).
Des requêtes Splunk afin 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 Security Operations. 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 transmettez 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 ligne:
```
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 où se trouvent les fichiers de configuration). Exemple :
```
cp creds.txt c:/opt/chronicle/config/creds.txt
```
Vérifiez que le fichier creds.txt se trouve au bon emplacement :
```
ls c:/opt/chronicle/config
```

Collecter des données syslog

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

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 Google Security Operations 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 à utiliser. Les exemples suivants illustrent la configuration de la cible rsyslog:

Trafic journal 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 vers le redirecteur Google Security Operations. Dans le fichier de configuration du redirecteur Google Security Operations (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 affiché, 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 TLS minimale doit correspondre à l'une des valeurs suivantes: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

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

Collecter les données des fichiers

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

Utilisez cette option si vous souhaitez importer manuellement des journaux à partir d'un seul fichier journal. Cela peut servir à remplir les journaux d'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 de plusieurs 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 Security Operations (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 du fichier n'envoie que les nouvelles lignes de journal en entrée. Si cette règle est définie sur true, toutes les lignes de journal précédentes sont à nouveau envoyées lors des redémarrages du redirecteur. Cela entraîne la duplication des journaux. Il est utile de définir cette option sur true 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. Si cette option est définie 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 Google Security Operations 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 Google Security Operations pour mettre à jour votre fichier de configuration du redirecteur Google Security Operations afin de permettre 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 redirecteur Google Security Operations des droits d'administrateur ou des droits racine pour surveiller l'interface réseau.
Aucune option de ligne de commande n'est nécessaire.
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 Security Operations (le serveur ou la machine à l'écoute sur le port span) et envoyez la sortie à Google Security Operations.

Vous pouvez également modifier le fichier de configuration. Recherchez la section PCAP et remplacez la valeur GUID affichée à côté de l'interface par le GUID affiché lors de l'exécution de getmac.exe.

Par exemple, voici une section PCAP originale:

- 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 des données à partir du sujet Kafka

Vous pouvez ingérer des données des sujets Kafka comme vous le feriez dans syslog. Les groupes de consommateurs vous permettent de déployer jusqu'à trois redirecteurs Google Security Operations et d'extraire des données du même sujet Kafka. Pour en savoir plus, consultez Kafka.

Pour en savoir plus sur les groupes de consommateurs Kafka, consultez les 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 les données WebProxy

Le redirecteur Google Security Operations peut capturer des 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 Google Security Operations.

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 pour 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 Google Security Operations, puis envoyez le résultat à Google Security Operations. Vous pouvez également modifier le fichier de configuration. Recherchez la section "WebProxy" et remplacez le GUID affiché à côté de l'interface par le GUID affiché après l'exécution de getmac.exe.

Modifiez le fichier de configuration du redirecteur Google Security Operations (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 journaux 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 cumulé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 cumulé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`, 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 au terme desquelles 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 redirecteur et Champs de configuration du collecteur.

Activer/Désactiver la compression des données

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

Par exemple, les journaux textuels sont bien compressés et peuvent permettre de réduire considérablement la bande passante tout en utilisant peu le processeur. Cependant, les charges utiles chiffrées des paquets bruts ne sont pas bien 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, activer la compression des journaux peut également augmenter l'utilisation du processeur. Soyez conscient du compromis.

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

La mise en mémoire tampon du disque vous permet de mettre en mémoire tampon les messages en attente sur le disque, par opposition à la mémoire. Les messages en attente peuvent être stockés en cas de plantage du redirecteur Google Security Operations ou 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 du disque 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 dans la configuration du redirecteur:

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 recommande d'installer 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 volume pour éviter les conflits.

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

La configuration suivante inclut une 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'expression régulière

Les filtres d'expression régulière vous permettent de filtrer les journaux en fonction de correspondances d'expressions régulières par rapport aux 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 "block" (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 des filtres allow, le redirecteur Google Security Operations 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 signalés à Google Security Operations à l'aide des métriques d'état du redirecteur. 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, le comportement consiste à tout autoriser.

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

Dans la configuration suivante du redirecteur Google Security Operations, 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. Cependant, tous les journaux NIX_SYSTEM contenant "foo" ou "bar" sont bloqués, malgré l'erreur allow_filter. En effet, les filtres utilisent un opérateur logique OU. 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 étiquettes peuvent être configurées pour l'intégralité d'un redirecteur Google Security Operations ou dans un collecteur spécifique d'un redirecteur Google Security Operations. Si les deux sont fournis, les libellés sont fusionnés avec les clés du collecteur et prévalent sur les clés du redirecteur Google Security Operations en cas de chevauchement des clés.

Exemple de configuration: étiquettes arbitraires

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

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

Configurer des espaces de noms

Utilisez des étiquettes d'espace de noms pour identifier les journaux provenant de segments réseau distincts et éliminer les conflits d'adresses IP qui se chevauchent. Vous pouvez configurer une étiquette d'espace de noms pour l'intégralité d'un redirecteur Google Security Operations ou dans un collecteur spécifique du redirecteur Google Security Operations. 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 de Google Security Operations. 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 Google Security Operations, cliquez ici.

Exemple de configuration: espaces de noms

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

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

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

Le redirecteur Google Security Operations pour Windows sur Docker peut être déployé dans un environnement où un équilibreur de charge de couche 4 est installé entre la source de données et les instances du redirecteur Google Security Operations. Cela vous permet de répartir la collecte des journaux sur plusieurs redirecteurs Google Security Operations ou d'envoyer les journaux à un autre redirecteur Google Security Operations en cas de défaillance. Cette fonctionnalité n'est compatible qu'avec le type de collection syslog.

Le redirecteur Google Security Operations 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 les options de serveur HTTP, d'équilibrage de charge et de haute disponibilité dans la section server du fichier de configuration du redirecteur Google Security Operations. Ces options sont compatibles avec la définition des délais avant expiration et des codes d'état renvoyés en réponse aux vérifications d'état reçues dans les déploiements basés sur le planificateur de conteneurs et l'orchestration, ainsi que depuis 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 redirecteur Google Security Operations.

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

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

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

Chemin d'accès à la configuration	Description
server : Grace_timeout	Durée pendant laquelle le redirecteur Google Security Operations renvoie une vérification de l'état d'état ou de préparation incorrecte et accepte toujours de nouvelles connexions. C'est également le temps d'attente entre la réception d'un signal pour l'arrêt et le début réel de l'arrêt du serveur lui-même. Cela laisse à l'équilibreur de charge le temps de retirer le redirecteur Google Security Operations du pool.
serveur : drain_timeout	Durée pendant laquelle le redirecteur Google Security Operations attend que les connexions actives se ferment d'elles-mêmes avant d'être fermées par le serveur.
serveur : http : port	Numéro de port sur lequel le serveur HTTP écoute les vérifications d'état de l'équilibreur de charge. Doit être compris entre 1024 et 65 535.
serveur : 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).
serveur : http : read_timeout	Utilisé pour 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 à la fois read_timeout et read_header_timeout.
serveur : http : read_header_timeout	Utilisé pour 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ête. Le délai de lecture de la connexion est réinitialisé après la lecture de l'en-tête.
serveur : http : write_timeout	Utilisé pour 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 autorisé pour envoyer une réponse. Il est réinitialisé lorsqu'un nouvel en-tête de requête est lu.
serveur : http : inactif_timeout	Utilisé pour 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 de la requête suivante lorsque les connexions inactives sont activées. Si la valeur de "idle_timeout" est nulle, la valeur de read_timeout est utilisée. Si les deux valeurs sont égales à zéro, la valeur read_header_timeout est utilisée.
routes : meta : ready_status	Code d'état renvoyé par le redirecteur Google Security Operations 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 orchestrateur de conteneurs, tel que Kubernetes. La vérification de l'état provient d'un équilibreur de charge traditionnel.
routes : meta : unready_status	Code d'état renvoyé par le redirecteur Google Security Operations lorsqu'il n'est pas prêt à accepter le trafic.
routes : meta : available_status	Code d'état renvoyé par le redirecteur Google Security Operations lorsqu'une vérification d'activité est reçue et que le redirecteur Google Security Operations est disponible. Les programmeurs/orchestrateurs de conteneurs tels que Kubernetes envoient souvent des vérifications d'activité.