Infoblox-DNS-Logs erfassen

Unterstützt in:

Google SecOps SIEM

In diesem Dokument wird beschrieben, wie Sie Infoblox-DNS-Logs mit Bindplane in Google Security Operations aufnehmen.

Der Parser extrahiert Felder aus Infoblox-DNS-SYSLOG- und CEF-formatierten Logs. Sie verwendet „grok“ und/oder „kv“, um die Log-Nachricht zu parsen, und ordnet diese Werte dann dem Unified Data Model (UDM) zu. Außerdem werden Standardmetadatenwerte für die Ereignisquelle und den Ereignistyp festgelegt.

Hinweise

Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:

Eine Google SecOps-Instanz
Windows Server 2016 oder höher oder Linux-Host mit systemd
Wenn Sie den Agent hinter einem Proxy ausführen, müssen die Firewallports gemäß den Anforderungen des Bindplane-Agents geöffnet sein.
Privilegierter Zugriff auf die Infoblox Grid Manager-Weboberfläche

Authentifizierungsdatei für die Aufnahme in Google SecOps abrufen

Melden Sie sich in der Google SecOps-Konsole an.
Rufen Sie die SIEM-Einstellungen > Collection Agents auf.
Laden Sie die Authentifizierungsdatei für die Aufnahme herunter. Speichern Sie die Datei sicher auf dem System, auf dem BindPlane installiert wird.

Google SecOps-Kundennummer abrufen

Melden Sie sich in der Google SecOps-Konsole an.
Rufen Sie die SIEM-Einstellungen > Profile auf.
Kopieren und speichern Sie die Kunden-ID aus dem Bereich Organisationsdetails.

BindPlane-Agent installieren

Installieren Sie den Bindplane-Agent auf Ihrem Windows- oder Linux-Betriebssystem gemäß der folgenden Anleitung.

Fenstereinbau

Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.

Führen Sie dazu diesen Befehl aus:

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

Warten Sie, bis die Installation abgeschlossen ist.
Überprüfen Sie die Installation mit folgendem Befehl:
```
sc query observiq-otel-collector
```

Der Dienst sollte als RUNNING (Wird ausgeführt) angezeigt werden.

Linux-Installation

Öffnen Sie ein Terminal mit Root- oder Sudo-Berechtigungen.

Führen Sie dazu diesen Befehl aus:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

Warten Sie, bis die Installation abgeschlossen ist.
Überprüfen Sie die Installation mit folgendem Befehl:
```
sudo systemctl status observiq-otel-collector
```

Der Dienst sollte als aktiv (wird ausgeführt) angezeigt werden.

Zusätzliche Installationsressourcen

Weitere Installationsoptionen und Informationen zur Fehlerbehebung finden Sie in der Installationsanleitung für den Bindplane-Agent.

BindPlane-Agent zum Erfassen von Syslog-Daten und Senden an Google SecOps konfigurieren

Konfigurationsdatei suchen

Linux:

sudo nano /etc/bindplane-agent/config.yaml

Windows:

notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"

Konfigurationsdatei bearbeiten

Ersetzen Sie den gesamten Inhalt von config.yaml durch die folgende Konfiguration:

receivers:
    udplog:
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds_file_path: '/path/to/ingestion-authentication-file.json'
        customer_id: 'YOUR_CUSTOMER_ID'
        endpoint: malachiteingestion-pa.googleapis.com
        log_type: 'INFOBLOX_DNS'
        raw_log_field: body
        ingestion_labels:

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - udplog
            exporters:
                - chronicle/chronicle_w_labels

Konfigurationsparameter

Ersetzen Sie die folgenden Platzhalter:
- Empfängerkonfiguration:
  - udplog: Verwenden Sie udplog für UDP-Syslog oder tcplog für TCP-Syslog.
  - 0.0.0.0: IP-Adresse, an der gelauscht werden soll (0.0.0.0, um an allen Schnittstellen zu lauschen)
  - 514: Portnummer, die überwacht werden soll (Standard-Syslog-Port)
- Exporter-Konfiguration:
  - creds_file_path: Vollständiger Pfad zur Datei für die Authentifizierung bei der Aufnahme:
    - Linux: /etc/bindplane-agent/ingestion-auth.json
    - Windows: C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json
  - YOUR_CUSTOMER_ID: Kunden-ID aus dem Abschnitt „Kunden-ID abrufen“
  - endpoint: Regionale Endpunkt-URL:
    - USA: malachiteingestion-pa.googleapis.com
    - Europa: europe-malachiteingestion-pa.googleapis.com
    - Asien: asia-southeast1-malachiteingestion-pa.googleapis.com
    - Eine vollständige Liste finden Sie unter Regionale Endpunkte.
  - log_type: Logtyp genau wie in Chronicle (INFOBLOX_DNS)

Konfigurationsdatei speichern

Speichern Sie die Datei nach der Bearbeitung:
- Linux: Drücken Sie Ctrl+O, dann Enter und dann Ctrl+X.
- Windows: Klicken Sie auf Datei > Speichern.

Bindplane-Agent neu starten, um die Änderungen zu übernehmen

Führen Sie den folgenden Befehl aus, um den Bindplane-Agent unter Linux neu zu starten:

sudo systemctl restart observiq-otel-collector

Prüfen Sie, ob der Dienst ausgeführt wird:

  sudo systemctl status observiq-otel-collector

Logs auf Fehler prüfen:

  sudo journalctl -u observiq-otel-collector -f

Wählen Sie eine der folgenden Optionen aus, um den Bindplane-Agent unter Windows neu zu starten:
- Eingabeaufforderung oder PowerShell als Administrator:
```
net stop observiq-otel-collector && net start observiq-otel-collector
```
- Services-Konsole:
  1. Drücken Sie Win+R, geben Sie services.msc ein und drücken Sie die Eingabetaste.
  2. Suchen Sie nach observIQ OpenTelemetry Collector.
  3. Klicken Sie mit der rechten Maustaste und wählen Sie Neu starten aus.
  4. Prüfen Sie, ob der Dienst ausgeführt wird:
```
sc query observiq-otel-collector
```
  5. Logs auf Fehler prüfen:
```
type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
```

Syslog-Weiterleitung auf Infoblox DNS konfigurieren

Melden Sie sich in der Weboberfläche von Infoblox Grid Manager an.
Klicken Sie auf Raster > Grid Manager > Mitglieder.
Wählen Sie das zu konfigurierende Mitglied aus und klicken Sie auf Bearbeiten.
Rufen Sie den Tab Monitoring auf.
Klicken Sie unter Syslog auf Hinzufügen, um einen neuen Syslog-Server hinzuzufügen.
Geben Sie die folgenden Konfigurationsdetails an:
- Adresse: Geben Sie die IP-Adresse des Bindplane-Agent-Hosts ein.
- Port: Geben Sie 514 ein.
- Transport: Wählen Sie UDP aus.
- Knoten-ID: Wählen Sie den Infoblox-Knoten aus (für HA-Paare).
- Schweregrad: Wählen Sie Info (oder den gewünschten Schweregrad) aus.
- Einrichtung: Wählen Sie local0 oder die gewünschte Einrichtung aus.
Aktivieren Sie die folgenden Protokollkategorien:
- DNS-Abfragen: Wählen Sie unter Grid DNS Properties > Logging (DNS-Eigenschaften des Grids > Logging) die Option Log DNS Queries (DNS-Abfragen protokollieren) aus.
- DNS-Antworten: Wählen Sie DNS-Antworten protokollieren aus.
- DHCP: Aktivieren Sie die DHCP-Protokollierung unter Grid DHCP Properties (DHCP-Eigenschaften für das Grid).
- Audit: Aktivieren Sie das Audit-Logging unter Grid Properties> Monitoring.
Klicken Sie auf Speichern & schließen.
Starten Sie den DNS-Dienst bei Bedarf neu.
Prüfen Sie die Bindplane-Agent-Logs, um zu sehen, ob Syslog-Nachrichten gesendet werden.

UDM-Zuordnungstabelle

