Le redirecteur Google Security Operations pour Linux

Ce document explique comment installer et configurer le redirecteur sous Linux. Pour installer le redirecteur sous Windows, consultez Gestionnaire Windows.

Le redirecteur permet d'envoyer des journaux depuis l'environnement client vers l'instance Google Security Operations. Elle est utilisée lorsque les clients souhaitent envoyer les journaux directement à Google Security Operations et ne souhaitent pas utiliser les buckets cloud pour ingérer des données, ou lorsque le type de journal n'a pas d'ingestion native via une API tierce. Le redirecteur peut être utilisé en tant que solution prête à être déployée, plutôt que d'incorporer manuellement l'API d'ingestion.

Vous pouvez installer le redirecteur sur diverses distributions Linux, y compris Debian, Ubuntu, Red Hat et Suse. Google Cloud fournit le logiciel à l'aide d'un conteneur Docker. Vous pouvez exécuter et gérer le conteneur Docker sur une machine physique ou virtuelle exécutant Linux.

Configuration requise

Vous trouverez ci-dessous des recommandations générales. Pour obtenir des recommandations spécifiques à votre système, contactez l'assistance Google Security Operations.

  • RAM : 1 Go pour chaque type de données collectées (collecteur) que Google Security Operations accepte pour l'ingestion Par exemple, si vous avez spécifié quatre collecteurs différents, vous avez besoin de 4 Go de RAM pour collecter les données de ces quatre collecteurs.

  • Processeur : deux processeurs suffisent pour gérer moins de 10 000 événements par seconde (EPS,total pour tous les types de données). Si vous prévoyez de transférer plus de 10 000 EPS, provisionnez quatre à six processeurs.

  • Disque : 100 Mo d'espace disque sont suffisants, quelle que soit la quantité de données traitées par le redirecteur Google Security Operations. Si vous devez mettre en mémoire tampon les messages en attente sur le disque plutôt que sur la mémoire, consultez la section Mise en mémoire tampon du disque. Par défaut, le redirecteur Google Security Operations effectue une mise en mémoire tampon.

Plages d'adresses IP utilisées par Google

Vous aurez peut-être besoin que la plage d'adresses IP s'ouvre lors de la mise en place d'une configuration du redirecteur, par exemple lorsque vous définissez 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

Tous les pare-feu ou proxys authentifiés situés entre le conteneur de redirecteur Google Security Operations et Internet nécessitent des règles pour autoriser l'accès aux hôtes 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

Personnaliser les fichiers de configuration

Google Cloud adapte les fichiers de configuration à l'instance du redirecteur avec des métadonnées spécifiques, comme indiqué dans la section des résultats. Vous pouvez télécharger le fichier de configuration selon vos besoins et inclure des informations sur les types de journaux à ingérer dans la section "Collecteurs". Pour en savoir plus sur les paramètres de configuration, consultez la documentation de référence sur les paramètres de configuration.

Configurer le redirecteur Linux

Pour configurer le redirecteur Linux via l'interface utilisateur, consultez Gérer les configurations du redirecteur via l'interface utilisateur Google SecOps.

Pour configurer manuellement le redirecteur Linux, procédez comme suit:

  1. Faites une copie du modèle de fichier de configuration fourni avec le logiciel.

  2. Téléchargez le fichier de configuration via l'interface utilisateur.

  3. Enregistrez les deux fichiers dans le même répertoire en utilisant 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.

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

  5. Assurez-vous qu'une entrée existe pour chaque entrée du fichier FORWARDER_NAME_auth.conf, même si l'entrée ne possède pas d'informations d'authentification correspondantes. Cela est nécessaire pour mapper correctement les données.

Les modifications apportées au fichier de configuration sont automatiquement appliquées par le redirecteur dans un délai de 5 minutes.

Exemple de configuration

L'exemple de code suivant montre le format des fichiers de configuration pour un redirecteur. Pour en savoir plus sur les paramètres de chaque type de mécanisme d'ingestion, tel que Splunk ou Syslog, consultez la section Collecter des données.

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"

Ce système à deux fichiers vous permet de stocker les identifiants d'authentification dans un fichier distinct pour plus de sécurité. Vous pouvez stocker le fichier FORWARDER_NAME.conf dans un dépôt de contrôle des versions ou dans tout système ouvert de gestion de configuration. Vous pouvez stocker le fichier FORWARDER_NAME_auth.conf directement dans la machine physique ou virtuelle exécutant le redirecteur.

Exemple de configuration (fichier unique)

output:
  url: malachiteingestion-pa.googleapis.com:443
  identity:
    identity:
    collector_id: "COLLECTOR_ID" \
    customer_id: "CUSTOMER_ID" \
    secret_key: |
      {
        "type": "service_account",
        "project_id": "PROJECT_ID" \,
        "private_key_id": "PRIVATE_KEY_ID" \,
        "private_key": "-----BEGIN PRIVATE KEY-----\ "PRIVATE_KEY" \n-----END PRIVATE KEY-----\n",
        "client_email": "CLIENT_EMAIL" \,
        "client_id": "CLIENT_ID" \,
        "auth_uri": "https://accounts.google.com/o/oauth2/auth",
        "token_uri": "https://oauth2.googleapis.com/token",
        "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
        "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/malachite-test-1%40malachite-test.iam.gserviceaccount.com"
      }

collectors:
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DHCP"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10514
      udp_address: 0.0.0.0:10514
      connection_timeout_sec: 60
      tcp_buffer_size: 524288
  - syslog:
      common:
        enabled: true
        data_type: "WINDOWS_DNS"
        data_hint:
        batch_n_seconds: 10
        batch_n_bytes: 1048576
      tcp_address: 0.0.0.0:10515
      connection_timeout_sec: 60
      certificate: "../forwarder/inputs/testdata/localhost.pem"
      certificate_key: "../forwarder/inputs/testdata/localhost.key"
      tcp_buffer_size: 524288

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

  1. Créez une copie de votre configuration existante.
  2. Enregistrez un fichier sous le nom FORWARDER_NAME.conf et supprimez les identifiants d'autorisation.
  3. Enregistrez l'autre fichier sous le nom FORWARDER_NAME_auth.conf et supprimez toutes les données de non-autorisation du fichier. Utilisez les exemples de fichiers de configuration fournis dans ce guide à titre de référence.
  4. Veillez à respecter la convention d'attribution de noms et les autres consignes mentionnées dans la section Personnaliser les fichiers de configuration.

Installer Docker

L'installation de Docker dépend de l'environnement hôte. Vous pouvez installer Docker sur différents systèmes d'exploitation hôtes. Google Cloud fournit une documentation limitée pour vous aider à installer Docker sur plusieurs des distributions Linux les plus courantes. Cependant, Docker est Open Source et toute la documentation nécessaire est déjà disponible. Pour obtenir des instructions d'installation de Docker, consultez la documentation Docker.

Une fois Docker installé sur votre système, le processus d'installation du redirecteur Google Security Operations est semblable à celui de n'importe quel type de distribution Linux.

Pour vérifier si Docker est correctement installé sur votre système, exécutez la commande suivante (droits d'accès élevés):

   docker ps
  

La réponse suivante indique que Docker a été installé correctement:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Commandes Docker utiles

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

    docker info
    
  • Le service Docker peut être désactivé par défaut. Pour vérifier s'il est désactivé, exécutez la commande suivante:

    systemctl is-enabled docker
    
  • Pour activer le service Docker et le démarrer immédiatement, exécutez l'une des commandes suivantes:

    sudo systemctl enable --now docker
    
    sudo systemctl enable /usr/lib/systemd/system/docker.service
    

    Résultat :

    Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service
    
  • Lorsque vous démarrez un redirecteur, exécutez la commande suivante pour le configurer afin qu'il redémarre automatiquement:

    sudo docker run --restart=always `IMAGE_NAME`
    

    IMAGE_NAME est le nom de l'image du redirecteur.

  • Pour vérifier l'état et les détails du service Docker, exécutez la commande suivante:

    sudo systemctl status docker
    

    Résultat :

    ● docker.service - Docker Application Container Engine
        Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
        Active: active (running) since Sat 2020-07-18 11:14:05 UTC; 15s ago
    TriggeredBy: ● docker.socket
          Docs: https://docs.docker.com
      Main PID: 263 (dockerd)
          Tasks: 20
        Memory: 100.4M
        CGroup: /system.slice/docker.service
                └─263 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
    Jul 18 11:14:05 swarm-kraken dockerd[263]: time="2020-07-18T11:14:05.713787002Z" level=info msg="API listen on /run/docker.sock"
    Jul 18 11:14:05 swarm-kraken systemd[1]: Started Docker Application Container Engine
    

    Si vous rencontrez des problèmes avec Docker, l'équipe d'assistance Google Security Operations peut demander le résultat de cette commande pour vous aider à résoudre le problème.

Installer le redirecteur sous Linux

Cette section explique comment installer le redirecteur Google Security Operations à l'aide d'un conteneur Docker sur un système Linux.

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

Google Security Operations fournit des fichiers de configuration du redirecteur spécifiques à votre système d'exploitation (Linux ou Windows). Vous pouvez télécharger le fichier de configuration selon vos besoins. Une fois les étapes suivantes effectuées, transférez les fichiers de configuration de votre ordinateur portable vers le répertoire /opt/chronicle/config du redirecteur, dans le répertoire d'accueil de l'utilisateur.

  1. Connectez-vous à l'hôte du redirecteur Linux via un terminal.

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

      adduser USERNAME
      passwd USERNAME
      usermod -aG wheel USERNAME
    

  3. Remplacez le répertoire par le répertoire d'accueil du nouvel utilisateur qui exécute le conteneur Docker.

  4. Créez un répertoire pour stocker les fichiers de configuration du redirecteur Google Security Operations :

      mkdir /opt/chronicle/config
    

  5. Changez de répertoire.

      cd /opt/chronicle/config
    

  6. Une fois les fichiers transférés, assurez-vous que les fichiers de configuration se trouvent dans le répertoire /opt/chronicle/config :

      ls -l
    

Étape 2. Exécuter le redirecteur dans le conteneur Docker

Vous pouvez utiliser les procédures suivantes pour démarrer le redirecteur Google Security Operations pour la première fois, ainsi que pour effectuer une mise à niveau vers la dernière version du conteneur Google Security Operations:

Les options --log-opt sont disponibles depuis Docker 1.13. Ces options limitent la taille des fichiers journaux du conteneur et doivent être utilisées tant que votre version de Docker les prend en charge.

  1. Si vous effectuez une mise à niveau, commencez par nettoyer toutes les exécutions Docker précédentes. Dans l'exemple suivant, le nom du conteneur Docker est cfps. Obtenez la dernière image Docker à partir de Google Cloud à l'aide de la commande docker pull, comme indiqué ci-dessous.

    docker stop cfps
    
    docker rm cfps
    
  2. Procurez-vous la dernière image Docker à partir de Google Cloud:

    docker pull gcr.io/chronicle-container/cf_production_stable
    
  3. 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    gcr.io/chronicle-container/cf_production_stable
    

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

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

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

    docker stop cfps
  

Pour supprimer le conteneur de redirecteur:

    docker rm cfps
  

Mettre à jour le redirecteur

Le redirecteur Google Security Operations se compose de deux parties et est mis à niveau comme suit:

  • Bundle du redirecteur : mise à jour automatique et sans redémarrage.

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

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.

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

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

  2. 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
    
  3. 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 /opt/chronicle/config/creds.txt
    
  4. Vérifiez que le fichier creds.txt se trouve au bon emplacement :

    ls /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 dispositif ou serveur compatible avec l'envoi de données syslog via une connexion TCP ou UDP pour transmettre leurs 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 au 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 "/opt/chronicle/external/certs/client_generated_cert.pem"
certificate_key "/opt/chronicle/external/certs/client_generated_cert.key"

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

Quelques points importants à noter:

  • 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. La connexion TCP est interrompue si elle est inactive pendant un certain temps.

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

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: /opt/chronicle/edr/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 libcap sous Linux. Pour plus d'informations sur libcap, consultez la page libcap – Manuel Linux.

Les paquets sont capturés et envoyés à Google Security Operations à la place des entrées de journal. La capture de paquets n'est gérée qu'à partir d'une interface locale. Pour activer la capture de paquets pour votre système, contactez l'assistance Google Security Operations.

Google Cloud configure le redirecteur Google Security Operations avec l'expression de filtre de paquets de Berkeley (BPF) utilisée lors de la capture de paquets (par exemple, sur le port 53 et non sur l'hôte local). Pour plus d'informations, consultez la page Filtres de paquets de Berkeley.

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 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 la page suivante : https://docs.confluent.io/platform/current/clients/consumer.html

Exemple de configuration: entrée Kafka

