Forwarder-Konfigurationsdatei manuell verwalten

Unterstützt in:

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

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

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

Hinweise

Bevor Sie die Konfigurationsdatei erstellen, sollten Sie Ihre Implementierung planen. Dazu müssen Sie wissen, welche Datentypen aufgenommen werden können und welche wichtigen Attribute 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 mit der folgenden Namenskonvention:

    FORWARDER_NAME.conf: Mit dieser Datei definieren Sie die Konfigurationseinstellungen für die Aufnahme von Logs.

    FORWARDER_NAME_auth.conf: Mit dieser Datei definieren Sie die Autorisierungsanmeldedaten.

  3. Ändern Sie die Dateien, um die Konfiguration für Ihre Forwarder-Instanz einzufügen.

    Details zu den Einstellungen für die einzelnen Arten von Erfassungsmechanismen, z. B. Splunk oder Syslog, finden Sie unter Datentypen in der Konfigurationsdatei definieren. Weitere Informationen zum Anpassen der einzelnen Attribute, z. B. zur Datenkomprimierung oder zum Zwischenspeichern auf der Festplatte, 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 hat. Das ist erforderlich, um die Daten richtig zuzuordnen.

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

Beispielkonfigurationen

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

Konfiguration mit zwei Dateien

Bei diesem Dateisystem werden Anmeldedaten zur Authentifizierung in einer separaten Datei gespeichert, um die Sicherheit zu erhöhen. Sie können die Datei FORWARDER_NAME.conf in einem Versionsverwaltungs-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 Forwarder ausgeführt wird.

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

Die Datei FORWARDER_NAME.conf

output:
  url: {region}-chronicle.googleapis.com (for example: us-chronicle.googleapis.com)
  use_dataplane : true
  project_id: PROJECT_ID
  region: {region} (for example: {us})
  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

Die 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 für eine einzelne Datei

output:
  url: us-chronicle.googleapis.com
  use_dataplane: true
  project_id: PROJECT_ID
  region: us
    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 System mit zwei Dateien konvertieren

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

  1. Erstellen Sie eine Kopie Ihrer vorhandenen Konfigurationsdatei.

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

  3. Speichern Sie die andere Datei als FORWARDER_NAME_auth.conf-Datei und löschen Sie alle Daten, die nicht zur Autorisierung gehören. Sie können die Beispielkonfiguration als Referenz verwenden. Achten Sie darauf, dass Sie die Namenskonvention und andere Richtlinien im Abschnitt Konfigurationen anpassen einhalten.

Datentypen in der Konfigurationsdatei definieren

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

Splunk-Daten

