Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Forwarder unter Linux installieren und konfigurieren

In diesem Dokument wird beschrieben, wie Sie den Forwarder unter Linux installieren und konfigurieren. Informationen zum Installieren des Forwarders unter Windows finden Sie unter Windows-Forwarder.

Der Forwarder wird verwendet, um Logs aus der Kundenumgebung an die Chronicle-Instanz zu senden. Dies wird verwendet, wenn die Kunden die Logs direkt an Chronicle senden und die Cloud-Buckets nicht zum Aufnehmen von Daten verwenden möchten oder der Logtyp keine native Datenaufnahme über eine Drittanbieter-API hat. Der Forwarder kann als sofort einsetzbare Lösung verwendet werden, anstatt die Aufnahme-API manuell einzubinden.

Sie können den Forwarder unter einer Vielzahl von Linux-Distributionen installieren, darunter Debian, Ubuntu, Red Hat und Suse. Google Cloud stellt die Software mithilfe eines Docker-Containers bereit. Sie können den Docker-Container auf einer physischen oder virtuellen Maschine mit Linux ausführen und verwalten.

Systemanforderungen

Im Folgenden finden Sie allgemeine Empfehlungen. Spezifische Empfehlungen für Ihr System erhalten Sie vom Support von Chronicle.

  • RAM: 1 GB für jeden erfassten Datentyp. Beispielsweise sind Endpunkterkennung und -antwort (Endpoint Detection and Response, EDR), DNS und DHCP jeweils separate Datentypen. Sie benötigen 3 GB RAM, um Daten für alle drei zu erfassen.

  • CPU: 2 CPUs sind ausreichend,um weniger als 10.000 Ereignisse pro Sekunde (EPS) zu verarbeiten (insgesamt für alle Datentypen). Wenn Sie mehr als 10.000 EPS weiterleiten, müssen Sie 4 bis 6 CPUs bereitstellen.

  • Laufwerk: 100 MB Speicherplatz sind ausreichend, unabhängig davon, wie viele Daten der Chronicle-Forwarder verarbeitet. Wenn Sie Rückstandsnachrichten vom Laufwerk und nicht vom Arbeitsspeicher gepuffert werden müssen, finden Sie weitere Informationen unter Laufwerkzwischenspeicherung. Der Chronicle-Forwarder wird standardmäßig im Arbeitsspeicher gepuffert.

Firewallkonfiguration prüfen

Für alle Firewalls und authentifizierten Proxys zwischen dem Chronicle-Forwarder-Container und dem Internet sind Regeln erforderlich, um den Zugriff auf die folgenden Hosts zu öffnen:

Verbindungstyp Ziel Port
TCP malachiteingestion-pa.googleapis.com 443
TCP malachiteingestion-europe-backstory.googleapis.com 443
TCP malachiteingestion-asia-southeast1-backstory.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP storage.googleapis.com 443

Konfigurationsdateien anpassen

Wenden Sie sich an Ihren Chronicle-Ansprechpartner, um die Konfigurationsdateivorlagen zu erhalten.

Google Cloud passt die Konfigurationsdateien mit den im Ausgabebereich gezeigten Metadaten an die Forwarder-Instanz an. Sie können die Konfigurationsdateien entsprechend Ihren Anforderungen ändern und Informationen zu den Logtypen angeben, die im Collector-Abschnitt aufgenommen werden sollen. Wenn Sie weitere Informationen zu den Konfigurationseinstellungen benötigen, wenden Sie sich an den Chronicle-Support.

So konfigurieren Sie den Linux-Forwarder:

  1. Erstellen Sie eine Kopie der mit der Software bereitgestellten Konfigurationsdateivorlage.

  2. Speichern Sie die beiden Dateien gemäß der folgenden Namenskonvention im selben Verzeichnis:

    FORWARDER_NAME.conf: Mit dieser Datei definieren Sie die Konfigurationseinstellungen für die Logaufnahme.

    FORWARDER_NAME_auth.conf: Verwenden Sie diese Datei, um die Anmeldedaten für die Autorisierung zu definieren.

  3. Ändern Sie die Dateien so, dass sie die Konfiguration für Ihre Forwarder-Instanz enthalten. Verwenden Sie die in diesem Dokument enthaltenen Beispiele als Referenz.

  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, um die Daten korrekt zuzuordnen.

Beispielkonfiguration

Das folgende Codebeispiel zeigt das Format der Konfigurationsdateien für einen Forwarder. Weitere Informationen zu den Einstellungen für die verschiedenen Aufnahmemechanismen wie Splunk oder Syslog finden Sie unter Daten erfassen.

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

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"

Mit diesem zwei Dateisystem können Sie Anmeldedaten zur Authentifizierung in einer separaten Datei speichern. Sie können die Datei FORWARDER_NAME.conf in einem Repository für die Versionsverwaltung oder in einem beliebigen offenen Konfigurationsverwaltungssystem speichern. Sie können die Datei FORWARDER_NAME_auth.conf direkt in der physischen oder virtuellen Maschine speichern, auf der der Forwarder ausgeführt wird.

Beispielkonfiguration (einzelne 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
enable_auto_update: false

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

  1. Erstellen Sie eine Kopie Ihrer vorhandenen Konfiguration.
  2. Speichern Sie eine Datei als Datei FORWARDER_NAME.conf und löschen Sie die Anmeldedaten für die Autorisierung aus der Datei.
  3. Speichern Sie die andere Datei als Datei FORWARDER_NAME_auth.conf und löschen Sie alle Nicht-Autorisierungsdaten aus der Datei. Verwenden Sie die in diesem Leitfaden angegebenen Beispielkonfigurationsdateien als Referenz.
  4. Beachten Sie die Namenskonvention und andere Richtlinien, die im Abschnitt Konfigurationsdateien anpassen aufgeführt sind.

Docker installieren

Die Installation von Docker ist von der Hostumgebung abhängig. Sie können Docker auf verschiedenen Hostbetriebssystemen installieren. Google Cloud bietet eine eingeschränkte Dokumentation, die Sie bei der Installation von Docker auf einigen der beliebteren Linux-Distributionen unterstützt. Docker ist Open-Source-Software und alle erforderlichen Dokumentationen sind bereits verfügbar. Eine Anleitung zur Docker-Installation finden Sie in der Docker-Dokumentation.

Sobald Docker auf Ihrem System installiert ist, ist der Chronicle-Forwarder-Installationsprozess ähnlich wie bei jeder anderen Linux-Distribution.

Führen Sie den folgenden Befehl aus, um zu prüfen, ob Docker ordnungsgemäß auf Ihrem System installiert ist:

   docker ps
  

Die folgende Antwort gibt an, dass Docker ordnungsgemäß installiert wurde:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Weitere Informationen zur Docker-Installation können Sie mit dem folgenden Befehl abrufen:

    docker info
  

Wenn Sie Probleme mit Docker haben, kann das Chronicle-Supportteam die Ausgabe von diesem Befehl anfordern, um das Problem zu beheben.

Forwarder unter Linux installieren

In diesem Abschnitt wird beschrieben, wie Sie den Chronicle Forwarder mithilfe eines Docker-Containers auf einem Linux-System installieren.

Schritt 1: Forwarder-Konfigurationsdateien herunterladen, übertragen und installieren

Google Cloud bietet Konfigurationsdateien speziell für Ihr Betriebssystem (Linux oder Windows). Laden Sie die Dateien vom Link, den Sie von Ihrem Chronicle-Ansprechpartner erhalten haben, in ein lokales Verzeichnis auf Ihrem Laptop herunter (z. B. in ein Verzeichnis mit dem Namen „chronicle“). Nachdem Sie die folgenden Schritte ausgeführt haben, übertragen Sie die Konfigurationsdateien von Ihrem Laptop in das /opt/chronicle/config-Verzeichnis des Forwarders im Basisverzeichnis des Nutzers.

  1. Stellen Sie über das Terminal eine Verbindung zum Host des Linux-Forwarders her.

  2. Erstellen Sie einen neuen Nutzer auf dem Host des Linux-Forwarders.

      adduser USERNAME
      passwd USERNAME
      usermod -aG wheel USERNAME
    

  3. Wechseln Sie in das Basisverzeichnis des neuen Nutzers, der den Docker-Container ausführt.

  4. Erstellen Sie ein Verzeichnis zum Speichern der Chronicle-Forwarder-Konfigurationsdateien:

      mkdir /opt/chronicle/config
    

  5. Wechseln Sie das Verzeichnis.

      cd /opt/chronicle/config
    

  6. Prüfen Sie nach der Übertragung, ob sich die Konfigurationsdateien im Verzeichnis /opt/chronicle/config befinden:

      ls -l
    

Schritt 2: Forwarder im Docker-Container ausführen

Mit den folgenden Verfahren können Sie den Chronicle-Forwarder zum ersten Mal starten und ein Upgrade auf die neueste Version des Chronik-Containers ausführen:

Die Optionen für --log-opt sind seit Docker 1.13 verfügbar. Diese Optionen begrenzen die Größe der Container-Logdateien und müssen verwendet werden, solange Ihre Version von Docker sie unterstützt.

  1. Wenn Sie ein Upgrade ausführen, bereinigen Sie zuerst alle vorherigen Docker-Ausführungen. Im folgenden Beispiel lautet der Name des Docker-Containers cfps. Rufen Sie mit dem Befehl docker pull wie unten gezeigt das aktuelle Docker-Image von Google Cloud ab.

    docker stop cfps
    
    docker rm cfps
    
  2. Rufen Sie das aktuelle Docker-Image von Google Cloud ab:

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

Forwarder deinstallieren

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

So beenden oder deinstallieren Sie den Forwarder-Container:

    docker stop cfps
  

So entfernen Sie den Forwarder-Container:

    docker rm cfps
  

Forwarder aktualisieren

Der Chronicle-Forwarder besteht aus zwei Teilen und wird wie folgt aktualisiert:

  • Forwarder-Bundle: Es wird automatisch aktualisiert und es ist kein Neustart erforderlich.

  • Forwarder Docker-Image: Wird manuell aktualisiert, nachdem der vorhandene Forwarder beendet und eine neue Instanz gestartet wurde (siehe Schritt 2).

Daten erheben

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

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 zum Generieren von Daten für jeden der erforderlichen Datentypen (z. B. index=dns).

Sie müssen die Anmeldedaten für das Splunk-Konto dem Chronicle-Forwarder zur Verfügung stellen. Dazu erstellst du eine creds.txt-Datei oder fügst im Feld splunk-Einstellungen deiner Datei FORWARDER_NAME_auth.conf die Felder user und password hinzu. In den folgenden beiden Verfahren wird jede Methode beschrieben. Verwenden Sie nur eine Methode. Es wird empfohlen, die Datei FORWARDER_NAME_auth.conf zu verwenden.

Wenn Sie die Datei FORWARDER_NAME_auth.conf verwenden möchten, fügen Sie die Felder user und password in den Abschnitt splunk der Datei FORWARDER_NAME_auth.conf ein (siehe unten).

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:
  - 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: 10
      maximum_window_size: 30
      user: myusername
      password: mypassword
      query_string: search index=* sourcetype=dns
      query_mode: realtime

minimum_window_size:Der Mindestzeitraum, der an die Splunk-Abfrage übergeben wird. Der Standardwert beträgt 10 Sekunden. Dieser Parameter wird zur Feinabstimmung verwendet, wenn festgelegt werden muss, wie oft der Splunk-Server abgefragt wird, wenn der Forwarder im stabilen Zustand ist. Außerdem kann der Splunk API-Aufruf bei einer Verzögerung mehrmals erfolgen.

maximum_window_size: Der maximale Zeitraum, der an die Splunk-Abfrage übergeben wird. Der Standardwert beträgt 30 Sekunden. Dieser Parameter wird für die Abstimmung in Fällen verwendet, in denen es zu einer Verzögerung kommt oder wenn pro Abfrage mehr Daten erforderlich sind.

Ändern Sie diesen Parameter (gleich oder größer als), wenn Sie den Parameter „min“ ändern. Verzögerungsfälle können auftreten, wenn ein Splunk-Abfrageaufruf länger dauert als die maximale Größe von (window_size).

query_mode: Es gibt nur einen gültigen Wert: realtime. Weitere Informationen zu Echtzeitsuchen in Splunk finden Sie in der Splunk-Dokumentation.

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. Kunden, die mit dem Chronicle-Forwarder auf eine Splunk-Instanz zugreifen, kopieren die Datei creds.txt in das Konfigurationsverzeichnis, also im selben Verzeichnis, in dem sich die Konfigurationsdateien befinden. Beispiel:

    cp creds.txt /opt/chronicle/config/creds.txt
    
  4. Prüfen Sie, ob sich die Datei creds.txt am richtigen Speicherort befindet:

    ls /opt/chronicle/config
    

Syslog-Daten erfassen

Der Chronicle-Forwarder kann als Syslog-Server verwendet werden. Sie können jede Appliance oder jeden Server konfigurieren, die Syslog-Daten über eine TCP- oder UDP-Verbindung sendet, um deren Daten an den Chronicle-Forwarder weiterzuleiten. Sie können die genauen Daten steuern, die die Appliance oder der Server an die Chronikweiterleitung sendet. Der Chronicle-Forwarder kann dann die Daten an Chronicle weiterleiten.

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

rsyslog konfigurieren

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

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

  • UDP-Log-Traffic: 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 Chronicle-Forwarder-Konfigurationsdatei (FORWARDER_NAME.conf) den Speicherort Ihres eigenen generierten Zertifikats und Zertifikatsschlüssels an, wie im folgenden Beispiel gezeigt:

Zertifikat „/opt/chronicle/external/certs/client_generated_cert.pem“
Zertifikatschlüssel „/opt/chronicle/external/certs/client_generated_cert.key“

Ändern Sie anhand des folgenden Beispiels die Chronicle-Forwarder-Konfigurationsdatei (FORWARDER_NAME.conf) 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: "/opt/chronicle/external/certs/client_generated_cert.pem"
  certificate_key: "/opt/chronicle/external/certs/client_generated_cert.key"
  minimum_tls_version: "TLSv1_3"

Wichtige Hinweise:

  • Sie können die TCP-Puffergröße konfigurieren. Die Standardgröße für TCP-Zwischenspeicher beträgt 64 KB.

  • Der empfohlene Standardwert für connection_timeout beträgt 60 Sekunden. Die TCP-Verbindung wird beendet, wenn die Verbindung für eine bestimmte Zeit inaktiv ist.

  • Die minimale TLS-Version wird mit der TLS-Version der Eingabeanfrage abgeglichen. Die TLS-Version der Eingabeanfrage sollte älter als die TLS-Mindestversion sein. Die TLS-Mindestversion sollte einer der folgenden Werte sein: TLSv1_0, TLSv1_1, TLSv1_2, TLSv1_3.

Sie können unter dem Konfigurationsverzeichnis ein Zertifikatverzeichnis erstellen und die Zertifikatsdateien dort speichern.

Dateidaten erfassen

Verwenden Sie diese Option, wenn Sie Logs aus einer einzelnen Protokolldatei manuell hochladen möchten. Dies kann zum Backfill von Logs für eine bestimmte Logdatei verwendet werden.

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

  docker run \
    --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/falconhoseclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Dieser Docker-Ausführungsbefehl ist wichtig, um das Ladevolumen dem Container zuzuordnen.

Basierend auf diesem Beispiel sollten Sie die Chronicle-Forwarder-Konfiguration (FORWARDER_NAME.conf-Datei) so ändern:

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

Paketdaten erfassen

Der Chronicle-Forwarder kann Pakete mit libcap unter Linux direkt von einer Netzwerkschnittstelle erfassen. Weitere Informationen zu libcap finden Sie auf der Seite libcap.

Pakete werden anstelle von Logeinträgen an Chronicle gesendet. Die Paketerfassung erfolgt nur über eine lokale Schnittstelle. Wenn Sie die Paketerfassung für Ihr System aktivieren möchten, wenden Sie sich an den Chrome Enterprise-Support.

Google Cloud konfiguriert den Chronicle-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-Paketfilter.

Daten aus dem Kafka-Thema erfassen

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

Weitere Informationen zu Kafka-Nutzergruppen finden Sie hier: https://docs.confluent.io/platform/current/clients/consumer.html

Beispielkonfiguration: Kafka-Eingabe

Die folgende Forwarder-Konfiguration zeigt, wie der Forwarder eingerichtet wird, um Daten aus den Kafka-Themen aufzunehmen.

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

Datei FORWARDER_NAME_auth.conf

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

Optionale Konfigurationen anpassen

Datenkomprimierung ein-/ausschalten

Durch die Logkomprimierung wird die Nutzung der Netzwerkbandbreite beim Übertragen von Logs an Chronik reduziert. Die Komprimierung kann jedoch zu einer erhöhten CPU-Auslastung führen. Der Kompromiss zwischen CPU-Nutzung und Bandbreite hängt von vielen Faktoren ab, einschließlich der Art der Logdaten, der Komprimierung der Daten, der Verfügbarkeit von CPU-Zyklen auf dem Host, auf dem der Forwarder ausgeführt wird, und der Notwendigkeit, die Netzwerkbandbreite zu reduzieren.

Beispielsweise werden textbasierte Logs gut komprimiert und können bei geringer CPU-Auslastung erhebliche Einsparungen bei der Bandbreite erzielen. Verschlüsselte Nutzlasten von Rohpaketen werden jedoch nicht gut komprimiert und führen zu einer höheren CPU-Auslastung.

Die Protokollkomprimierung ist standardmäßig deaktiviert. Das Aktivieren der Logkomprimierung kann den Bandbreitenverbrauch reduzieren. Das Aktivieren der Logkomprimierung kann jedoch auch die CPU-Auslastung erhöhen. Beachten Sie die Vor- und Nachteile.

Setzen Sie das Feld komprimierung in der Konfigurationsdatei von Chronicle-Forwarder auf true, um die Protokollkomprimierung zu aktivieren:

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

Laufwerkszwischenspeicher konfigurieren

Mit der Zwischenspeicherung von Laufwerken können Sie im Rückstand liegende Nachrichten auf dem Laufwerk und nicht im Arbeitsspeicher speichern. Die im Rückstand befindlichen Nachrichten können für den Fall gespeichert werden, dass der Forwarder abstürzt oder der zugrunde liegende Host abstürzt. Das Aktivieren der Zwischenspeicherung von Laufwerken kann sich auf die Leistung auswirken.

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

Wenn Sie den Forwarder mit Docker ausführen, empfiehlt Google zu Isolationszwecken ein Volume, das von Ihrem Konfigurations-Volume getrennt ist. Außerdem sollte jede Eingabe mit einem eigenen Verzeichnis oder eigenen 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
      # /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 festlegen

Mit Filtern für reguläre Ausdrücke können Sie Logs anhand von Übereinstimmungen mit regulären Ausdrücken nach Rohlogs filtern.

Die Filter verwenden die hier beschriebene RE2-Syntax: https://github.com/google/re2/wiki/Syntax

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

Alternativ können Sie Filter mit dem Verhalten allow angeben. Wenn Sie 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. Blockfilter haben Vorrang vor allow-Filtern.

Wenn Filter definiert sind, muss ihnen ein Name zugewiesen werden. Die Namen der aktiven Filter werden über Forwarder-Statusmesswerte an Chronicle gemeldet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern zusammengeführt, die auf Collector-Ebene definiert sind. Bei in Konflikt stehenden Namen haben Filter auf Collector-Ebene Vorrang. Wenn auf Stamm- oder Collector-Ebene keine Filter definiert sind, werden alle Filter zugelassen.

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

In der folgenden Forwarder-Konfiguration werden die WINEVTLOG-Logs blockiert, die nicht mit dem Stammfilter (allow_filter) übereinstimmen. Aufgrund des regulären Ausdrucks erlaubt der Filter nur Logs mit Prioritäten zwischen 0 und 99. NIX_SYSTEM-Logs, die „foo“ oder „bar“ enthalten, werden jedoch trotz allow_filter blockiert. Das liegt daran, dass die Filter ein logisches OR 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 Forwarder oder innerhalb eines bestimmten Collectors eines Forwarders konfiguriert werden. Wenn beide angegeben werden, werden die Labels mit den Collector-Schlüsseln zusammengeführt und haben Vorrang vor den Forwardern-Schlüsseln, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration: beliebige Labels

In der folgenden Forwarder-Konfiguration sind die Schlüssel/Wert-Paare „foo=bar“ und „meow=mix“ beide an WINEVTLOG-Logs angehängt und die Schlüssel-/Wert-Paare „foo=baz“ und „meow=mix“ sind 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 aus verschiedenen Netzwerksegmenten zu identifizieren und sich überschneidende IP-Adressen abzuheben. Sie können ein Namespace-Label für einen gesamten Forwarder oder innerhalb eines bestimmten Collectors des Forwarders konfigurieren. Wenn beide enthalten sind, hat der Namespace des spezifischen Collectors Vorrang.

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

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

Beispielkonfiguration: Namespaces

In der folgenden Forwarder-Konfiguration werden 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 konfigurieren

Der Chronicle-Forwarder für Linux kann in einer Umgebung bereitgestellt werden, in der ein Layer-4-Load-Balancer zwischen der Datenquelle und den Forwarder-Instanzen installiert ist. Dadurch kann ein Kunde die Logsammlung auf mehrere Forwarder verteilen oder Logs an einen anderen Forwarder senden, wenn einer fehlschlägt. Dieses Feature wird nur für den Syslog-Sammlungstyp unterstützt.

Der Linux-Forwarder enthält einen integrierten HTTP-Server, der auf HTTP-Systemdiagnosen vom Load-Balancer reagiert. Der HTTP-Server sorgt auch dafür, dass Logs beim Start oder Herunterfahren eines Forwarders nicht verloren gehen.

Konfigurieren Sie die Optionen für HTTP-Server, Load-Balancing und Hochverfügbarkeit im Abschnitt server der Weiterleitungskonfigurationsdatei. Diese Optionen unterstützen das Festlegen von Zeitüberschreitungszeiten und Statuscodes, die als Antwort auf Systemdiagnosen zurückgegeben werden, die in Container-Planer- und Orchestrierungsbasierten Bereitstellungen sowie von traditionellen Load-Balancern empfangen werden.

Verwende die folgenden URL-Pfade für Gesundheits-, Tagesform- 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-Planer/Orchestratoren wie Kubernetes.
  • http://<host:port>/meta/ready: Bereitschaftsprüfungen und herkömmliche Systemdiagnosen für den 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 : race_timeout Die Zeitspanne, in der der Forwarder eine schlechte Bereitschafts- oder Systemdiagnose zurückgibt und weiterhin neue Verbindungen akzeptiert. Dies ist auch die Zeit, die zwischen dem Empfang eines Signals zum Stoppen und dem tatsächlichen Herunterfahren des Servers gewartet werden muss. Dadurch hat der Load-Balancer Zeit, den Forwarder aus dem Pool zu entfernen.
Server : per Drain beenden Die Zeit, die der Forwarder wartet, bis aktive Verbindungen erfolgreich geschlossen wurden, bevor er vom Server geschlossen wird.
Server : http : Port Die Portnummer, die der HTTP-Server auf Systemdiagnosen des Load-Balancers überwacht. Muss zwischen 1024 und 65535 liegen.
Server : http : host Die IP-Adresse oder der Hostname, die in IP-Adressen aufgelöst werden kann, die der Server überwachen soll. Wenn das Feld leer ist, gilt der Standardwert für das lokale System (0.0.0.0).
Server : http : read_timeout Wird zur Feinabstimmung des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximale Zeit, die die gesamte Anfrage gelesen werden kann, sowohl der Header als auch der Text. Sie können sowohl read_timeout als auch read_header_timeout festlegen.
Server : http : read_header_timeout Wird zur Feinabstimmung des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximal zulässige Zeit zum Lesen von Anfrageheadern. Das Zeitlimit für die Verbindung von Lesevorgängen wird nach dem Lesen des Headers zurückgesetzt.
Server : http : write_timeout Wird zur Feinabstimmung des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximal zulässige Zeit zum Senden einer Antwort. Sie wird zurückgesetzt, wenn ein neuer Anfrageheader gelesen wird.
server : http : id_timeout Wird zur Feinabstimmung des HTTP-Servers verwendet. In der Regel muss die Standardeinstellung nicht geändert werden. Die maximale Zeit, die auf die nächste Anfrage gewartet wird, wenn inaktive Verbindungen aktiviert sind. Wenn der Wert für „id-timeout“ null ist, wird der Wert von „read_timeout“ verwendet. Wenn beide Nullen sind, wird „read_header_timeout“ verwendet.
Routen : meta : ready_status Der Statuscode, den der Forwarder zurückgibt, wenn er in einer der folgenden Situationen den Traffic akzeptieren 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 : ungeleseny_status Der Statuscode, den der Forwarder zurückgibt, wenn er nicht zum Annehmen von Traffic bereit ist.
Routen : meta : available_status Der Statuscode, den der Forwarder zurückgibt, wenn eine Aktivitätsprüfung empfangen und der Forwarder verfügbar ist. Container-Planer/-Orchestratoren wie Kubernetes senden häufig Aktivitätsprüfungen.

Häufig gestellte Fragen

Wie aktualisiere ich meinen Forwarder?

Der Windows-Forwarder wird nicht ständig aktualisiert, da ihn nur wenige Kunden nutzen. Der Linux-Forwarder wird ständig über ein Shell-Skript im Docker-Image aktualisiert, sodass Sie keine ausführbare Datei angeben müssen. Wenn ein Kunde jedoch eine Supportanfrage öffnet, um die neueste ausführbare Windows-Datei für den Forwarder abzurufen, stellt das Supportteam dem Kunden über das Supportportal eine EXE-Datei zur Verfügung.

Was ist ein Docker-Container?

  • Docker-Container sind wie virtuelle Maschinen und bieten zusätzliche Sicherheit, Isolation und Ressourcenverwaltung.

  • Virtuelle Maschinen haben sowohl einen privilegierten Bereich (Linux-Kernel) als auch einen Nutzerbereich (alle Elemente, mit denen Sie interagieren): libc, python, ls, tcpdump usw.

  • Container: Sie haben nur einen Nutzerbereich, mit dem Sie interagieren, z. B. libc, python, ls, tcpdump, und den Berechtigungsbereich des Hosts.

Warum Chronicle-Forwarder mithilfe eines Containers verteilen?

  • Mehr Sicherheit durch Isolierung:
    • Die Kundenumgebung und die Anforderungen wirken sich nicht auf den Chronicle-Forwarder aus.
    • Chronicle-Forwarder-Umgebung und -Anforderungen wirken sich nicht auf den Kunden aus.
    • Es gibt bereits einen Mechanismus zur Containerverteilung, der für Google Cloud und Kunden privat und separat sein kann. https://cloud.google.com/container-registry/

Warum nur Linux für Container? Was ist mit Windows?

  • Container wurden zuerst für Linux entwickelt und sind produktionsreif.

  • Windows-Unterstützung für Container wird ausgeführt. Container sind für Windows Server 2016 und Windows 10 verfügbar.

Möchten Sie erweiterte Docker-Befehle lernen?

  • Der Chronicle-Forwarder verwendet einen einzelnen Container, sodass Sie sich nicht mit Schwarm, Orchestrierung, Kubernetes oder anderen erweiterten Docker-Konzepten oder -Befehlen vertraut machen müssen.