Weiterleitungs für Linux installieren und konfigurieren

In diesem Dokument wird beschrieben, wie der Forwarder unter Linux installiert und konfiguriert wird. Sie können den Forwarder auf verschiedenen Linux-Distributionen (Debian, Ubuntu, Red Hat, Suse usw.) installieren. Google Cloud stellt die Software mithilfe eines Docker-Containers bereit. Sie können den Docker-Container entweder auf einer physischen oder virtuellen Maschine mit Linux ausführen und verwalten.

Konfigurationsdateien anpassen

Auf der Grundlage der vor der Bereitstellung übermittelten Informationen stellt Google Cloud Ihnen die Weiterleitungssoftware und Konfigurationsdateien zur Verfügung. Google Cloud passt Ihre Konfigurationsdateien an die Weiterleitungsinstanz in Ihrem Netzwerk an. Wenn Sie die Konfiguration ändern müssen, wenden Sie sich an den Chronicle-Support.

Systemanforderungen

Unten finden Sie allgemeine Empfehlungen. Wenn Sie Empfehlungen für Ihr System haben, wenden Sie sich an den Chronicle-Support.

  • RAM: 1,5 GB für jeden erfassten Datentyp. Zum Beispiel sind Endpunkterkennung und -antwort (EDR), DNS und DHCP alle separaten Datentypen. Sie benötigen 4,5 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, stellen Sie 4 bis 6 CPUs bereit.

  • Laufwerk: 100 MB Festplattenspeicher sind ausreichend, unabhängig davon, wie viele Daten vom Chronicle-Forwarder verarbeitet werden. Weitere Informationen zur Pufferung von Laufwerken Der Chronicle-Forwarder speichert standardmäßig den Arbeitsspeicher.

Firewallkonfiguration überprüfen

Wenn sich zwischen dem Chronicle-Weiterleitungscontainer und dem Internet Firewalls oder authentifizierte Proxys befinden, sind für den Zugriff auf die folgenden Hosts Regeln erforderlich:

Verbindungstyp Bestimmungsort Port
TCP malachiteingestion-pa.googleapis.com 443
TCP accounts.google.com 443
TCP gcr.io 443
TCP oauth2.googleapis.com 443
TCP storage.googleapis.com 443

Splunk-Daten erfassen

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

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

  • Splunk-Abfragen, um Daten für jeden der erforderlichen Datentypen zu generieren (z. B. index=dns).

Sie müssen die Anmeldedaten für Ihr Splunk-Konto für den Chronicle-Forwarder verfügbar machen.

Erstellen Sie eine lokale Datei für Ihre Splunk-Anmeldedaten und nennen Sie sie creds.txt. Geben Sie Ihren Nutzernamen in die erste Zeile und das Passwort in die zweite Zeile ein:

  cat creds-file

  myusername
  mypassword

Kunden, die mit Chronicle-Forwarder auf eine Splunk-Instanz zugreifen, kopieren die creds.txt-Datei in das Konfigurationsverzeichnis (das Verzeichnis, in dem sich die Konfigurationsdateien befinden). Beispiel:

cp creds-file ~/config/creds.txt

Überprüfen Sie, ob sich die creds.txt-Datei auf dem richtigen Speicherort befindet:

ls ~/config

- 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: admin
      password: letmeinaA1!
      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 Abstimmung verwendet, wenn die Anforderung geändert werden soll, wie oft der Splunk-Server abgefragt wird, wenn sich der Forwarder im stabilen Zustand befindet. Bei einer Verzögerung kann der Splunk API-Aufruf mehrmals ausgeführt werden.

maximum_window_size: Der maximale Zeitraum, der an die Splunk-Abfrage übergeben wird. Der Standardwert beträgt 30 Sekunden. Er wird zur Abstimmung in Fällen verwendet, in denen Verzögerungen auftreten und bei denen mehr Daten pro Abfrage benötigt werden.

Ändern Sie diesen Parameter (gleich oder größer als) beim Ändern des Parameters „min“. Verzögerungsfälle können auftreten, wenn ein Splunk-Abfrageaufruf länger als die für „max_window_size“ dauert.

Docker installieren

Sie können Docker auf einer Vielzahl von Hostbetriebssystemen installieren. Die tatsächliche Installation von Docker hängt von der Hostumgebung ab. Google Cloud bietet eine begrenzte Dokumentation zur Installation von Docker auf mehreren gängigen Linux-Distributionen. Docker ist jedoch Open Source und eine umfassende Dokumentation ist bereits verfügbar.

Wenn Sie Docker auf Ihrem System installiert haben, läuft der Rest des Chronicle-Forward-Installationsvorgangs ab, unabhängig davon, welche Linux-Distribution Sie verwenden.

Prüfen Sie, ob Docker auf Ihrem System installiert ist. Führen Sie dazu den folgenden Befehl aus (Erhöhte Berechtigungen):

# docker ps

Die folgende Antwort gibt an, dass Docker korrekt installiert wurde:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Mit dem folgenden Befehl können Sie zusätzliche Informationen zu Ihrer Docker-Installation erfassen:

# docker info

Wenn Probleme mit Docker auftreten, kann der Chronicle-Support die Ausgabe von diesem Befehl zur Fehlerbehebung anfordern.

Weiterleitung einrichten

In diesem Abschnitt wird beschrieben, wie Sie Chronicle Forwarder mit einem Docker-Container auf einem Linux-System installieren.

Schritt 1: Weiterleitungsdateien herunterladen, übertragen und installieren

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

  1. Stellen Sie über das Terminal eine Verbindung zu Ihrem Linux-Weiterleiter her.

  2. Erstellen Sie einen neuen Nutzer im Linux-Weiterleiter.

    # 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, um die Chronicle-Forward-Konfigurationsdateien zu speichern: # mkdir ~/config

  5. Verzeichnis wechseln

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

    # ls -l

Schritt 2: Forwarder im Docker-Container ausführen

Sie können die folgenden Schritte verwenden, um Chronicle-Weiterleitung zum ersten Mal zu starten und ein Upgrade auf die neueste Version des Chronicle-Containers durchzuführen:

Die Option --log-opt ist seit Docker 1.13 verfügbar. Diese Optionen beschränken die Größe der Container-Logdateien und sollten verwendet werden, solange Ihre Version von Docker sie unterstützt.

  1. Wenn Sie ein Upgrade durchführen, bereinigen Sie zuerst alle vorherigen Docker-Ausführungen. Im folgenden Beispiel lautet der Name des Docker-Containers cfps. Rufen Sie dann das aktuelle Docker-Image aus Google Cloud mit dem #-Pull-Befehl von Docker 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 Chronicle-Weiterleitung vom Docker-Container:

    docker run \
    
      --detach \
    
      --name cfps \
    
      --restart=always \
    
      --log-opt max-size=100m \
    
      --log-opt max-file=10 \
    
      --net=host \
    
      -v ~/config:/opt/chronicle/external \
    
      gcr.io/chronicle-container/cf_production_stable
    

Diese Befehle werden auch als Shell-Skript namens run_docker_production_stable.sh bereitgestellt.

Der Docker-Container (und der Chronicle-Forwarder) bleiben nach dem Neustart des Systems bestehen.

Schritt 3: Forwarder überwachen und verwalten

Mit den folgenden Docker-Befehlen können Sie den Chronicle-Forwarder überwachen und verwalten:

  • Prüfen Sie, ob der Docker-Container ausgeführt wird:

    docker ps

  • Rufen Sie die Logs aus dem Container auf. Beachten Sie, dass dadurch ein beträchtliches Ausgabevolumen generiert werden kann. Dies ist jedoch für die Fehlerbehebung nützlich:

    docker logs cfps

  • So sehen Sie, was im Container ausgeführt wird:

    docker top cfps

  • So beenden Sie den Container:

    docker stop cfps

Syslog-Daten erfassen

Chronicle-Forwarder kann als Syslog-Server verwendet werden. Das bedeutet, dass Sie jede Appliance oder jeden Server so konfigurieren können, dass syslog-Daten über eine TCP- oder UDP-Verbindung gesendet werden, um deren Daten an Chronicle-Forwarder weiterzuleiten. Sie können genau steuern, welche Daten die Appliance oder der Server an die Chronicle-Weiterleitung sendet. Chronicle-Forwarder kann dann die Daten an Chronicle weiterleiten.

Die Konfigurationsdatei (von Google Cloud bereitgestellt) gibt an, welche Ports für jeden weitergeleiteten Datentyp ü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. Lesen Sie die Systemdokumentation zur richtigen Syntax. Die folgenden Beispiele zeigen eine rsyslog-Zielkonfiguration:

  • TCP-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-Weiterleitung aktivieren. Geben Sie in der Chronicle-Forward-Konfigurationsdatei den Speicherort Ihres eigenen generierten Zertifikats und Ihres Zertifikatschlü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"

Auf Grundlage des folgenden Beispiels würde die Chronicle-Weiterleitungskonfiguration so geändert werden:

  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"

Der Wert für Batch_n_Byte darf 5 MB nicht überschreiten.

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

Dateidaten erfassen

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 ~/config:/opt/chronicle/external \

    -v /var/log/crowdstrike/falconhoseclient:/opt/chronicle/edr \

     gcr.io/chronicle-container/cf_production_stable

Dieser Docker-Ausführungsbefehl ist entscheidend, um das Containervolumen dem Container zuzuordnen.

Basierend auf diesem Beispiel würden Sie die Chronicle-Weiterleitungskonfiguration 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

Chronicle-Forwarder kann Pakete direkt von einer Netzwerkschnittstelle mit libpcap unter Linux erfassen. Pakete werden nicht an Logeinträge gesendet, sondern 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 Berkeley-Packet-Filter-Ausdruck (BPF), der beim Erfassen von Paketen verwendet wird, z. B. Port 53 und nicht „localhost“.

Datenkomprimierung wechseln

Durch die Logkomprimierung wird der Verbrauch der Netzwerkbandbreite beim Übertragen von Logs in Chronicle reduziert. Die Komprimierung kann jedoch zu einer höheren CPU-Auslastung führen. Der Kompromiss zwischen CPU-Nutzung und Bandbreite ist von vielen Faktoren abhängig, einschließlich der Art der Logdaten, der Komprimierbarkeit dieser Daten, der Verfügbarkeit von CPU-Zyklen auf dem Host, der den Forwarder ausführt, und der Notwendigkeit einer Verringerung der Netzwerkbandbreite.

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

Die Logkomprimierung ist standardmäßig deaktiviert. Durch Aktivieren der Logkomprimierung kann der Bandbreitenverbrauch reduziert werden. Durch Aktivieren der Logkomprimierung kann jedoch auch die CPU-Auslastung erhöht werden. Beachten Sie den Kompromiss.

