Chronicle-Forwarder für Windows in Docker

In diesem Dokument wird beschrieben, wie Sie den Chronicle-Forwarder für Windows in Docker installieren und konfigurieren.

Systemanforderungen

Im Folgenden finden Sie allgemeine Empfehlungen. Wenden Sie sich an den Chronicle-Support, um Empfehlungen speziell für Ihr System zu erhalten.

Windows Server-Version: Der Chronicle-Forwarder wird unter Microsoft Windows Server 2022 unterstützt.
RAM: 1,5 GB für jeden erfassten Protokolltyp Endpunkterkennung und -antwort (EDR), DNS und DHCP sind beispielsweise separate Logtypen. Sie benötigen 4,5 GB RAM, um für alle drei Daten zu erfassen. Eine Liste der unterstützten Standardparser und Logtypen finden Sie unter Unterstützte Standardparser.
CPU: 2 CPUs sind ausreichend,um insgesamt weniger als 10.000 Ereignisse pro Sekunde (EPS) über alle Datentypen hinweg zu verarbeiten. Wenn Sie davon ausgehen,mehr als 10.000 EPS zu senden, sind 4 bis 6 CPUs erforderlich.
Laufwerk: 100 MB Speicherplatz sind ausreichend, unabhängig davon, wie viele Daten der Chronicle-Forwarder verarbeitet. Sie können das Laufwerk zwischenspeichern, indem Sie der Konfigurationsdatei die Parameter write_to_disk_buffer_enabled und write_to_disk_dir_path hinzufügen.

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

Google-IP-Adressbereiche

Möglicherweise muss der IP-Adressbereich geöffnet werden, wenn Sie eine Chronicle-Forwarder-Konfiguration einrichten, z. B. wenn Sie die Konfiguration für Ihre Firewall einrichten. Google kann keine spezifische Liste von IP-Adressen zur Verfügung stellen. Sie können jedoch IP-Adressbereiche von Google abrufen.

Firewallkonfiguration prüfen

Wenn Sie Firewalls oder authentifizierte Proxys zwischen dem Chronicle-Forwarder-Container und dem Internet haben, sind Regeln erforderlich, die den Zugriff auf die folgenden Google Cloud-Hosts ermöglichen:

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

So prüfen Sie die Netzwerkverbindung zu Google Cloud:

Starten Sie Windows PowerShell mit Administratorberechtigungen. Klicken Sie dazu auf Start, geben Sie PowerShell ein, klicken Sie mit der rechten Maustaste auf Windows PowerShell und klicken Sie auf Als Administrator ausführen.

Führen Sie den folgenden Befehl aus:

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

Der Befehl gibt zurück, dass TcpTestSucceeded true ist.

Beispiel:

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

Docker unter Microsoft Windows installieren

In diesem Abschnitt wird beschrieben, wie Sie Docker unter Microsoft Windows über die Befehlszeile und PowerShell installieren.

Vorteile von Chronicle-Forwarder mit einem Container:

Bessere Sicherheit durch Isolierung:
- Kundenumgebung und -anforderungen haben keine Auswirkungen auf den Chronicle-Forwarder.
- Die Chronicle-Forwarder-Umgebung und -Anforderungen haben keine Auswirkungen auf den Kunden.
- Der Containerverteilungsmechanismus ist bereits vorhanden und kann für Google Cloud und Kunden privat und separat sein. Weitere Informationen finden Sie unter Artifact Registry.

Führen Sie auf Microsoft Windows Server Core 2022 die folgenden Schritte aus.

Aktivieren Sie die Microsoft Windows-Containerfunktion.
```
Install-WindowsFeature containers -Restart
```

Führen Sie den folgenden Befehl im PowerShell-Administratormodus aus, um Docker CE zu installieren:

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

.\install-docker-ce.ps1

Testen Sie die Docker-Befehlszeile mit dem Befehl docker ps, der eine Liste der ausgeführten Container zurückgibt. Wenn mit dem Befehl keine ausgeführten Container aufgelistet werden, ist die Installation erfolgreich. Wenn Docker nicht ordnungsgemäß installiert ist, wird ein Fehler angezeigt.