La configuration du redirecteur suivante montre comment configurer le redirecteur pour qu'il ingère les données des sujets Kafka.

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:

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 libcap sous Linux. Pour plus d'informations sur libcap, consultez la page libcap – Manuel Linux. Pour activer la capture de données WebProxy pour votre système, contactez l'assistance Google Security Operations.

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

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 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 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",
...
    }

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 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 utilise 1 Go de mémoire (RAM) pour chaque type de journal (par exemple, par 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 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 à 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
      # /buffers/NIX_SYSTEM is part of the external mounted volume for the
forwarder
      write_to_disk_dir_path: /buffers/NIX_SYSTEM
      max_file_buffer_bytes: 1073741824
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60

Définir des filtres d'expression régulière

Les filtres d'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 syntaxe RE2 décrite ici : https://github.com/google/re2/wiki/Syntax.

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 bloque tous les journaux qui ne correspondent pas à au moins un filtre allow.

Il est possible de définir un nombre arbitraire de filtres. Les filtres de 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 via les 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 du redirecteur 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 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 un redirecteur complet ou dans un collecteur spécifique d'un redirecteur. 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 en cas de chevauchement des clés.

Exemple de configuration: étiquettes arbitraires

Dans la configuration du redirecteur 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

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 un redirecteur complet ou dans un collecteur spécifique du redirecteur. Si les deux sont inclus, l'espace de noms du collecteur spécifique est prioritaire.

Tout espace de noms configuré pour le redirecteur 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 suivante, les journaux WINEVTLOG sont associés à l'espace de noms FORWARDER, et les journaux NIX_SYSTEM sont associés à l'espace de noms CORPORATE.

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

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

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

Le redirecteur Linux inclut un serveur HTTP intégré qui répond aux vérifications d'état HTTP provenant 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.

Configurez les options de serveur HTTP, d'équilibrage de charge et de haute disponibilité dans la section server du fichier de configuration du redirecteur. Ces options 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 traditionnels.

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.

  • http://<host:port>/meta/available: vérifications d'activité pour les planificateurs ou les orchestrateurs de conteneurs.
  • http://<host:port>/meta/ready: vérifications d'aptitude et vérifications d'état traditionnelles de l'équilibreur de charge.

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

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
Chemin d'accès à la configuration Description
server : Grace_timeout Durée pendant laquelle le redirecteur renvoie une vérification 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 du pool.
serveur : drain_timeout Durée pendant laquelle le redirecteur 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 lorsqu'il est prêt à accepter le trafic dans l'une des situations suivantes:
  • La vérification de l'aptitude est reçue de la part d'un programmeur ou d'un orchestrateur de conteneurs.
  • La vérification de l'état provient d'un équilibreur de charge traditionnel.
routes : meta : unready_status Code d'état renvoyé par le redirecteur lorsqu'il n'est pas prêt à accepter le trafic.
routes : meta : available_status Code d'état renvoyé par le redirecteur lorsqu'une vérification d'activité est reçue et que le redirecteur est disponible. Les planificateurs ou les orchestrateurs de conteneurs envoient souvent des vérifications de l'activité.

Questions fréquentes

Comment mettre à jour mon redirecteur ?

Le redirecteur Linux est constamment mis à jour via un script shell dans l'image Docker. Pour mettre à jour l'image Docker, exécutez le redirecteur.

Qu'est-ce qu'un conteneur Docker ?

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

  • Les machines virtuelles disposent à la fois d'un espace privilégié (noyau Linux) et d'un espace utilisateur (tous les éléments avec lesquels vous interagissez: libc, python, ls, tcpdump, etc.).

  • Conteneurs : ils ne disposent que d'un espace utilisateur (tous les éléments avec lesquels vous interagissez : libc, Python, ls, tcpdump, etc.) et dépendent de l'espace de privilèges de l'hôte.

Pourquoi distribuer le redirecteur Google Security Operations à l'aide d'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.
    • Un mécanisme de distribution de conteneurs existe déjà. Il peut être privé et distinct pour Google Cloud et les clients. https://cloud.google.com/container-registry/

Avez-vous besoin d'apprendre à utiliser des commandes Docker avancées ?

  • Le redirecteur Google Security Operations utilise un seul conteneur. Il n'est donc pas nécessaire d'en savoir plus sur Swarm, l'orchestration, ni sur les autres concepts ou commandes Docker avancés.