Wenn Sie die Protokollkomprimierung aktivieren möchten, setzen Sie das Feld komprimierung in der Chronicle-Weiterleitungsdatei auf true, wie im folgenden Beispiel gezeigt:

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
      secret_key: |
        {
          "type": "service_account",
...

Laufwerkspuffer

Durch die Pufferung von Laufwerken können Sie protokollierte Nachrichten auf dem Laufwerk anstatt auf dem Arbeitsspeicher zwischenspeichern. Die zurückgemeldeten Nachrichten können gespeichert werden, wenn der Forwarder oder der zugrunde liegende Host abstürzt. Beachten Sie, dass sich die Aktivierung der Zwischenspeicherung auf die Leistung auswirken kann.

Wenn Sie den Forwarder mit Docker ausführen, empfiehlt Google zur Isolierung, dass ein Volume getrennt von Ihrem Konfigurations-Volume bereitgestellt wird. Außerdem sollte jede Eingabe mit einem eigenen Verzeichnis oder Volume isoliert werden, um Konflikte zu vermeiden.

Beispielkonfiguration: Laufwerkszwischenspeicherung

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

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

Filter für reguläre Ausdrücke

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

Für die Filter wird die RE2-Syntax verwendet, die hier beschrieben ist: https://github.com/google/re2/wiki/Syntax

Die Filter müssen einen regulären Ausdruck enthalten und können optional eine Übereinstimmung definieren. Das Standardverhalten bei einer Übereinstimmung ist „Blockieren“. Sie können es auch explizit als Block konfigurieren.

Alternativ kannst du Filter mit dem Verhalten allow angeben. Wenn Sie beliebige 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 Zulassungsfiltern.

Wenn Filter definiert werden, muss ihnen ein Name zugewiesen werden. Die Namen aktiver Filter werden über Forwarder-Gesundheitsmesswerte an Chronicle gemeldet. Filter, die im Stammverzeichnis der Konfiguration definiert sind, werden mit Filtern auf Collector-Ebene zusammengeführt. In Konflikt stehende Namen haben Filter auf Collector-Ebene. 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 WINEVTLOG-Logs, die nicht mit dem Root-Filter (allow_filter) übereinstimmen, blockiert. Aufgrund des regulären Ausdrucks erlaubt der Filter nur Logs mit Prioritäten zwischen 0 und 99. Alle NIX_SYSTEM-Protokolle, die 'foo' oder 'bar' enthalten, werden 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

Mit Labels werden beliebige Metadaten mithilfe von Schlüssel/Wert-Paaren an Logs angehängt. 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, die Vorrang vor den Forwarder-Schlüsseln haben, wenn sich die Schlüssel überschneiden.

Beispielkonfiguration: beliebige Labels

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

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

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. Sind beide enthalten, hat der spezifische Collector-Namespace Vorrang.

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

Weitere Informationen zum Aufrufen von Namespaces in der Chronicle-Benutzeroberfläche

Beispielkonfiguration: Namespaces

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

Kafka-Eingabe

Sie können Daten aus Kafka-Themen genauso wie für „syslog“ aufnehmen. Mit Nutzergruppen können Sie bis zu drei Forwarder bereitstellen und Daten aus demselben Kafka-Thema abrufen.

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 so eingerichtet wird, dass er Daten aus Kafka-Themen aufnimmt:

collectors:
- kafka:
      common:
        batch_n_bytes: 1048576
        batch_n_seconds: 10
        data_hint: null
        data_type: NIX_SYSTEM
        enabled: true
      username: user
      password: password
      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

Load-Balancing und Hochverfügbarkeit

Der Chronicle-Linux-Forwarder kann in einer Umgebung bereitgestellt werden, in der ein Layer-4-Load-Balancer zwischen der Datenquelle und Forward-Instanzen installiert ist. So können Kunden die Logsammlung auf mehrere Forwarder verteilen oder Logs an einen anderen Forwarder senden, wenn ein Fehler auftritt. Dieses Feature wird nur für den syslog-Sammlungstyp unterstützt.

Der Linux-Weiterleiter umfasst einen integrierten HTTP-Server, der auf HTTP-Systemdiagnosen vom Load-Balancer antwortet. 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 Weiterleitungs-Konfigurationsdatei. Mit diesen Optionen können Sie Zeitüberschreitungen und Statuscodes festlegen, die als Reaktion auf Systemdiagnosen zurückgegeben werden, die bei Containerplanern und orchestrierten Bereitstellungen sowie bei herkömmlichen Load-Balancern eingehen.

Die folgenden URL-Pfade für Gesundheits-, Tagesform- und Aktivitätsprüfungen verwenden. Die <host:port>-Werte sind 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 traditionelle Systemdiagnosen für Load-Balancer.

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

collectors:
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: NIX_SYSTEM
      enabled: true
    tcp_address: 0.0.0.0:30000
    connection_timeout_sec: 60
- syslog:
    common:
      batch_n_bytes: 1048576
      batch_n_seconds: 10
      data_hint: null
      data_type: WINEVTLOG
      enabled: true
    tcp_address: 0.0.0.0:30001
    connection_timeout_sec: 60
server:
  graceful_timeout: 15s
  drain_timeout: 10s
  http:
    port: 8080
    host: 0.0.0.0
    read_timeout: 3s
    read_header_timeout: 3s
    write_timeout: 3s
    idle_timeout: 3s
    routes:
    - meta:
        available_status: 204
        ready_status: 204
        unready_status: 503
Konfigurationspfad Beschreibung
server : anhand_timeout Zeitraum, in dem der Weiterleitungssteller eine schlechte Bereitschafts-/Systemdiagnose zurückgibt und immer noch neue Verbindungen akzeptiert. Dies ist auch die Zeit, die zwischen dem Empfang eines Signals und dem tatsächlichen Herunterfahren des Servers gewartet wird. Dadurch kann der Load-Balancer die Weiterleitung aus dem Pool entfernen.
Server : haus_timeout Die Zeit, die der Weiterleitungsdienst wartet, bis aktive Verbindungen automatisch geschlossen werden, bevor er vom Server geschlossen wird.
Server : http : Port Portnummer, die der HTTP-Server auf Systemdiagnosen vom Load-Balancer überwacht. Muss zwischen 1024 und 65535 liegen.
Server : http : Host IP-Adresse oder Hostname, der in IP-Adressen aufgelöst werden kann, die der Server überwachen sollte. Wenn leer, ist der Standardwert das lokale System (0.0.0.0).
Server : http : read_timeout Wird zur Abstimmung des HTTP-Servers verwendet. Normalerweise muss dies nicht über die Standardeinstellung geändert werden. Die maximale Lesezeit für die gesamte Anfrage, sowohl für den Header als auch für den Text. Sie können sowohl „read_timeout“ als auch „read_header_timeout“ festlegen.
Server : http : read_header_timeout Wird zur Abstimmung des HTTP-Servers verwendet. Normalerweise muss dies nicht über die Standardeinstellung geändert werden. Die maximale Lesezeit für Anfrageheader. Das Zeitlimit für die Verbindung wird zurückgesetzt, nachdem der Header gelesen wurde.
Server : http : write_timeout Wird zur Abstimmung des HTTP-Servers verwendet. Normalerweise muss dies nicht über die Standardeinstellung 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 Abstimmung des HTTP-Servers verwendet. Normalerweise muss dies nicht über die Standardeinstellung geändert werden. Maximale Zeit, die auf die nächste Anfrage gewartet werden soll, wenn inaktive Verbindungen aktiviert sind. Wenn „idtime_outout“ null ist, wird der Wert von „read_timout“ verwendet. Wenn beide null sind, wird der Wert „read_header_timeout“ verwendet.
Route : Meta : Ready_Status Statuscode, der vom Weiterleitungsnutzer in folgenden Fällen akzeptiert wird:
  • Die Bereitschaftsprüfung wird von einem Container-Planer oder -Orchestrator wie Kubernetes empfangen.
  • Die Systemdiagnose wird von einem traditionellen Load-Balancer empfangen.
Routen : Meta : ungeleseny_status Statuscode, der vom Weiterleitungsnutzer zurückgegeben wird, wenn er nicht zur Annahme von Traffic bereit ist.
Routen : Meta : verfügbar Statuscode, der vom Weiterleitungsdienst zurückgegeben wird, wenn eine Aktivitätsprüfung empfangen und verfügbar ist. Aktivitätsprüfungen werden häufig von Containerplanern/Orchestratoren wie Kubernetes gesendet.

FAQ

Was ist ein Docker-Container?

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

  • Virtuelle Maschinen – haben einen privilegierten Bereich (Linux-Kernel) und einen Nutzerbereich (alles, mit dem Sie interagieren: libc, python, ls, tcpdump usw.).

  • Container: Sie haben nur einen Nutzerbereich (alles, mit dem Sie interagieren: libc, Python, ls, tcpdump usw.) und benötigen den Berechtigungsbereich des Hosts.

Warum sollten Sie Chronicle-Forwarder mit einem Container verteilen?

  • Mehr Sicherheit durch Isolierung:
    • Die Kundenumgebung und die Anforderungen wirken sich nicht auf den Chronicle-Forwarder aus.
    • Die Chronicle-Weiterleitungsumgebung und -Anforderungen haben keine Auswirkungen auf den Kunden.
    • Der 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? Was ist mit Windows?

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

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

Benötigen Sie erweiterte Docker-Befehle?

  • Chronicle-Forwarder verwendet einen einzelnen Container, sodass Sie sich nicht über Swarm, Orchestrierung, Kubernetes oder andere erweiterte Docker-Konzepte oder -Befehle informieren müssen.