Weiterleitungskonfigurationsdatei manuell verwalten

Unterstützt in:

Auf dieser Seite wird beschrieben, wie Sie eine Konfigurationsdatei für einen Google Security Operations-Weiterleiter manuell erstellen und ändern. Informationen zum Konfigurieren des Weiterleitungsservers über die Benutzeroberfläche (empfohlen) finden Sie unter Weiterleitungskonfigurationen über die Google SecOps-Benutzeroberfläche verwalten.

Für jeden bereitgestellten Google SecOps-Weiterleiter ist eine Konfigurationsdatei erforderlich. In einer Konfigurationsdatei für einen Weiterleiter werden die Einstellungen für die Übertragung der Daten an Ihre Google SecOps-Instanz angegeben.

Informationen zum Installieren und Konfigurieren des Google SecOps-Weiterleitungsservers, zu den Systemanforderungen und zu den Konfigurationseinstellungen finden Sie unter Weiterleitungsserver installieren und konfigurieren.

Hinweise

Bevor Sie die Konfigurationsdatei erstellen, planen Sie Ihre Implementierung. Informieren Sie sich über die Arten von Daten, die aufgenommen werden können, und die wichtigsten Attribute, die Sie in der Konfigurationsdatei definieren müssen.

Konfigurationsdatei erstellen

So erstellen Sie die Konfigurationsdatei manuell:

  1. Laden Sie die Konfigurationsdateien über die Benutzeroberfläche herunter.

  2. Speichern Sie die beiden Dateien im selben Verzeichnis und verwenden Sie dabei die folgende Benennungskonvention:

    FORWARDER_NAME.conf: In dieser Datei werden die Konfigurationseinstellungen für die Logaufnahme definiert.

    FORWARDER_NAME_auth.conf: In dieser Datei werden die Autorisierungsanmeldedaten definiert.

  3. Ändern Sie die Dateien so, dass sie die Konfiguration für Ihre Forwarder-Instanz enthalten.

    Details zu den Einstellungen für die einzelnen Datenaufnahmemechanismen wie Splunk oder Syslog finden Sie unter Datentypen in der Konfigurationsdatei definieren. Weitere Informationen zum Anpassen der einzelnen Attribute, z. B. zur Datenkomprimierung oder Festplattenpufferung, finden Sie unter Schlüsselattribute in der Konfigurationsdatei konfigurieren.

  4. Achten Sie darauf, dass für jede Eingabe in der Datei FORWARDER_NAME_auth.conf ein Eintrag vorhanden ist, auch wenn die Eingabe keine entsprechenden Authentifizierungsdetails enthält. Dies ist erforderlich, damit die Daten richtig zugeordnet werden können.

Alle Änderungen an der Konfigurationsdatei werden vom Weiterleiter innerhalb von fünf Minuten automatisch angewendet.

Beispielkonfigurationen

Sie können die folgenden Konfigurationsdateien als Vorlagen verwenden, um eigene zu erstellen.

Beispielkonfiguration mit zwei Dateien

Bei diesem Dateisystem werden Anmeldedaten aus Sicherheitsgründen in einer separaten Datei gespeichert. Sie können die Datei FORWARDER_NAME.conf in einem Versionskontroll-Repository oder einem beliebigen offenen Konfigurationsverwaltungssystem speichern. Sie können die Datei FORWARDER_NAME_auth.conf direkt auf der physischen oder virtuellen Maschine speichern, auf der der Weiterleiter ausgeführt wird.

Das folgende Codebeispiel zeigt das Format der Konfigurationsdateien für einen Weiterleiter.

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

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

Beispielkonfiguration mit einer einzelnen Datei

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

Von einem einzelnen Dateisystem in ein zwei Dateisysteme konvertieren

Wenn Sie eine einzelne Konfigurationsdatei verwenden und zum zwei Dateisystem wechseln möchten, gehen Sie so vor:

  1. Erstellen Sie eine Kopie der vorhandenen Konfigurationsdatei.

  2. Speichern Sie eine Datei als FORWARDER_NAME.conf und löschen Sie die Autorisierungsdaten aus der Datei.

  3. Speichern Sie die andere Datei als FORWARDER_NAME_auth.conf und löschen Sie alle nicht autorisierten Daten aus der Datei. Sie können die Beispielkonfiguration als Referenz verwenden. Beachten Sie die Namenskonvention und die anderen Richtlinien, die im Abschnitt Konfigurationen anpassen erwähnt werden.

Datentypen in der Konfigurationsdatei definieren

In den folgenden Abschnitten erfahren Sie, wie Sie den Google SecOps-Weiterleiter so konfigurieren, dass verschiedene Datentypen aufgenommen und an die Google SecOps-Instanz weitergeleitet werden.

Splunk-Daten

Sie können den Google SecOps-Weiterleiter so konfigurieren, dass Ihre Splunk-Daten an Google SecOps weitergeleitet werden. Google Cloud konfiguriert den Google SecOps-Weiterleiter mit den folgenden Informationen, um Ihre Daten aus Splunk weiterzuleiten:

  • URL für die Splunk REST API (z. B. https://10.0.113.15:8089).

  • Splunk-Abfragen zum Generieren von Daten für jeden der erforderlichen Datentypen (z. B. 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
  • Stellen Sie die Anmeldedaten für Ihr Splunk-Konto für den Google SecOps-Weiterleiter bereit. Erstellen Sie dazu eine creds.txt-Datei.

So verwenden Sie eine creds.txt-Datei:

  1. Erstellen Sie eine lokale Datei für Ihre Splunk-Anmeldedaten und nennen Sie sie creds.txt.

  2. Geben Sie Ihren Nutzernamen in die erste Zeile und das Passwort in die zweite Zeile ein:

    cat creds.txt

myusername
mypassword

  3. Wenn Sie den Google SecOps-Weiterleiter verwenden möchten, um auf eine Splunk-Instanz zuzugreifen, kopieren Sie die Datei creds.txt in das Konfigurationsverzeichnis (das Verzeichnis, in dem sich die Konfigurationsdateien befinden).

    Linux

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

    Windows

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

  4. Prüfen Sie, ob sich die Datei creds.txt im richtigen Verzeichnis befindet:

    Linux

      ls /opt/chronicle/config

    Windows

    ls c:/opt/chronicle/config

Syslog-Daten

Ein Weiterleiter kann als Syslog-Server verwendet werden. Sie können jeden Server konfigurieren, der das Senden von Syslog-Daten über eine TCP- oder UDP-Verbindung unterstützt, um die Daten an den Google SecOps-Weiterleiter weiterzuleiten. Sie können die Daten steuern, die der Server an den Weiterleiter sendet. Der Weiterleiter kann die Daten dann an Google SecOps weiterleiten.

In der FORWARDER_NAME.conf-Konfigurationsdatei (von Google Cloud bereitgestellt) wird angegeben, welche Ports für jeden Typ von weitergeleiteten Daten überwacht werden sollen (z. B. Port 10514). Standardmäßig akzeptiert der Google SecOps-Weiterleiter sowohl TCP- als auch UDP-Verbindungen.

Sie können die Größe des TCP-Puffers anpassen. Die Standardgröße des TCP-Puffers beträgt 64 KB. Der Standard- und empfohlene Wert für connection_timeout ist 60 Sekunden. Die TCP-Verbindung wird beendet, wenn sie länger als 60 Sekunden inaktiv ist.

rsyslog konfigurieren

Um rsyslog zu konfigurieren, müssen Sie für jeden Port ein Ziel angeben, z. B. für jeden Datentyp. Die folgenden Beispiele veranschaulichen die rsyslog-Zielkonfiguration:

  • TCP-Protokoll-Traffic: dns.* @@192.168.0.12:10514

  • UDP-Protokoll-Traffic: dns.* @192.168.0.12:10514

Weitere Informationen finden Sie in der Systemdokumentation.

TLS für Syslog-Konfigurationen aktivieren

Sie können TLS für die Syslog-Verbindung zum Google SecOps-Weiterleiter aktivieren. Geben Sie in der Konfigurationsdatei des Brokers (FORWARDER_NAME.conf) den Speicherort Ihres selbst generierten Zertifikats und Zertifikatsschlüssels an, wie im folgenden Beispiel gezeigt. Sie können im Verzeichnis configuration ein Verzeichnis certs erstellen und die Zertifikatdateien darin speichern.

Linux:

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

Windows:

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

Ändern Sie die Konfigurationsdatei des Brokers (FORWARDER_NAME.conf) anhand des Beispiels so:

Linux:

 collectors:
- syslog:
   common:
     enabled: true
     data_type: WINDOWS_DNS
     data_hint:
     batch_n_seconds: 10
     batch_n_bytes: 1048576
   tcp_address: 0.0.0.0:10515
   tcp_buffer_size: 65536
   connection_timeout_sec: 60
   certificate: "/opt/chronicle/external/certs/client_generated_cert.pem"
   certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
   minimum_tls_version: "TLSv1_3"

Windows:

  collectors:
- syslog:
    common:
      enabled: true
      data_type: WINDOWS_DNS
      data_hint:
      batch_n_seconds: 10
      batch_n_bytes: 1048576
    tcp_address: 0.0.0.0:10515
    tcp_buffer_size: 65536
    connection_timeout_sec: 60
    certificate: "c:/opt/chronicle/external/certs/client_generated_cert.pem"
    certificate_key: "c:/opt/chronicle/external/certs/client_generated_cert.key"
    minimum_tls_version: "TLSv1_3"

Die TLS-Version der Eingabeanfrage muss höher als die TLS-Mindestversion sein. Die Mindest-TLS-Version muss einer der folgenden Werte sein: TLSv1_0, TLSv1_1, TLSv1_2 oder TLSv1_3.

Dateidaten

Ein Datei-Collector ist für das Abrufen von Protokollen aus einer Datei konzipiert, die mit dem Docker-Container verknüpft ist. Sie können diese Option verwenden, wenn Sie Protokolle aus einer einzelnen Protokolldatei manuell hochladen möchten.

Starten Sie den Google SecOps-Weiterleiter aus dem Docker-Container, um das Ladevolumen dem Container zuzuordnen:

Linux

     docker run 

       --detach 

       --name cfps 

       --log-opt max-size=100m 

       --log-opt max-file=10 

       --net=host 

       -v /opt/chronicle/config:/opt/chronicle/external 

       -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr 

       gcr.io/chronicle-container/cf_production_stable

Windows

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

Sie können mehrere Ports mit mehreren Optionen oder mehreren Bereichen hinzufügen. Beispiel: -p 3001:3000 -p 2023:2022 oder -p 7000-8000:7000-8000. Die im Beispielcode angegebenen Portnummern sind Beispiele. Ersetzen Sie die Portnummern nach Bedarf.

Anhand des Beispiels können Sie die Konfiguration des Google SecOps-Weiterleitungsservers (FORWARDER_NAME.conf-Datei) so ändern:

Linux

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

Windows

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

Die Datei sample.txt muss sich im Ordner /var/log/crowdstrike/falconhostclient befinden.

Flag-Konfigurationen

skip_seek_to_end (bool): Dieses Flag ist standardmäßig auf false gesetzt und die Dateieingabe sendet nur neue Protokollzeilen als Eingabe. Wenn Sie diesen Wert auf true festlegen, werden beim Neustart des Brokers alle vorherigen Logzeilen noch einmal gesendet. Dies führt zu einer Log-Duplizierung. Das Festlegen dieses Flags auf true ist in bestimmten Situationen hilfreich, z. B. bei Ausfällen, da beim Neustart des Brokers die fehlenden Protokollzeilen noch einmal gesendet werden.

poll (bool): Der Datei-Collector verwendet die Tail-Bibliothek, um nach Änderungen im Dateisystem zu suchen. Wenn Sie dieses Flag auf true festlegen, verwendet die Tail-Bibliothek die Polling-Methode anstelle der Standard-Benachrichtigungsmethode.

Paketdaten

Der Google SecOps-Weiterleiter kann Pakete anstelle von Logeinträgen direkt von einer Netzwerkschnittstelle erfassen.

Linux-Systeme

Der Google SecOps-Weiterleiter kann Pakete mit libcap unter Linux erfassen. Weitere Informationen zu libcap finden Sie unter libcap – Linux-Manpage.

Anstelle von Logeinträgen werden Rohnetzwerkpakete erfasst und an Google Cloud gesendet. Diese Erfassung ist auf eine lokale Schnittstelle beschränkt. Wenn Sie die Paketerfassung für Ihr System aktivieren möchten, wenden Sie sich an den SecOps-Support von Google.

Google Cloud konfiguriert den Google SecOps-Weiterleiter mit dem Berkeley Packet Filter (BPF)-Ausdruck, der beim Erfassen von Paketen verwendet wird (z. B. Port 53 und nicht localhost). Weitere Informationen finden Sie unter Berkeley-Paketfilter.

Windows-Systeme

Der Google SecOps-Weiterleiter kann Pakete mit Npcap auf Windows-Systemen erfassen.

Anstelle von Logeinträgen werden Rohnetzwerkpakete erfasst und an Google Cloud gesendet. Diese Erfassung ist auf eine lokale Schnittstelle beschränkt. Wenn Sie Ihren Google SecOps-Weiterleiter für die Paketerfassung konfigurieren möchten, wenden Sie sich an den Google SecOps-Support.

Anforderungen an einen PCAP-Weiterleiter für die Paketerfassung:

  • Installieren Sie Npcap auf dem Microsoft Windows-Host.

  • Gewähren Sie dem Root- oder Administrator des Google SecOps-Weiterleitungsservers Berechtigungen zum Überwachen der Netzwerkschnittstelle.

  • Aktivieren Sie bei der Npcap-Installation den WinPcap-Kompatibilitätsmodus.

Zum Konfigurieren eines PCAP-Weiterleiters benötigt Google Cloud die GUID für die Schnittstelle, die zum Erfassen von Paketen verwendet wird. Führen Sie getmac.exe auf dem Computer aus, auf dem Sie den Google SecOps-Weiterleiter installieren möchten (entweder auf dem Server oder auf dem Computer, der den Spanning Tree Port überwacht), und senden Sie die Ausgabe an Google SecOps.

Alternativ können Sie die Konfigurationsdatei ändern. Suchen Sie den PCAP-Abschnitt und ersetzen Sie den vorhandenen GUID-Wert durch die GUID, die Sie durch Ausführen von getmac.exe erhalten haben.

Hier ist beispielsweise ein Original-PCAP-Abschnitt:

- 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

Ausgabe nach dem Ausführen von getmac.exe:

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

Überarbeiteter PCAP-Abschnitt mit der neuen 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

Die getmac.exe-Ausgabe für den Transportnamen beginnt mit \Device\Tcpip, während der vergleichbare pcap-Abschnitt mit \Device\NPF beginnt.

Daten aus dem Kafka-Thema

Der Google Security Operations-Weiterleiter unterstützt die Datenaufnahme direkt aus Kafka-Themen. Sie können bis zu drei Weiterleiter bereitstellen und Daten aus demselben Kafka-Thema abrufen, indem Sie das Konzept von Verbrauchergruppen für eine effiziente und parallele Verarbeitung nutzen. Weitere Informationen finden Sie unter Kafka. Weitere Informationen zu Kafka-Nutzergruppen finden Sie unter Kafka-Nutzer.

In der folgenden Weiterleitungskonfiguration wird gezeigt, wie Sie den Weiterleiter so einrichten, dass er Daten aus den Kafka-Themen aufnimmt.

Linux

Datei 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

Datei FORWARDER_NAME_auth.conf

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

Windows

FORWARDER_NAME.conf-Datei

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

Datei FORWARDER_NAME_auth.conf

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

WebProxy-Daten

Der Google SecOps-Weiterleiter kann Webproxy-Daten direkt über eine Netzwerkschnittstelle erfassen.

Linux

Der Google SecOps-Weiterleiter kann WebProxy-Daten mit libcap unter Linux erfassen. Weitere Informationen zu libcap finden Sie unter libcap – Linux-Manpage. Wenn Sie die Webproxy-Datenerhebung für Ihr System aktivieren möchten, wenden Sie sich an den Google SecOps-Support.

Ändern Sie die Konfiguration des Google SecOps-Weiterleitungsservers (FORWARDER_NAME.conf-Datei) folgendermaßen:

   - webproxy:
         common:
           enabled : true
           data_type: <Your LogType>
           batch_n_seconds: 10
           batch_n_bytes: 1048576
         interface: any
         bpf: tcp and dst port 80

Windows

Der Weiterleiter kann WebProxy-Daten mit Npcap erfassen und an Google Cloud senden.

Wenn Sie die Webproxy-Datenerfassung für Ihr System aktivieren möchten, wenden Sie sich an den Google SecOps-Support.

Führen Sie die folgenden Schritte aus, bevor Sie einen WebProxy-Weiterleiter ausführen:

  1. Installieren Sie Npcap auf dem Microsoft Windows-Host. Aktivieren Sie während der Installation den WinPcap-Kompatibilitätsmodus.

  2. Gewähren Sie dem Weiterleiter Root- oder Administratorberechtigungen, um die Netzwerkschnittstelle zu überwachen.

  3. Rufen Sie die GUID für die Schnittstelle ab, die zum Erfassen der WebProxy-Pakete verwendet wurde.

    Führen Sie getmac.exe auf dem Computer aus, auf dem Sie den Google SecOps-Weiterleiter installieren möchten, und senden Sie die Ausgabe an Google SecOps. Alternativ können Sie die Konfigurationsdatei ändern. Suchen Sie den Abschnitt „WebProxy“ und ersetzen Sie die GUID neben der Schnittstelle durch die GUID, die nach dem Ausführen von getmac.exe angezeigt wird.

    Ändern Sie die Konfigurationsdatei des Google SecOps-Weiterleiters (FORWARDER_NAME.conf) so:

      - 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

Schlüsselattribute in der Konfigurationsdatei konfigurieren

In der folgenden Tabelle sind wichtige Parameter aufgeführt, die in der Konfigurationsdatei des Brokers verwendet werden.

Parameter Beschreibung
data_type Die Art der Protokolldaten, die der Protokollierungsmechanismus erfassen und verarbeiten kann.
Metadaten Metadaten, die globale Metadaten überschreiben.
max_file_buffer_bytes Die maximale Anzahl von Byte, die im Laufwerks- oder Dateipuffer angesammelt werden können. Der Standardwert ist 1073741824, also 1 GB.
max_memory_buffer_bytes Maximale Anzahl von Bytes, die im Speicherpuffer angesammelt werden können. Der Standardwert ist 1073741824, also 1 GB.
write_to_disk_dir_path Der Pfad, der für den Datei- oder Laufwerkbuffer verwendet werden soll.
write_to_disk_buffer_enabled Bei true wird anstelle des Arbeitsspeicherpuffers der Laufwerkpuffer verwendet. Der Standardwert ist false.
batch_n_bytes Maximale Anzahl von Byte, die vom Collector erfasst werden können, bevor die Daten in Batches zusammengefasst werden. Der Standardwert ist 1048576, also 1 MB.
batch_n_seconds Die Anzahl der Sekunden, nach denen die vom Collector erfassten Daten in Batches zusammengefasst werden. Der Standardwert beträgt 11 Sekunden.
data_hint Datenformat, das der Collector empfangen kann (normalerweise der Header der Protokolldatei, der das Format beschreibt).

Eine umfassende Liste der in der Konfigurationsdatei verwendeten Parameter finden Sie unter Konfigurationsfelder für Weiterleitungen und Konfigurationsfelder für Collector.

Datenkompression

Die Protokollkomprimierung ist standardmäßig deaktiviert. Wenn Sie die Protokollkomprimierung aktivieren, lässt sich der Bandbreitenverbrauch möglicherweise reduzieren. Die Aktivierung der Protokollkomprimierung kann jedoch auch die CPU-Auslastung erhöhen. Bewerten Sie den Trade-off anhand Ihrer Umgebung und Protokolldaten.

Wenn Sie die Protokollkomprimierung aktivieren möchten, setzen Sie das Feld compression in der Konfigurationsdatei des Google SecOps-Weiterleiters auf true, wie im folgenden Beispiel gezeigt:

Die Datei 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
...

Datei FORWARDER_NAME_auth.conf

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

Laufwerkpufferung

Mit der Laufwerkpufferung können Sie nicht verarbeitete Nachrichten auf dem Laufwerk statt im Arbeitsspeicher puffern.

Sie können die automatische Speicherpufferung so konfigurieren, dass ein dynamisch freigegebener Puffer für alle Collector verwendet wird. So lassen sich Traffic-Spitzen besser bewältigen. Fügen Sie Folgendes in die Weiterleitungskonfiguration ein, um den dynamisch freigegebenen Puffer zu aktivieren:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Wenn die automatische Laufwerkspeicherung aktiviert ist, target_memory_utilization aber nicht definiert ist, wird der Standardwert 70 verwendet.

Wenn Sie den Forwarder mit Docker ausführen, empfehlen wir aus Gründen der Isolation, ein separates Volume von Ihrem Konfigurationsvolume bereitzustellen. Außerdem sollte jede Eingabe in einem eigenen Verzeichnis oder Volume isoliert werden, um Konflikte zu vermeiden.

Beispielkonfiguration

Die folgende Konfiguration enthält Syntax zum Aktivieren der Laufwerkpufferung:

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

Filter für reguläre Ausdrücke

Mit regulären Ausdrucksfiltern können Sie Protokolle nach Mustern filtern, die mit den Rohprotokolldaten abgeglichen werden. Die Filter verwenden die RE2-Syntax. Die Filter müssen einen regulären Ausdruck enthalten und optional ein Verhalten bei einer Übereinstimmung definieren.

Das Standardverhalten bei einer Übereinstimmung ist block. Sie können Filter mit allow-Verhalten angeben. Wenn Sie einen allow-Filter angeben, blockiert der Weiterleiter alle Protokolle, die nicht mit mindestens einem allow-Filter übereinstimmen.

Es ist möglich, eine beliebige Anzahl von Filtern zu definieren. Block-Filter haben Vorrang vor allow-Filtern.

Bei der Definition von Filtern muss ihnen ein Name zugewiesen werden. Die Namen der aktiven Filter werden über die Statistiken zur Gesundheit des Weiterleitungsservers an Google SecOps gesendet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern auf Ebene des Collectors zusammengeführt. Bei Namenskonflikten haben die Filter auf Collector-Ebene Vorrang. Wenn weder auf Stamm- noch auf Collectorebene Filter definiert sind, werden alle Protokolle zugelassen.

Beispielkonfiguration

In der folgenden Weiterleitungskonfiguration werden WINEVTLOG-Protokolle, die nicht mit dem Stammfilter (allow_filter) übereinstimmen, blockiert. Aufgrund des regulären Ausdrucks werden mit dem Filter nur Protokolle mit Prioritäten zwischen 0 und 99 zugelassen. NIX_SYSTEM-Protokolle, die „foo“ oder „bar“ enthalten, werden jedoch trotz allow_filter blockiert. Das liegt daran, dass die Filter ein logisches ODER verwenden. Alle Protokolle werden verarbeitet, bis ein Filter ausgelöst wird.

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

Benutzerdefinierte Labels

Mit Labels können Protokollen benutzerdefinierte Metadaten in Form von Schlüssel/Wert-Paaren hinzugefügt werden. Sie können Labels für einen gesamten Weiterleiter oder für einen bestimmten Collector des Weiterleiters konfigurieren. Wenn beide vorhanden sind, überschreiben Labels auf Ebene des Datensammlers Labels auf Ebene des Übertragers, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration

In der folgenden Weiterleitungskonfiguration sind die Schlüssel/Wert-Paare „foo=bar“ und „meow=mix“ an WINEVTLOG-Protokolle angehängt und die Schlüssel/Wert-Paare „foo=baz“ und „meow=mix“ an NIX_SYSTEM-Protokolle.

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

Namespaces

Mithilfe von Namespace-Labels können Sie Protokolle aus verschiedenen Netzwerksegmenten identifizieren und Überschneidungen von IP-Adressen beheben. Jeder für den Weiterleiter konfigurierte Namespace wird mit den zugehörigen Assets auf der Benutzeroberfläche von Google SecOps angezeigt. Sie können auch mit der Google SecOps-Suche nach Namespaces suchen.

Informationen zum Aufrufen von Namespaces in der Benutzeroberfläche von Google SecOps finden Sie unter Asset-Namespaces.

Beispielkonfiguration

In der folgenden Weiterleitungskonfiguration sind die WINEVTLOG-Protokolle dem FORWARDER-Namespace und die NIX_SYSTEM-Protokolle dem CORPORATE-Namespace zugeordnet.

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

Optionen für Load Balancing und Hochverfügbarkeit

Sie können die Optionen für den HTTP-Server, das Load Balancing und die Hochverfügbarkeit im Abschnitt „server“ der Weiterleitungskonfigurationsdatei konfigurieren. Mit diesen Optionen können Zeitlimits und Statuscodes festgelegt werden, die als Reaktion auf Systemdiagnosen zurückgegeben werden, die in Container-Schedulern und orchestrierungsbasierten Bereitstellungen sowie von Load Balancern empfangen werden.

Verwenden Sie die folgenden URL-Pfade für Systemdiagnosen, Bereitschafts- und Aktivitätsprüfungen. Die <host:port>-Werte werden in der Weiterleitungskonfiguration definiert.

  • http://<host:port>/meta/available: Aktivitätsprüfungen für Container-Scheduler oder ‑Orchestratoren
  • http://<host:port>/meta/ready: Bereitschafts- und Load Balancer-Systemdiagnosen

Die folgende Weiterleitungskonfiguration ist ein Beispiel für Load Balancing und Hochverfügbarkeit:

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
Konfigurationspfad Beschreibung
server : graceful_timeout Die Zeitspanne, in der der Weiterleiter eine fehlerhafte Bereitschafts-/Systemdiagnose zurückgibt und trotzdem neue Verbindungen akzeptiert. Dies ist auch die Zeit, die zwischen dem Empfang eines Stoppsignals und dem tatsächlichen Herunterfahren des Servers vergeht. So hat der Load Balancer Zeit, den Weiterleiter aus dem Pool zu entfernen.
server : drain_timeout Die Zeit, die der Weiterleiter wartet, bis aktive Verbindungen von selbst geschlossen werden, bevor sie vom Server geschlossen werden.
server : http : port Die Portnummer, unter der der HTTP-Server auf Systemdiagnosen vom Load Balancer wartet. Muss zwischen 1024 und 65535 liegen.
server : http : host Die IP-Adresse oder der Hostname, der in IP-Adressen aufgelöst werden kann, auf die der Server hören soll. Ist das Feld leer, wird der Standardwert „local system“ (0.0.0.0) verwendet.
server : http : read_timeout Wird zum Optimieren des HTTP-Servers verwendet. Muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximale Zeit, die zum Lesen der gesamten Anfrage benötigt wird, einschließlich Header und Text. Sie können sowohl „read_timeout“ als auch „read_header_timeout“ festlegen.
server : http : read_header_timeout Wird zum Optimieren des HTTP-Servers verwendet. Muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximale Zeit, die zum Lesen von Anfrageheadern zulässig ist. Die Frist für das Lesen der Verbindung wird nach dem Lesen des Headers zurückgesetzt.
server : http : write_timeout Wird zum Optimieren des HTTP-Servers verwendet. Muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximale Zeitspanne, innerhalb derer eine Antwort gesendet werden muss. Er wird zurückgesetzt, wenn ein neuer Anfrageheader gelesen wird.
server : http : idle_timeout Wird zum Optimieren des HTTP-Servers verwendet. Muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximale Wartezeit auf die nächste Anfrage, wenn inaktive Verbindungen aktiviert sind. Wenn „idle_timeout“ null ist, wird der Wert von „read_timeout“ verwendet. Wenn beide null sind, wird „read_header_timeout“ verwendet.
routes : meta : ready_status Der Statuscode, den der Weiterleiter zurückgibt, wenn er in einer der folgenden Situationen bereit ist, den Traffic anzunehmen:
  • Die Bereitschaftsprüfung wird von einem Container-Scheduler oder -Orchestrator empfangen.
  • Die Systemdiagnose wird von einem herkömmlichen Load Balancer empfangen.
routes : meta : unready_status Der Statuscode, den der Weiterleiter zurückgibt, wenn er nicht bereit ist, Traffic anzunehmen.
routes : meta : available_status Der Statuscode, den der Weiterleiter zurückgibt, wenn eine Aktivitätsprüfung empfangen wird und der Weiterleiter verfügbar ist. Container-Scheduler oder ‑Orchestrator senden häufig Liveness-Prüfungen.