Logfeld	UDM-Zuordnung	Logik
agent.hostname	principal.hostname	Bei Protokollen im CEF-Format wird „agent.hostname“ dem Feld „principal.hostname“ zugeordnet, sofern es vorhanden ist.
client_ip	principal.ip	Bei Protokollen im CEF-Format wird client_ip, sofern vorhanden, principal.ip zugeordnet.
client_port	principal.port	Bei Protokollen im CEF-Format wird „client_port“ dem Feld „principal.port“ zugeordnet, sofern es vorhanden ist.
Daten	answers.data	Aus dem Datenfeld des Antwortbereichs im Rohlog extrahiert. Mehrere Vorkommen werden als separate Antwortobjekte zugeordnet.
Beschreibung	metadata.description	Direkt aus dem Feld „description“ des Rohlogs zugeordnet oder mithilfe von Grok-Mustern aus anderen Feldern wie „message“ und „msg2“ extrahiert.
dest_ip1	target.ip	Aus dem Rohlog extrahiert und „target.ip“ zugeordnet.
destinationDnsDomain	dns_question.name	Bei Protokollen im CEF-Format wird „destinationDnsDomain“ dem Feld „dns_question.name“ zugeordnet, sofern es vorhanden ist.
dns_class	dns_question.class	Zugeordnet mithilfe der Nachschlagetabelle „dns_query_class_mapping.include“.
dns_domain	dns_question.name	Aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert und dns_question.name zugeordnet.
dns_name	dns_question.name	Wird mit Grok-Mustern aus dem Feld „dns_domain“ extrahiert und „dns_question.name“ zugeordnet.
dns_records	answers.data	Bei Logs im CEF-Format wird dns_records, sofern vorhanden, answers.data zugeordnet. Mehrere Vorkommen werden als separate Antwortobjekte zugeordnet.
dst_ip	target.ip oder target.hostname	Aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert. Wenn es sich um eine gültige IP-Adresse handelt, wird sie „target.ip“ zugeordnet. Andernfalls wird sie „target.hostname“ zugeordnet.
dst_ip1	target.ip oder target.hostname	Wird aus dem Feld „message“ oder „msg2“ des Rohlogs mithilfe von Grok-Mustern extrahiert. Wenn es sich um eine gültige IP-Adresse handelt, wird sie „target.ip“ zugeordnet. Andernfalls wird sie „target.hostname“ zugeordnet. Wird nur zugeordnet, wenn sie sich von „dst_ip“ unterscheidet.
evt_type	metadata.product_event_type	Direkt aus dem Feld „evt_type“ des Rohlogs zugeordnet, das mithilfe von Grok-Mustern aus dem Feld „message“ extrahiert wird.
InfobloxB1OPHIPAddress	principal.ip	Bei Protokollen im CEF-Format wird InfobloxB1OPHIPAddress, sofern vorhanden, principal.ip zugeordnet.
InfobloxB1Region	principal.location.country_or_region	Bei Logs im CEF-Format wird „InfobloxB1Region“ dem Feld „principal.location.country_or_region“ zugeordnet, sofern es vorhanden ist.
InfobloxDNSQType	dns_question.type	Bei Protokollen im CEF-Format wird InfobloxDNSQType, sofern vorhanden, dns_question.type zugeordnet.
Vermittler	intermediary.ip oder intermediary.hostname	Aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert. Wenn es sich um eine gültige IP-Adresse handelt, wird sie intermediary.ip zugeordnet. Andernfalls wird sie intermediary.hostname zugeordnet.
msg2	metadata.description, dns.response_code, dns_question.name, target.ip, target.hostname, answers.name, answers.ttl, answers.data, answers.class, answers.type, security_result.severity	Aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert. Wird zum Extrahieren verschiedener Felder verwendet, aber nicht direkt UDM zugeordnet.
name1	answers.name	Aus dem Feld „msg2“ des Rohlogs mit Grok-Mustern extrahiert und „answers.name“ zugeordnet.
name2	answers.name	Aus dem Feld „msg2“ des Rohlogs mit Grok-Mustern extrahiert und „answers.name“ zugeordnet.
Protokoll	network.ip_protocol	Wird direkt aus dem Protokollfeld des Rohlogs zugeordnet, wenn es mit bekannten Protokollen übereinstimmt.
qclass	dns_question.class	Zwischenfeld, das für die Zuordnung von „dns_class“ zu UDM verwendet wird.
qclass1	answers.class	Zwischenfeld, das für die Zuordnung von „dns_class1“ zum UDM verwendet wird.
qclass2	answers.class	Zwischenfeld, das für die Zuordnung von „dns_class2“ zu UDM verwendet wird.
query_type	dns_question.type	Wird mithilfe der dns_record_type.include-Nachschlagetabelle zugeordnet.
query_type1	answers.type	Wird mithilfe der dns_record_type.include-Nachschlagetabelle zugeordnet.
query_type2	answers.type	Wird mithilfe der dns_record_type.include-Nachschlagetabelle zugeordnet.
recursion_flag	network.dns.recursion_desired	Wenn das Flag „recursion_flag“ ein „+“ enthält, wird es als „true“ dem Attribut „network.dns.recursion_desired“ zugeordnet.
record_type	dns_question.type	Zwischenfeld, das zum Zuordnen von „query_type“ zu UDM verwendet wird.
record_type1	answers.type	Zwischenfeld, das für die Zuordnung von „query_type1“ zu UDM verwendet wird.
record_type2	answers.type	Zwischenfeld, das zum Zuordnen von „query_type2“ zu UDM verwendet wird.
res_code	network.dns.response_code	Wird mithilfe der dns_response_code.include-Nachschlagetabelle zugeordnet.
response_code	network.dns.response_code	Bei Protokollen im CEF-Format wird response_code, sofern vorhanden, mithilfe der dns_response_code.include-Nachschlagetabelle network.dns.response_code zugeordnet.
security_action	security_result.action	Abgeleitet vom Statusfeld. Wenn der Status „denied“ lautet, wird „security_action“ auf „BLOCK“ gesetzt. Andernfalls wird „security_action“ auf „ALLOW“ gesetzt.
die Ausprägung	security_result.severity	Wenn bei Logs im CEF-Format der Schweregrad vorhanden und „informational“ ist, wird er in security_result.severity als „INFORMATIONAL“ zugeordnet.
src_host	principal.hostname	Wird aus dem Feld „description“ oder „message“ des Rohlogs mithilfe von Grok-Mustern extrahiert und „principal.hostname“ zugeordnet.
src_ip	principal.ip oder principal.hostname	Aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert. Wenn es sich um eine gültige IP-Adresse handelt, wird sie principal.ip zugeordnet. Andernfalls wird sie principal.hostname zugeordnet.
src_port	principal.port	Wird aus dem Nachrichtenfeld des Rohlogs mit Grok-Mustern extrahiert und „principal.port“ zugeordnet.
ttl1	answers.ttl	Aus dem Feld „msg2“ des Rohlogs mit Grok-Mustern extrahiert und „answers.ttl“ zugeordnet.
ttl2	answers.ttl	Aus dem Feld „msg2“ des Rohlogs mit Grok-Mustern extrahiert und „answers.ttl“ zugeordnet.
metadata.event_type	metadata.event_type	Abgeleitet aus verschiedenen Feldern und der Parserlogik. Der Standardwert ist GENERIC_EVENT, wenn kein anderer Ereignistyp erkannt wird. Mögliche Werte sind NETWORK_DNS, NETWORK_CONNECTION und STATUS_UPDATE.
metadata.log_type	metadata.log_type	Wird vom Parser auf „INFOBLOX_DNS“ gesetzt.
metadata.product_name	metadata.product_name	Wird vom Parser auf „Infoblox DNS“ gesetzt.
metadata.vendor_name	metadata.vendor_name	Wird vom Parser auf „INFOBLOX“ gesetzt.
metadata.product_version	metadata.product_version	Aus CEF-Nachrichten extrahiert.
metadata.event_timestamp	metadata.event_timestamp	Aus dem Zeitstempelfeld kopiert.
network.application_protocol	network.application_protocol	Auf „DNS“ festgelegt, wenn „event_type“ nicht „GENERIC_EVENT“ oder „STATUS_UPDATE“ ist.

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