Sie können den Google SecOps-Forwarder so konfigurieren, dass Ihre Splunk-Daten an Google SecOps weitergeleitet werden. Google Cloud konfiguriert den Google SecOps-Forwarder 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-Forwarder bereit. Dazu können Sie eine creds.txt-Datei erstellen.

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-Forwarder verwenden möchten, um auf eine Splunk-Instanz zuzugreifen, kopieren Sie die Datei creds.txt in das Konfigurationsverzeichnis (dasselbe 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 vorgesehenen Verzeichnis befindet:

    Linux

      ls /opt/chronicle/config
    

    Windows

    ls c:/opt/chronicle/config
    

Syslog-Daten

Ein Forwarder kann als Syslog-Server fungieren. Sie können jeden Server, der das Senden von Syslog-Daten über eine TCP- oder UDP-Verbindung unterstützt, so konfigurieren, dass seine Daten an den Google SecOps-Forwarder weitergeleitet werden. Sie können die Daten steuern, die der Server an den Forwarder sendet. Der Forwarder kann die Daten dann an Google SecOps weiterleiten.

In der Konfigurationsdatei FORWARDER_NAME.conf (vonGoogle Cloudbereitgestellt) wird angegeben, welche Ports für die einzelnen Arten weitergeleiteter Daten überwacht werden sollen (z. B. Port 10514). Standardmäßig akzeptiert der Google SecOps-Forwarder sowohl TCP- als auch UDP-Verbindungen.

Sie können die TCP-Puffergröße anpassen. Die Standardgröße des TCP-Puffers beträgt 64 KB. Der Standardwert und der empfohlene Wert für connection_timeout sind 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 (z. B. jeden Datentyp) ein Ziel angeben. Die folgenden Beispiele veranschaulichen die rsyslog-Zielkonfiguration:

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

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

Weitere Informationen finden Sie in der Dokumentation Ihres Systems.

TLS für Syslog-Konfigurationen aktivieren

Sie können TLS für die Syslog-Verbindung zum Google SecOps-Forwarder aktivieren. Geben Sie in der Konfigurationsdatei des Forwarders (FORWARDER_NAME.conf) den Speicherort Ihres selbst generierten Zertifikats und Zertifikatschlüssels an, wie im folgenden Beispiel gezeigt. Sie können ein certs-Verzeichnis unter dem configuration-Verzeichnis erstellen und die Zertifikatsdateien 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 Forwarder-Konfigurationsdatei (FORWARDER_NAME.conf) anhand des gezeigten 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 Mindest-TLS-Version sein. Die Mindest-TLS-Version sollte einer der folgenden Werte sein: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Dateidaten

Ein Dateicollector ist dafür konzipiert, Logs aus einer Datei abzurufen, die an den Docker-Container gebunden ist. Sie können diese Option verwenden, wenn Sie Logs aus einer einzelnen Logdatei manuell hochladen möchten.

Starten Sie den Google SecOps-Forwarder über den Docker-Container, um das Lastvolumen 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-Forwarders (Datei FORWARDER_NAME.conf) 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 sollte sich im Ordner /var/log/crowdstrike/falconhostclient befinden.

Flag-Konfigurationen

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

poll (bool): Der Dateicollector verwendet die Tail-Bibliothek, um nach Änderungen im Dateisystem zu suchen. Wenn Sie dieses Flag auf true setzen, verwendet die Tail-Bibliothek die Polling-Methode anstelle der Standardmethode „notify“.

Paketdaten

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

Linux-Systeme

Der Google SecOps-Forwarder kann Pakete mit libcap unter Linux erfassen. Weitere Informationen zu libcap finden Sie auf der Linux-Handbuchseite zu libcap.

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

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

Windows-Systeme

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

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

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

  • Installieren Sie Npcap auf dem Microsoft Windows-Host.

  • Gewähren Sie dem Google SecOps-Forwarder Root- oder Administratorberechtigungen, um die Netzwerkschnittstelle zu überwachen.

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

Zum Konfigurieren eines PCAP-Forwarders 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-Forwarder installieren möchten (entweder auf dem Server oder auf dem Computer, der den Span-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 ein Beispiel für einen ursprünglichen 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 Ausführung 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 „Transport Name“ beginnt mit \Device\Tcpip, während der vergleichbare pcap-Abschnitt mit \Device\NPF beginnt.

Daten aus Kafka-Thema

Der Google SecOps-Forwarder unterstützt die direkte Aufnahme von Daten aus Kafka-Themen. Sie können bis zu drei Forwarder bereitstellen und Daten aus demselben Kafka-Thema abrufen. Dabei können Sie das Konzept der Nutzergruppen für eine effiziente und parallele Verarbeitung nutzen. Weitere Informationen finden Sie unter Kafka. Weitere Informationen zu Kafka-Nutzergruppen finden Sie unter Kafka-Nutzer.

Die folgende Forwarder-Konfiguration zeigt, wie Sie den Forwarder so einrichten, dass Daten aus den Kafka-Themen aufgenommen werden.

Linux

Die 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
   

Die 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-Forwarder kann WebProxy-Daten direkt von einer Netzwerkschnittstelle erfassen.

Linux

Der Google SecOps-Forwarder kann WebProxy-Daten mit libcap unter Linux erfassen. Weitere Informationen zu libcap finden Sie auf der Linux-Handbuchseite zu libcap. Wenn Sie die Erfassung von WebProxy-Daten für Ihr System aktivieren möchten, wenden Sie sich an den Google SecOps-Support.

Ändern Sie die Konfiguration des Google SecOps-Forwarders (Datei FORWARDER_NAME.conf) so:

   - 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 Forwarder kann WebProxy-Daten mit Npcap erfassen und an Google Cloudsenden.

Wenn Sie die Erfassung von WebProxy-Daten 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-Forwarder 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 Forwarder Root- oder Administratorberechtigungen, damit er die Netzwerkschnittstelle überwachen kann.

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

    Führen Sie getmac.exe auf dem Computer aus, auf dem Sie den Google SecOps-Forwarder 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, die neben der Schnittstelle angezeigt wird, durch die GUID, die nach dem Ausführen von getmac.exe angezeigt wird.

    Ändern Sie die Konfigurationsdatei des Google SecOps-Forwarders (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 Forwarder-Konfigurationsdatei verwendet werden.

Parameter Beschreibung
data_type Der Typ der Protokolldaten, die der Collector erfassen und verarbeiten kann.
Metadaten Metadaten, die globale Metadaten überschreiben.
max_file_buffer_bytes Maximale Anzahl von Byte, die im Festplatten- 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 Festplattenpuffer verwendet werden soll.
write_to_disk_buffer_enabled Wenn true, wird der Festplattenpuffer anstelle des Arbeitsspeicherpuffers verwendet. Der Standardwert ist false.
batch_n_bytes Maximale Anzahl von Byte, die vom Collector angesammelt werden können, bevor die Daten in einem Batch 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 (in der Regel der Logdateiheader, der das Format beschreibt).

Eine ausführliche Liste der in der Konfigurationsdatei verwendeten Parameter finden Sie unter Felder für die Forwarder-Konfiguration und Felder für die Collector-Konfiguration.

Datenkompression

Die Log-Komprimierung ist standardmäßig deaktiviert. Durch die Aktivierung der Protokollkomprimierung kann der Bandbreitenverbrauch reduziert werden. Das Aktivieren der Logkomprimierung kann jedoch auch die CPU-Auslastung erhöhen. Bewerten Sie den Kompromiss anhand Ihrer Umgebung und der Protokolldaten.

Wenn Sie die Logkomprimierung aktivieren möchten, legen Sie das Feld compression in der Konfigurationsdatei des Google SecOps-Forwarders auf true fest, 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
...

Die Datei FORWARDER_NAME_auth.conf

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

Laufwerkspufferung

Mit der Laufwerkszwischenspeicherung können Sie zurückgestellte Nachrichten auf dem Laufwerk statt im Arbeitsspeicher zwischenspeichern.

Sie können die automatische Speicherpufferung so konfigurieren, dass ein dynamisch freigegebener Puffer für alle Collectors verwendet wird. Dadurch lassen sich Trafficspitzen besser abfangen. Fügen Sie Folgendes in Ihre Forwarder-Konfiguration ein, um den dynamisch freigegebenen Puffer zu aktivieren:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

Wenn die automatische Pufferung von Datenträgern aktiviert ist, aber target_memory_utilization nicht definiert ist, wird der Standardwert 70 verwendet.

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

Beispielkonfiguration

Die folgende Konfiguration enthält die Syntax zum Aktivieren der Festplattenpufferung:

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 Filtern für reguläre Ausdrücke können Sie Logs filtern, indem Sie Muster mit den Rohlogdaten abgleichen. Die Filter verwenden die RE2-Syntax. Die Filter müssen einen regulären Ausdruck enthalten und können optional ein Verhalten für den Fall einer Übereinstimmung definieren.

Das Standardverhalten bei einem Treffer ist block. Sie können Filter mit dem allow-Verhalten angeben. Wenn Sie einen allow-Filter angeben, blockiert der Forwarder alle Logs, 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.

Wenn Filter definiert sind, muss ihnen ein Name zugewiesen werden. Die Namen aktiver Filter werden über die Messwerte zum Forwarder-Status an Google SecOps gemeldet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern zusammengeführt, die auf Sammlerebene definiert sind. Die Filter auf Collector-Ebene haben Vorrang, wenn es zu Namenskonflikten kommt. Wenn weder auf der Stamm- noch auf der Kollektorebene Filter definiert sind, werden alle Logs zugelassen.

Beispielkonfiguration

In der folgenden Forwarder-Konfiguration werden die WINEVTLOG-Logs, die nicht mit dem Stammfilter (allow_filter) übereinstimmen, blockiert. Der reguläre Ausdruck lässt nur Logs mit Prioritäten zwischen 0 und 99 zu. Alle NIX_SYSTEM-Logs, die „foo“ oder „bar“ enthalten, werden jedoch trotz der allow_filter blockiert. Das liegt daran, dass die Filter ein logisches ODER verwenden. Alle Logs 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

Beliebige Labels

Mit Labels können benutzerdefinierte Metadaten in Form von Schlüssel/Wert-Paaren an Logs angehängt werden. Sie können Labels für einen gesamten Forwarder oder innerhalb eines bestimmten Collectors des Forwarders konfigurieren. Wenn beide vorhanden sind, überschreiben Labels auf Sammlerebene Labels auf Weiterleiterebene, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration

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

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

Sie können Namespace-Labels verwenden, um Logs aus verschiedenen Netzwerksegmenten zu identifizieren und überlappende IP-Adressen zu entschärfen. Alle für den Forwarder konfigurierten Namespaces werden mit den zugehörigen Assets in der Google SecOps-Benutzeroberfläche angezeigt. Sie können auch mit der Google SecOps Search-Funktion nach Namespaces suchen.

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

Beispielkonfiguration

In der folgenden Forwarder-Konfiguration sind die WINEVTLOG-Logs an den FORWARDER-Namespace und die NIX_SYSTEM-Logs an den CORPORATE-Namespace angehängt.

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 HTTP-Server, Load-Balancing und Hochverfügbarkeit im Serverabschnitt der Forwarder-Konfigurationsdatei konfigurieren. Mit diesen Optionen können Zeitlimits und Statuscodes festgelegt werden, die als Reaktion auf Systemdiagnosen zurückgegeben werden, die in containerbasierten Bereitstellungen mit Scheduler und Orchestrierung sowie von Load-Balancern empfangen werden.

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

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

Die folgende Forwarder-Konfiguration 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 Zeit, in der der Forwarder eine fehlerhafte Bereitschafts-/Systemdiagnose zurückgibt und trotzdem neue Verbindungen akzeptiert. Dies ist auch die Wartezeit zwischen dem Empfang eines Signals zum Beenden und dem tatsächlichen Herunterfahren des Servers. So hat der Load-Balancer Zeit, den Forwarder aus dem Pool zu entfernen.
server : drain_timeout Die Zeit, die der Forwarder wartet, bis aktive Verbindungen von selbst geschlossen werden, bevor sie vom Server geschlossen werden.
server : http : port Die Portnummer, an 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. Wenn leer, ist der Standardwert das lokale System (0.0.0.0).
server : http : read_timeout Wird zum Optimieren des HTTP-Servers verwendet. Muss in der Regel nicht von der Standardeinstellung geändert werden. Die maximal zulässige Zeit zum Lesen der gesamten Anfrage, sowohl des Headers als auch des Texts. 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 Lesedeadline 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 maximal zulässige Zeit zum Senden einer Antwort. 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 für 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 Forwarder zurückgibt, wenn er bereit ist, den Traffic in einer der folgenden Situationen zu akzeptieren:
  • 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 Forwarder zurückgibt, wenn er nicht bereit ist, Traffic anzunehmen.
routes : meta : available_status Der Statuscode, den der Forwarder zurückgibt, wenn eine Aktivitätsprüfung empfangen wird und der Forwarder verfügbar ist. Container-Scheduler oder Orchestratoren senden häufig Liveness-Prüfungen.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten