Chronicle-Forwarder für Linux

In diesem Dokument wird beschrieben, wie der Forwarder unter Linux installiert und konfiguriert wird. Informationen zum Installieren des Forwarders unter Windows finden Sie hier.

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

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

Systemanforderungen

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

  • RAM: 1 GB für jeden erfassten Datentyp (Collector), den Chronicle für die Aufnahme akzeptiert. Wenn Sie beispielsweise vier verschiedene Collectors angegeben haben, benötigen Sie 4 GB RAM, um Daten für alle vier Collectors zu erfassen.

  • CPU: 2 CPUs reichen für die Verarbeitung von weniger als 10.000 Ereignissen pro Sekunde (EPS) aus (insgesamt für alle Datentypen). Wenn Sie voraussichtlich mehr als 10.000 EPS weiterleiten, stellen Sie 4 bis 6 CPUs bereit.

  • Laufwerk: 100 MB Speicherplatz sind ausreichend, unabhängig davon, wie viele Daten der Chronicle-Forwarder verarbeitet. Wenn Sie zurückgestellte Nachrichten auf dem Laufwerk statt auf dem Arbeitsspeicher zwischenspeichern müssen, finden Sie weitere Informationen unter Laufwerkszwischenspeicherung. Der Chronicle-Forwarder puffert standardmäßig im Arbeitsspeicher.

Google-IP-Adressbereiche

Möglicherweise muss der IP-Adressbereich beim Einrichten einer Forwarder-Konfiguration geöffnet werden, z. B. bei der Konfiguration Ihrer Firewall. Google kann keine spezifische Liste von IP-Adressen zur Verfügung stellen. Sie können jedoch IP-Adressbereiche von Google abrufen.

Firewallkonfiguration prüfen

Für alle Firewalls oder authentifizierten Proxys zwischen dem Chronicle-Forwarder-Container und dem Internet sind Regeln erforderlich, um den Zugriff auf die folgenden Hosts zu 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

Konfigurationsdateien anpassen

Google Cloud passt die Konfigurationsdateien an die Forwarder-Instanz mit bestimmten Metadaten an, wie im Ausgabeabschnitt gezeigt. Sie können die Konfigurationsdatei entsprechend Ihren Anforderungen herunterladen und im Collectors-Bereich Informationen zu den Logtypen angeben, die aufgenommen werden sollen. Weitere Informationen

Linux-Forwarder konfigurieren

Informationen zum Konfigurieren des Linux-Forwarders über die Benutzeroberfläche finden Sie unter Forwarder-Konfigurationen über die Chronicle-UI verwalten.

So konfigurieren Sie den Linux-Forwarder manuell:

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

  2. Laden Sie die Konfigurationsdatei über die UI herunter.

  3. Speichern Sie die beiden Dateien unter Verwendung der folgenden Namenskonvention im selben Verzeichnis:

    FORWARDER_NAME.conf: Verwenden Sie diese Datei, um die Konfigurationseinstellungen für die Logaufnahme zu definieren.

    FORWARDER_NAME_auth.conf: Definieren Sie mit dieser Datei die Anmeldedaten für die Autorisierung.

  4. Passen Sie die Dateien so an, dass sie die Konfiguration für Ihre Forwarder-Instanz enthalten. Verwenden Sie die in diesem Dokument bereitgestellten Beispiele als Referenz.

  5. 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 für die korrekte Zuordnung der Daten erforderlich.

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

Beispielkonfiguration

Das folgende Codebeispiel zeigt das Format der Konfigurationsdateien für einen Forwarder. Details zu den Einstellungen für die einzelnen Arten von Aufnahmemechanismen, z. B. 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

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"

Mit diesem beiden Dateisystem können Sie die Anmeldedaten für die Authentifizierung zur Verbesserung der Sicherheit in einer separaten Datei speichern. Sie können die Datei FORWARDER_NAME.conf in einem Repository zur Versionsverwaltung oder 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

Wenn Sie eine einzelne Konfigurationsdatei verwenden und zu den beiden Dateisystemen wechseln möchten, gehen Sie so vor:

  1. Erstellen Sie eine Kopie der vorhandenen Konfiguration.
  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 Datei FORWARDER_NAME_auth.conf und löschen Sie alle Nicht-Autorisierungsdaten aus der Datei. Verwenden Sie die in diesem Handbuch bereitgestellten 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 hängt von der Hostumgebung ab. Sie können Docker auf verschiedenen Host-Betriebssystemen installieren. Google Cloud bietet eine eingeschränkte Dokumentation, die Sie bei der Installation von Docker auf mehreren der beliebteren Linux-Distributionen unterstützt. Docker ist jedoch Open Source und die erforderliche Dokumentation ist bereits verfügbar. Eine Anleitung zur Docker-Installation finden Sie in der Docker-Dokumentation.

Sobald Docker auf Ihrem System installiert ist, ähnelt der Installationsprozess für Chronicle-Forwarder dem Installationsprozess jeder Art von Linux-Distribution.

Mit dem folgenden Befehl (erhöhte Berechtigungen) können Sie prüfen, ob Docker korrekt 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

Nützliche Docker-Befehle

  • Mit dem folgenden Befehl können Sie zusätzliche Informationen zur Docker-Installation abrufen:

    docker info

  • Der Docker-Dienst könnte standardmäßig deaktiviert sein. Prüfen Sie mit dem folgenden Befehl, ob sie deaktiviert ist:

    systemctl is-enabled docker

  • Führen Sie einen der folgenden Befehle aus, um den Docker-Dienst zu aktivieren und sofort zu starten:

    sudo systemctl enable --now docker

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

    Ausgabe:

    Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service

  • Wenn Sie einen Forwarder starten, führen Sie den folgenden Befehl aus, um den Forwarder auf automatischen Neustart einzustellen:

    sudo docker run --restart=always `IMAGE_NAME`

    IMAGE_NAME ist der Name des Forwarder-Images.

  • Führen Sie den folgenden Befehl aus, um den Status und die Details des Docker-Dienstes zu prüfen:

    sudo systemctl status docker

    Ausgabe:

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

    Bei Problemen mit Docker 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 Chronicle Forwarder mit einem Docker-Container auf einem Linux-System installieren.

Schritt 1: Konfigurationsdateien für Forwarder herunterladen, übertragen und installieren

Chronicle bietet Forwarder-Konfigurationsdateien speziell für Ihr Betriebssystem (Linux oder Windows). Sie können die Konfigurationsdatei herunterladen. Übertragen Sie nach Abschluss der folgenden Schritte die Konfigurationsdateien von Ihrem Laptop in das /opt/chronicle/config-Forwarder-Verzeichnis 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. Ändern Sie das Verzeichnis in das Basisverzeichnis des neuen Nutzers, der den Docker-Container ausführt.

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

      mkdir /opt/chronicle/config

  5. Wechseln Sie das Verzeichnis. 

      cd /opt/chronicle/config

  6. Prüfen Sie nach der Übertragung der Dateien, ob sie sich 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 auf die neueste Version des Chronicle-Containers upgraden:

Die --log-opt-Optionen sind seit Docker 1.13 verfügbar. Diese Optionen begrenzen die Größe der Containerlogdateien 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 das neueste Docker-Image von Google Cloud ab, wie unten gezeigt.

    docker stop cfps

    docker rm cfps

  2. Laden Sie das aktuelle Docker-Image von Google Cloud herunter:

    docker pull gcr.io/chronicle-container/cf_production_stable

  3. Starten Sie Chronicle-Forwarder über den 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-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

Forwarder deinstallieren

Mit den folgenden Docker-Befehlen können Sie den Chronicle-Forwarder beenden, 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 so aktualisiert:

  • Forwarder Bundle: Wird automatisch aktualisiert und ein Neustart ist nicht erforderlich.

  • Forwarder-Docker-Image: Wird manuell aktualisiert, nachdem der vorhandene Forwarder beendet und eine neue Instanz gestartet wurde, wie in Schritt 2 beschrieben.

Forwarder hinter einem Proxy installieren

In diesem Abschnitt wird beschrieben, wie Sie den Chronicle-Forwarder hinter einem Proxy installieren.

  1. Konfigurieren Sie Ihren Computer für die Verwendung des Proxys.

    1. Fügen Sie der Datei /etc/resolv.conf die folgenden Zeilen hinzu:

      nameserver = 10.0.0.1
nameserver = 10.0.0.2

    2. Legen Sie die folgenden Umgebungsvariablen fest:

      $HTTP_PROXY = http://proxy.example.com:80
$HTTPS_PROXY = https://proxy.example.com:80

  2. Konfigurieren Sie Docker für die Verwendung des Proxys.

    1. Erstellen Sie ein systemd-Drop-in-Verzeichnis für den Docker-Dienst.

      mkdir /etc/systemd/system/docker.service.d

    2. Erstellen Sie eine Datei /etc/systemd/system/docker.service.d/http-proxy.conf, in der die Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY hinzugefügt werden.

      [Service]
Environment="HTTP_PROXY=http://proxy.example.com:80/"
Environment="HTTPS_PROXY=https://proxy.example.com:80/"

    3. Leeren Sie die Änderungen.

      $ sudo systemctl daemon-reload

    4. Prüfen Sie, ob die Konfiguration geladen wurde.

      $ sudo systemctl show --property Environment docker
Environment=HTTP_PROXY=http://proxy.example.com:80/
Environment=HTTPS_PROXY=https://proxy.example.com:80/

    5. Starten Sie Docker neu.

      $ sudo systemctl restart docker

  3. Holen Sie sich das neueste Docker-Image für Chronicle-Forwarder von Google Cloud.

    docker pull gcr.io/chronicle-container/cf_production_stable

  4. Führen Sie den Chronicle-Forwarder-Container aus, indem Sie Proxy-Umgebungsvariablen hinzufügen.

    docker run \
--env HTTP_PROXY="http://proxy.example.com:80/" \
--env HTTPS_PROXY="https://proxy.example.com:80/" \
--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

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.

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:

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

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 Zertifikatschlüssels an, wie im folgenden Beispiel gezeigt:

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

Ändern Sie anhand des gezeigten 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"

Einige wichtige Punkte, die Sie beachten sollten:

  • 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“ beträgt 60 Sekunden. Die TCP-Verbindung wird beendet, wenn sie für eine bestimmte Zeit inaktiv war.

  • 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 \
    --net=host \
    -v /opt/chronicle/config:/opt/chronicle/external \
    -v /var/log/crowdstrike/falconhostclient:/opt/chronicle/edr \
     gcr.io/chronicle-container/cf_production_stable

Dieser Befehl zum Ausführen von Docker 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: /opt/chronicle/edr/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 libcap unter Linux direkt von einer Netzwerkschnittstelle erfassen. Weitere Informationen zu libcap finden Sie auf der Seite libcap – Linux-Handbuch.

Pakete werden erfasst und anstelle von Logeinträgen an Chronicle gesendet. Die Paketerfassung erfolgt nur über eine lokale Schnittstelle. Wenden Sie sich an den Chronicle-Support, um die Paketerfassung für Ihr System zu aktivieren.

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

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 Forwarder bereitstellen und Daten aus demselben Kafka-Thema abrufen. Weitere Informationen finden Sie unter Kafka.

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

Beispielkonfiguration: Kafka-Eingabe

Die folgende Forwarder-Konfiguration zeigt, wie Sie den Forwarder einrichten, 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

Die Datei FORWARDER_NAME_auth.conf

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

WebProxy-Daten erfassen

Der Chronicle-Forwarder kann WebProxy-Daten mithilfe von libcap unter Linux direkt aus einer Netzwerkschnittstelle erfassen. Weitere Informationen zu libcap finden Sie auf der Seite libcap – Linux-Handbuch. Wenden Sie sich an den Support von Chronicle, um die WebProxy-Datenerfassung für Ihr System zu aktivieren.

Ändern Sie die Chronicle-Forwarder-Konfiguration (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

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 Forwarder ausgeführt wird, und der Notwendigkeit, die Netzwerkbandbreite zu reduzieren.

Textbasierte Logs werden beispielsweise gut komprimiert und können bei geringer CPU-Nutzung 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. Achten Sie auf die Abwägung.

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

Die Datei FORWARDER_NAME.conf

output:
  compression: true
    url: malachiteingestion-pa.googleapis.com:443
    identity:
      identity:
      collector_id: 10479925-878c-11e7-9421-10604b7cb5c1
      customer_id: ebdc4bb9-878b-11e7-8455-10604b7cb5c1
...

Die 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 für den Fall gespeichert werden, dass der Forwarder 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 Forwarder 1 GB Arbeitsspeicher (RAM) für jeden Protokolltyp (z. B. pro 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 Arbeitsspeichers 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 Forwarder mit Docker ausführen, empfiehlt Google zu Isolierungszwecken, ein vom Konfigurations-Volume getrenntes Volume bereitzustellen. 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
      # /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 basierend auf Übereinstimmungen regulärer Ausdrücke mit Rohlogs filtern.

In den Filtern wird die hier beschriebene RE2-Syntax verwendet: https://github.com/google/re2/wiki/Syntax

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 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 über Forwarder-Zustandsmesswerte 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 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 Forwarder oder innerhalb eines bestimmten Collectors eines 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 Forwarders, 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“ 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 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 Forwarder oder innerhalb eines bestimmten Collectors des Forwarders konfigurieren. Wenn beide enthalten sind, hat der Namespace des jeweiligen Collectors Vorrang.

Jeder für den 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 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 Linux kann in einer Umgebung bereitgestellt werden, in der ein Layer-4-Load-Balancer zwischen der Datenquelle und den Forwarder-Instanzen installiert ist. Auf diese Weise kann ein Kunde die Logsammlung auf mehrere Forwarder verteilen oder Logs an einen anderen Forwarder senden, wenn ein Forwarder fehlschlägt. Diese Funktion wird nur mit dem Sammlungstyp „syslog“ unterstützt.

Der Linux-Forwarder umfasst einen integrierten HTTP-Server, der auf HTTP-Systemdiagnosen des Load-Balancers antwortet. Der HTTP-Server sorgt auch dafür, dass Logs beim Starten oder Herunterfahren eines Forwarders nicht verloren gehen.

Konfigurieren Sie die Optionen für HTTP-Server, Load-Balancing und Hochverfügbarkeit im Abschnitt server der Forwarder-Konfigurationsdatei. 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 herkömmlichen Load-Balancern empfangen werden.

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

  • http://<host:port>/meta/available: Aktivitätsprüfungen auf Container-Planer oder Orchestratoren.
  • http://<host:port>/meta/ready: Bereitschaftsprüfungen und Systemdiagnosen herkömmlicher 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, die der Forwarder eine fehlerhafte 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 Forwarder aus dem Pool zu entfernen.
Server: {8/}Drain_timeout Die Zeit, die der 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 Forwarder zurückgibt, wenn er den Traffic in einer der folgenden Situationen annehmen kann:
  • Die Bereitschaftsprüfung wird von einem Containerplaner oder -orchestrator empfangen.
  • Die Systemdiagnose wird von einem herkömmlichen Load-Balancer empfangen.
Routen : Meta : ungelesene_status Der Statuscode, den der Forwarder zurückgibt, wenn er nicht für die Annahme von Traffic bereit ist.
Routen : Meta : verfügbar_status Der Statuscode, den der Forwarder zurückgibt, wenn eine Aktivitätsprüfung empfangen wird und der Forwarder verfügbar ist Containerplaner oder -orchestrierer senden häufig Aktivitätsprüfungen.

Häufig gestellte Fragen

Wie aktualisiere ich meinen Forwarder?

Der Linux-Forwarder wird kontinuierlich über ein Shell-Skript im Docker-Image aktualisiert. Führen Sie den Forwarder aus, um das Docker-Image zu aktualisieren.

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 (alles, mit dem Sie interagieren: libc, Python, ls, tcpdump usw.).

  • Container – haben nur einen Nutzerbereich (alles, mit dem Sie interagieren: libc, Python, ls, tcpdump usw.) und stützen sich auf den Berechtigungsbereich des Hosts.

Warum sollten Sie Chronicle-Forwarder mit einem Container verteilen?

  • 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.
    • Ein Mechanismus zur Containerverteilung ist bereits vorhanden und kann für Google Cloud und Kunden privat und separat sein. https://cloud.google.com/container-registry/

Warum nur Linux für Container? Wie sieht es mit Windows aus?

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

  • Windows-Unterstützung für Container läuft. Container sind für Windows Server 2016 und Windows 10 verfügbar.

Benötigen Sie erweiterte Docker-Befehle?

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