Weitere Informationen finden Sie unter Jetzt starten: Fenster für Container vorbereiten.

Für Bereitstellungen in Unternehmen installieren Sie die Mirantis Container Runtime, auch bekannt als Docker EE.

Chronicle-Forwarder konfigurieren

Informationen zum Konfigurieren des Chronicle-Forwarders für Windows in Docker finden Sie unter Forwarder-Konfigurationen über die Chronicle-UI verwalten.

Achten Sie beim Konfigurieren des Chronicle-Forwarders darauf, dass alle Pfade im Forwarder mit dem Präfix „c:“ beginnen.

Alle Änderungen an der Konfigurationsdatei werden innerhalb von 5 Minuten automatisch vom Chronicle-Forwarder angewendet.

Informationen zum Erfassen von Paketdaten mit dem Chronicle-Forwarder für Windows auf Docker finden Sie unter Paketdaten erfassen.

Chronicle-Forwarder im Docker-Container ausführen

Wenn Sie ein Upgrade des Chronicle-Forwarders durchführen, bereinigen Sie zuerst frühere Docker-Ausführungen. Im folgenden Beispiel lautet der Name des Docker-Containers cfps.
```
docker stop cfps

docker rm cfps
```
Rufen Sie mit diesem Docker-Pull-Befehl das neueste Docker-Image von Google Cloud ab.
```
docker pull gcr.io/chronicle-container/cf_production_stable_windows
```
Starten Sie den Chronicle-Forwarder aus dem Docker-Container.
```
docker run `
--detach `
--name cfps `
--restart=always `
--log-opt max-size=100m `
--log-opt max-file=10 `
-p 10514:10514 `
-v C:\config\:C:/opt/chronicle/external `
gcr.io/chronicle-container/cf_production_stable_windows
```
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

Hinweis: Die im Beispielcode angegebenen Portnummern sind Beispiele. Sie müssen die Portnummern entsprechend Ihren Anforderungen ersetzen.

Forwarder-Logs ansehen

Führen Sie den folgenden Befehl aus, um die Chronicle-Forwarder-Logs anzusehen:

  sudo docker logs cfps

Führen Sie den folgenden Befehl aus, um den Pfad der Datei anzusehen, in der die Logs gespeichert sind:

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

Führen Sie den folgenden Befehl aus, um die Live-Lauflogs anzusehen:

  sudo docker logs cfps -f

Führen Sie den folgenden Befehl aus, um die Logs in einer Datei zu speichern:

  sudo docker logs cfps &> logs.txt

Chronicle-Forwarder deinstallieren

Mit den folgenden Docker-Befehlen können Sie den Chronicle-Forwarder beenden und deinstallieren oder entfernen.

Dieser Befehl stoppt den Chronicle-Forwarder-Container:

  docker stop cfps

Mit diesem Befehl wird der Chronicle-Forwarder-Container entfernt:

  docker rm cfps

Chronicle-Forwarder aktualisieren

Der Chronicle-Forwarder für Windows in Docker wird ständig mithilfe eines Shell-Skripts im Docker-Image aktualisiert, sodass Sie hierfür keine ausführbare Datei bereitstellen müssen.

Daten erheben

In den folgenden Abschnitten erfahren Sie, wie Sie den Chronicle-Forwarder für die Aufnahme verschiedener Datentypen konfigurieren, die an die Chronicle-Instanz weitergeleitet werden.

Für batch_n_bytes darf kein Wert größer als 1 MB konfiguriert werden. Wenn Sie einen Wert festlegen, der größer als 1 MB ist, wird er automatisch auf 1 MB zurückgesetzt.

Splunk-Daten erfassen

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

URL für die Splunk REST API (z. B. https://10.0.113.15:8089).
Splunk-Abfragen, um Daten für jeden der erforderlichen Datentypen zu generieren (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

Machen Sie die Anmeldedaten Ihres Splunk-Kontos für den Chronicle-Forwarder verfügbar. Erstellen Sie dazu eine creds.txt-Datei.

So verwenden Sie eine creds.txt-Datei:

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

Hinweis: Achten Sie darauf, dass die Anmeldedaten sicher gespeichert werden. Leiten Sie Ihre Splunk-Anmeldedaten nicht an Google Cloud weiter.
Geben Sie Ihren Nutzernamen in die erste Zeile und das Passwort in die zweite Zeile ein:
```
cat creds.txt

myusername
mypassword
```
Wenn Sie den Chronicle-Forwarder für den Zugriff auf eine Splunk-Instanz verwenden möchten, kopieren Sie die Datei creds.txt in das Konfigurationsverzeichnis (das Verzeichnis, in dem sich die Konfigurationsdateien befinden). Beispiel:
```
cp creds.txt c:/opt/chronicle/config/creds.txt
```
Prüfen Sie, ob sich die Datei creds.txt am richtigen Speicherort befindet:
```
ls c:/opt/chronicle/config
```

Syslog-Daten erfassen

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

Die von Google Cloud bereitgestellte Konfigurationsdatei FORWARDER_NAME.conf gibt an, welche Ports für die einzelnen weitergeleiteten Daten (z. B. Port 10514) überwacht werden sollen. Standardmäßig akzeptiert der Chronicle-Forwarder sowohl TCP- als auch UDP-Verbindungen.

rsyslog konfigurieren

Zum Konfigurieren von rsyslog müssen Sie für jeden Port (z. B. jeden Datentyp) ein Ziel angeben. Die korrekte Syntax finden Sie in der Systemdokumentation. Die folgenden Beispiele veranschaulichen die rsyslog-Zielkonfiguration:

TCP-Logtraffic: dns.* @@192.168.0.12:10514
UDP-Logtraffic: dns.* @192.168.0.12:10514

TLS für Syslog-Konfigurationen aktivieren

Sie können TLS für die Syslog-Verbindung zum Chronicle-Forwarder aktivieren. Geben Sie in der Konfigurationsdatei für den Chronicle-Forwarder (FORWARDER_NAME.conf) den Speicherort Ihres eigenen generierten Zertifikats und des Zertifikatschlüssels an, wie im folgenden Beispiel gezeigt:

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 für den Chronicle-Forwarder (FORWARDER_NAME.conf) basierend auf dem gezeigten Beispiel so:

  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"

Ein paar wichtige Hinweise:

Sie können die TCP-Puffergröße konfigurieren. Die standardmäßige TCP-Zwischenspeichergröße beträgt 64 KB.
Der empfohlene Standardwert für connection_timeout ist 60 Sekunden. Wenn die Verbindung für eine bestimmte Zeit inaktiv ist, wird die TCP-Verbindung beendet.
Die TLS-Mindestversion wird mit der TLS-Version der Eingabeanfrage verglichen. Die TLS-Version der Eingabeanfrage sollte höher als die TLS-Mindestversion sein. Die Mindestversion für TLS muss einer der folgenden Werte sein: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Sie können im Konfigurationsverzeichnis ein Verzeichnis „certs“ erstellen und die Zertifikatsdateien dort speichern.

Dateidaten erfassen

Ein Datei-Collector ist darauf ausgelegt, die Protokolle aus einer Datei abzurufen. Die Datei sollte an den Docker-Container gebunden sein.

Verwenden Sie diese Option, wenn Sie Protokolle manuell aus einer einzelnen Datei hochladen möchten. Dies kann verwendet werden, um Logs für eine bestimmte Logdatei aufzufüllen.

Starten Sie den Chronicle-Forwarder aus dem Docker-Container:

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

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

Der Befehl docker run ist wichtig, um das Ladevolumen dem Container zuzuordnen.

Auf Grundlage dieses Beispiels sollten Sie die Chronicle-Forwarder-Konfiguration (FORWARDER_NAME.conf-Datei) so ändern. Die Datei sample.txt sollte sich im Ordner /var/log/crowdstrike/falconhostclient befinden.

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

Flag-Konfigurationen

skip_seek_to_end (bool): Dieses Flag ist standardmäßig auf false gesetzt und die Dateieingabe sendet nur neue Logzeilen als Eingabe. Wenn dieser Wert auf true gesetzt ist, werden alle vorherigen Logzeilen bei Neustarts von Forwardern noch einmal gesendet. Dadurch werden die Logs dupliziert. Das Festlegen dieses Flags auf true ist in bestimmten Situationen hilfreich (z. B. bei Ausfällen), da der Neustart des Forwarders die fehlenden Logzeilen noch einmal sendet.

poll (bool): Der Datei-Collector prüft mithilfe der Tail-Bibliothek auf Änderungen im Dateisystem. Wenn Sie dieses Flag auf true setzen, verwendet die Tail-Bibliothek die Abfragemethode anstelle der standardmäßigen Benachrichtigungsmethode.

Paketdaten erfassen

Der Chronicle-Forwarder kann Pakete mithilfe von Npcap auf Windows-Systemen direkt von einer Netzwerkschnittstelle erfassen.

Pakete werden anstelle von Logeinträgen erfasst und an Google Cloud gesendet. Die Erfassung erfolgt nur über eine lokale Schnittstelle.

Wenden Sie sich an den Chronicle-Support, um Ihre Chronicle-Forwarder-Konfigurationsdatei zu aktualisieren, um die Paketerfassung zu unterstützen.

Zum Ausführen eines Paketerfassungs-Forwarders (PCAP) benötigen Sie Folgendes:

Installieren Sie Npcap auf dem Microsoft Windows-Host.
Gewähren Sie dem Chronicle-Forwarder-Root oder Administratorberechtigungen zum Überwachen der Netzwerkschnittstelle.
Befehlszeilenoptionen sind nicht erforderlich.
Aktivieren Sie in 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 der Maschine aus, auf der Sie den Chronicle-Forwarder installieren möchten (entweder den Server oder die Maschine, die den Span-Port überwacht) und senden Sie die Ausgabe an Chronicle.

Alternativ können Sie die Konfigurationsdatei ändern. Suchen Sie den PCAP-Abschnitt und ersetzen Sie den GUID-Wert neben der Schnittstelle durch die GUID, die beim Ausführen von getmac.exe angezeigt wird.

Hier sehen Sie beispielsweise 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

So sieht die Ausgabe von getmac.exe aus:

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

Und schließlich finden Sie hier den überarbeiteten 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

Daten aus Kafka-Thema erfassen

Sie können Daten aus den Kafka-Themen genau wie von syslog aufnehmen. Mit den Nutzergruppen können Sie bis zu drei Chronicle-Forwarder bereitstellen und Daten aus demselben Kafka-Thema abrufen. Weitere Informationen finden Sie unter Kafka.

Weitere Informationen zu Kafka-Kundengruppen

Beispielkonfiguration: Kafka-Eingabe

Die folgende Chronicle-Forwarder-Konfiguration zeigt, wie der Chronicle-Forwarder so eingerichtet wird, dass Daten aus den Kafka-Themen aufgenommen werden.

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

Der Chronicle-Forwarder kann WebProxy-Daten mit Npcap direkt von einer Netzwerkschnittstelle erfassen und an Google Cloud senden.

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

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

Installieren Sie Npcap auf dem Microsoft Windows-Host. WinPcap-Kompatibilitätsmodus während der Installation aktivieren
Gewähren Sie dem Chronicle-Forwarder Root- oder Administratorberechtigungen, um die Netzwerkschnittstelle zu überwachen.
Zum Konfigurieren eines WebProxy-Forwarders benötigt Google Cloud die GUID für die Schnittstelle, die zum Erfassen der WebProxy-Pakete verwendet wird.

Führen Sie getmac.exe auf dem Computer aus, auf dem Sie den Chronicle-Forwarder installieren möchten, und senden Sie die Ausgabe an Chronicle. 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 für die Chronicle-Forwarder-Konfiguration (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
```

Konfigurationen anpassen

In der folgenden Tabelle sind wichtige Parameter aufgeführt, die in der Konfigurationsdatei für Forwarder 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 Laufwerk- oder Dateizwischenspeicher akkumuliert werden kann. Der Standardwert ist `1073741824`, also 1 GB.
max_memory_buffer_bytes	Maximale Anzahl von Byte, die im Arbeitsspeicherpuffer akkumuliert werden können. Der Standardwert ist `1073741824`, also 1 GB.
write_to_disk_dir_path	Der Pfad, der für die Datei oder den Laufwerkzwischenspeicher verwendet werden soll.
write_to_disk_buffer_enabled	Bei `true` wird der Laufwerkzwischenspeicher anstelle des Arbeitsspeicherzwischenspeichers verwendet. Der Standardwert ist `false`.
batch_n_bytes	Maximale Anzahl von Byte, die vom Collector akkumuliert werden können, nach dem die Daten in Batches zusammengefasst werden. Der Standardwert ist `1048576` mit 1 MB.
batch_n_seconds	Die Anzahl der Sekunden, nach der die vom Collector erfassten Daten in einem Batch 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 Forwarder-Konfigurationsfelder und Collector-Konfigurationsfelder.

Datenkomprimierung ein-/ausschalten

Die Logkomprimierung reduziert den Verbrauch der Netzwerkbandbreite bei der Übertragung von Logs zu Chronicle. Die Komprimierung kann jedoch zu einer Erhöhung der CPU-Auslastung führen. Der Kompromiss zwischen CPU-Nutzung und Bandbreite hängt von vielen Faktoren ab, darunter vom Typ der Logdaten, der Komprimierbarkeit dieser Daten, der Verfügbarkeit von CPU-Zyklen auf dem Host, auf dem der Chronicle-Forwarder ausgeführt wird, und der Notwendigkeit, die Nutzung der Netzwerkbandbreite zu reduzieren.

Textbasierte Logs werden beispielsweise gut komprimiert und können bei geringer CPU-Auslastung erhebliche Bandbreiteneinsparungen bieten. Verschlüsselte Nutzlasten von Rohpaketen werden jedoch nicht gut komprimiert und verursachen eine höhere CPU-Auslastung.

Standardmäßig ist die Protokollkomprimierung deaktiviert. Durch Aktivieren der Logkomprimierung kann der Bandbreitenverbrauch reduziert werden. Das Aktivieren der Logkomprimierung kann jedoch auch die CPU-Auslastung erhöhen. Seien Sie sich der Nachteile bewusst.

Zum Aktivieren der Logkomprimierung setzen Sie das Feld compression in der Chronicle-Forwarder-Konfigurationsdatei auf true, wie im folgenden Beispiel gezeigt:

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

Laufwerkszwischenspeicherung konfigurieren

Durch die Zwischenspeicherung von Laufwerken können Sie zurückgestellte Nachrichten auf dem Laufwerk statt auf dem Arbeitsspeicher zwischenspeichern. Die zurückgestellten Nachrichten können gespeichert werden, wenn der Chronicle-Forwarder abstürzt oder der zugrunde liegende Host abstürzt. Beachten Sie, dass die Aktivierung der Laufwerkzwischenspeicherung die Leistung beeinträchtigen kann.

Wenn die Laufwerkzwischenspeicherung deaktiviert ist, verwendet der Chronicle-Forwarder 1 GB Arbeitsspeicher (RAM) für jeden Logtyp (z. B. für jeden Connector). Geben Sie den Konfigurationsparameter max_memory_buffer_bytes an. Der maximal zulässige Arbeitsspeicher beträgt 4 GB.

Sie können die automatische Zwischenspeicherung des Laufwerks so konfigurieren, dass ein dynamisch freigegebener Zwischenspeicher für Collectors verwendet wird, um Traffic-Spitzen besser zu bewältigen. Fügen Sie Ihrer Weiterleitungskonfiguration Folgendes hinzu, um den dynamisch freigegebenen Zwischenspeicher zu aktivieren:

auto_buffer:
  enabled: true
  target_memory_utilization: 80

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

Wenn Sie den Chronicle-Forwarder mit Docker ausführen, empfiehlt Google zu Isolierungszwecken ein separates, von Ihrem Konfigurations-Volume getrenntes Volume. Außerdem sollte jede Eingabe mit ihrem eigenen Verzeichnis oder Volume isoliert werden, um Konflikte zu vermeiden.

Beispielkonfiguration: Laufwerkzwischenspeicherung

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

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

Filter für reguläre Ausdrücke festlegen

Mit Filtern für reguläre Ausdrücke können Sie Logs basierend auf Übereinstimmungen regulärer Ausdrücke mit Rohlogs filtern.

Für die Filter wird die syntax verwendet.

Die Filter müssen einen regulären Ausdruck enthalten und optional ein Verhalten definieren, wenn eine Übereinstimmung besteht. Das Standardverhalten für eine Übereinstimmung ist „block“. Sie können sie auch explizit als Block konfigurieren.

Alternativ können Sie Filter mit dem Verhalten allow angeben. Wenn Sie allow-Filter angeben, blockiert der Chronicle-Forwarder alle Logs, die nicht mindestens einem allow-Filter entsprechen.

Sie können eine beliebige Anzahl von Filtern definieren. Sperrfilter haben Vorrang vor allow-Filtern.

Wenn Filter definiert sind, muss ihnen ein Name zugewiesen werden. Die Namen aktiver Filter werden Chronicle mithilfe von Forwarder-Zustandsmesswerten gemeldet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern zusammengeführt, die auf Collector-Ebene definiert wurden. Die Filter auf Collector-Ebene haben bei in Konflikt stehenden Namen Vorrang. Wenn auf Stamm- oder Collector-Ebene keine Filter definiert sind, werden alle zugelassen.

Beispielkonfiguration: Filter für reguläre Ausdrücke

In der folgenden Chronicle-Forwarder-Konfiguration werden die WINEVTLOG-Logs blockiert, die nicht mit dem Stammfilter (allow_filter) übereinstimmen. Bei dem regulären Ausdruck lässt der Filter nur Logs mit Prioritäten zwischen 0 und 99 zu. Alle NIX_SYSTEM-Logs, die „foo“ oder „bar“ enthalten, werden trotz 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 konfigurieren

Labels werden verwendet, um mithilfe von Schlüssel/Wert-Paaren beliebige Metadaten an Logs anzuhängen. Labels können für einen gesamten Chronicle-Forwarder oder innerhalb eines bestimmten Collectors eines Chronicle-Forwarders konfiguriert werden. Wenn beide angegeben sind, werden die Labels mit den Collector-Schlüsseln zusammengeführt und haben Vorrang vor den Schlüsseln des Chronicle-Forwarders, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration: beliebige Labels

In der folgenden Chronicle-Forwarder-Konfiguration sind die Schlüssel/Wert-Paare foo=bar und meow=mix an WINEVTLOG-Logs und die Schlüssel/Wert-Paare foo=baz und meow=mix an die NIX_SYSTEM-Logs angehängt.

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 konfigurieren

Verwenden Sie Namespace-Labels, um Logs von unterschiedlichen Netzwerksegmenten und sich überschneidende IP-Adressen zum Auflösen von Konflikten zu identifizieren. Sie können ein Namespace-Label für einen gesamten Chronicle-Forwarder oder innerhalb eines bestimmten Collectors des Chronicle-Forwarders konfigurieren. Wenn beide enthalten sind, hat der Namespace des jeweiligen Collectors Vorrang.

Jeder für den Chronicle-Forwarder konfigurierte Namespace wird mit den zugehörigen Assets in der Chronicle-Benutzeroberfläche angezeigt. Sie können auch mit der Chronicle-Suchfunktion nach Namespaces suchen.

Informationen zum Aufrufen von Namespaces in der Chronicle-Benutzeroberfläche finden Sie hier.

Beispielkonfiguration: Namespaces

In der folgenden Chronicle-Forwarder-Konfiguration sind die WINEVTLOG-Logs an den FORWARDER-Namespace und 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

Load-Balancing- und Hochverfügbarkeitsoptionen konfigurieren

Der Chronicle-Forwarder für Windows in Docker kann in einer Umgebung bereitgestellt werden, in der ein Layer-4-Load-Balancer zwischen der Datenquelle und den Chronicle-Forwarder-Instanzen installiert ist. So können Sie die Logsammlung auf mehrere Chronicle-Forwarder verteilen oder Logs an einen anderen Chronicle-Forwarder senden, wenn einer davon fehlschlägt. Diese Funktion wird nur mit dem Sammlungstyp „syslog“ unterstützt.

Der Chronicle-Forwarder für Windows in Docker enthält einen integrierten HTTP-Server, der auf HTTP-Systemdiagnosen des Load-Balancers reagiert. Der HTTP-Server sorgt auch dafür, dass Logs beim Starten oder Herunterfahren eines Chronicle-Forwarders nicht verloren gehen.

Konfigurieren Sie die Optionen für HTTP-Server, Load-Balancing und Hochverfügbarkeit im Abschnitt server der Konfigurationsdatei für Chronicle-Forwarder. Mit diesen Optionen können Sie Zeitlimits und Statuscodes festlegen, die als Antwort auf Systemdiagnosen zurückgegeben werden, die in Container-Planer- und orchestrierungsbasierten Bereitstellungen sowie von konventionellen Load-Balancern empfangen werden.

Verwende die folgenden URL-Pfade für Gesundheits-, Bereitschafts- und Aktivitätsprüfungen. Die <host:port>-Werte sind in der Chronicle-Forwarder-Konfiguration definiert.

http://<host:port>/meta/available: Aktivitätsprüfungen für Container-Planer/Orchestratoren wie Kubernetes
http://<host:port>/meta/ready: Bereitschaftsprüfungen und herkömmliche Systemdiagnosen des Load-Balancers

Die folgende Chronicle-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 Chronicle-Forwarder eine schlechte Bereitschafts-/Systemdiagnose zurückgibt und noch neue Verbindungen annimmt. Dies ist auch die Zeit, die zwischen dem Empfang eines Signals zum Anhalten und dem tatsächlichen Herunterfahren des Servers selbst gewartet werden muss. So hat der Load-Balancer Zeit, den Chronicle-Forwarder aus dem Pool zu entfernen.
Server: {8/}Drain_timeout	Die Zeit, die der Chronicle-Forwarder selbst auf das erfolgreiche Schließen aktiver Verbindungen wartet, bevor er vom Server geschlossen wird.
Server : http : Port	Die Portnummer, die der HTTP-Server auf Systemdiagnosen des Load-Balancers überwacht. Muss zwischen 1.024 und 65.535 liegen.
Server : http : Host	Die IP-Adresse oder der Hostname, der in IP-Adressen aufgelöst werden kann und die der Server überwachen soll. Wenn das Feld leer ist, wird der Standardwert das lokale System (0.0.0.0) verwendet.
Server : http : read_timeout	Wird zum Optimieren des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximale Zeit, die zum Lesen der gesamten Anfrage (Header und Text) zur Verfügung steht. Sie können sowohl read_timeout als auch read_header_timeout festlegen.
Server : http : read_header_timeout	Wird zum Optimieren des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximal zulässige Zeit zum Lesen von Anfrageheadern. Beim Lesen der Verbindung wird das Zeitlimit nach dem Lesen des Headers zurückgesetzt.
Server : http : write_timeout	Wird zum Optimieren des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximal zulässige Zeit zum Senden einer Antwort. Er wird zurückgesetzt, wenn ein neuer Anfrageheader gelesen wird.
Server : http : idall_timeout	Wird zum Optimieren des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht 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.
Routen : Meta : Bereit_Status	Der Statuscode, den der Chronicle-Forwarder zurückgibt, wenn er den Traffic in einer der folgenden Situationen annehmen kann: Die Bereitschaftsprüfung wird von einem Container-Planer oder -Orchestrator wie Kubernetes empfangen. Die Systemdiagnose wird von einem herkömmlichen Load-Balancer empfangen.
Routen : Meta : ungelesene_status	Der Statuscode, den der Chronicle-Forwarder zurückgibt, wenn er nicht bereit ist, Traffic anzunehmen.
Routen : Meta : verfügbar_status	Der Statuscode, den der Chronicle-Forwarder zurückgibt, wenn eine Aktivitätsprüfung empfangen wurde und der Chronicle-Forwarder verfügbar ist. Containerplaner/-orchestratoren wie Kubernetes senden häufig Aktivitätsprüfungen.