IBM DB2-Logs erfassen

Unterstützt in:

Google SecOps SIEM

Hinweis: Dieses Feature unterliegt den Bedingungen des Pre-GA-Angebots in den dienstspezifischen Nutzungsbedingungen für Google Security Operations. Pre-GA-Features werden eventuell nur eingeschränkt unterstützt und Änderungen an diesen Features sind möglicherweise nicht mit anderen Pre-GA-Versionen kompatibel. Weitere Informationen finden Sie in den Richtlinien für den technischen Support von Google SecOps und den dienstspezifischen Nutzungsbedingungen für Google SecOps.

In diesem Dokument wird beschrieben, wie Sie IBM DB2-Logs mit dem Bindplane-Agent in Google Security Operations aufnehmen.

IBM Db2 ist ein relationales Datenbankverwaltungssystem, das eine Prüffunktion bietet, um unbekannten oder unerwarteten Zugriff auf Daten zu erkennen. Die Db2-Prüffunktion generiert und ermöglicht die Verwaltung eines Prüfpfads für eine Reihe vordefinierter Datenbankereignisse.

Hinweis

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

• Eine Google SecOps-Instanz
• Windows Server 2016 oder höher oder Linux-Host mit systemd
• Netzwerkverbindung zwischen dem Bindplane-Agent und der IBM DB2-Instanz
• Wenn Sie den Agent hinter einem Proxy ausführen, müssen die Firewallports gemäß den Anforderungen des Bindplane-Agents geöffnet sein.
• IBM Db2-Instanz (Version 11.1 oder höher) mit SYSADM-Berechtigungen
• Ausreichend Speicherplatz für die Speicherung und Archivierung von Audit-Logs

Authentifizierungsdatei für die Aufnahme in Google SecOps abrufen

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Rufen Sie die SIEM-Einstellungen > Collection Agent auf.
3. Klicken Sie auf Herunterladen, um die Datei zur Authentifizierung der Aufnahme herunterzuladen.

4. Speichern Sie die Datei sicher auf dem System, auf dem der Bindplane-Agent installiert wird.

   Hinweis :Diese JSON-Datei enthält Anmeldedaten für die Authentifizierung des Bindplane-Agents bei Google SecOps.

Google SecOps-Kundennummer abrufen

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Rufen Sie die SIEM-Einstellungen > Profile auf.

3. Kopieren und speichern Sie die Kunden-ID aus dem Bereich Organisationsdetails.

   Hinweis :Die customer ID ist für die Konfiguration des Bindplane-Agent-Exporters erforderlich.

BindPlane-Agent installieren

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

Fenstermontage

1. Öffnen Sie die Eingabeaufforderung oder PowerShell als Administrator.

2. Führen Sie dazu diesen Befehl aus:

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

3. Warten Sie, bis die Installation abgeschlossen ist.

4. Ü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

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

2. 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
   

3. Warten Sie, bis die Installation abgeschlossen ist.

4. Ü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 /opt/observiq-otel-collector/config.yaml
  

• Windows:

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

Konfigurationsdatei bearbeiten

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

   receivers:
     tcplog:
       listen_address: "0.0.0.0:1514"
   
   exporters:
     chronicle/db2_audit:
       compression: gzip
       creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json'
       customer_id: 'YOUR_CUSTOMER_ID'
       endpoint: malachiteingestion-pa.googleapis.com
       log_type: DB2_DB
       raw_log_field: body
       ingestion_labels:
         env: production
   
   service:
     pipelines:
       logs/db2_to_chronicle:
         receivers:
           - tcplog
         exporters:
           - chronicle/db2_audit
   

2. Ersetzen Sie die folgenden Platzhalter:

   • Empfängerkonfiguration:

     • listen_address: Auf 0.0.0.0:1514 gesetzt, um alle Schnittstellen auf Port 1514 zu überwachen (nicht privilegierter Port, der für Linux empfohlen wird).

   • Exporter-Konfiguration:

     • creds_file_path: Vollständiger Pfad zur Datei für die Authentifizierung bei der Aufnahme:

       • Linux: /opt/observiq-otel-collector/ingestion-auth.json
       • Windows: C:\\Program Files\\observIQ OpenTelemetry Collector\\ingestion-auth.json

     • customer_id: Kunden-ID aus dem vorherigen Schritt

     • 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: Auf DB2_DB festlegen

     • ingestion_labels: Optionale Labels im YAML-Format (z. B. env: production)

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

• Linux

  sudo systemctl restart observiq-otel-collector
  

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

     sudo systemctl status observiq-otel-collector
     

  2. Logs auf Fehler prüfen:

     sudo journalctl -u observiq-otel-collector -f
     

• Windows

  Wählen Sie eine der folgenden Optionen aus:

  • So verwenden Sie die Eingabeaufforderung oder PowerShell als Administrator:

    net stop observiq-otel-collector && net start observiq-otel-collector
    

  • Services Console verwenden:

    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"
       

IBM DB2-Prüffunktion konfigurieren

Konfigurieren Sie die DB2-Prüffunktion, um Sicherheitsereignisse zu erfassen und in Syslog zu extrahieren.

Aktuelle Konfiguration der Prüfung prüfen

• Stellen Sie als Nutzer mit SYSADM-Berechtigung eine Verbindung zu Ihrer DB2-Instanz her und führen Sie Folgendes aus:

  db2audit describe
  

  Hier wird die aktuelle Audit-Konfiguration angezeigt, einschließlich Audit-Status, Kategorien und Pfaden.

Prüfpfade konfigurieren

1. Legen Sie die Verzeichnisse fest, in denen Audit-Logs gespeichert werden sollen:

   db2audit configure datapath /db2audit/data
   db2audit configure archivepath /db2audit/archive
   

2. Prüfen Sie, ob diese Verzeichnisse vorhanden sind und der DB2-Instanzinhaber die entsprechenden Berechtigungen hat:

   mkdir -p /db2audit/data /db2audit/archive
   chown db2inst1:db2iadm1 /db2audit/data /db2audit/archive
   chmod 750 /db2audit/data /db2audit/archive
   

Prüfbereich und ‑kategorien konfigurieren

• Konfigurieren Sie die Audit-Funktion so, dass alle Sicherheitsereignisse erfasst werden:

  db2audit configure scope all status both errortype normal
  

  Dadurch wird Folgendes konfiguriert:

  • scope all: Prüft alle Kategorien (audit, checking, objmaint, secmaint, sysadmin, validate, context).
  • status both: Erfasst sowohl erfolgreiche als auch fehlgeschlagene Ereignisse.
  • errortype normal: Standardfehlerbehandlung

Prüffunktion starten

1. So starten Sie die Prüfung:

   db2audit start
   

2. Prüfen Sie, ob die Prüfung aktiv ist:

   db2audit describe
   

   In der Ausgabe sollte Audit active: "TRUE" angezeigt werden.

Syslog für den Empfang von DB2-Audit-Logs konfigurieren

Konfigurieren Sie den System-Syslog-Daemon so, dass er DB2-Audit-Nachrichten empfängt und speichert.

Linux (rsyslog)

1. Bearbeiten Sie die rsyslog-Konfigurationsdatei:

   sudo nano /etc/rsyslog.conf
   

2. Fügen Sie die folgende Zeile hinzu, um DB2-Prüfprotokollnachrichten an eine bestimmte Datei weiterzuleiten:

   user.info /var/log/db2/db2audit.log
   

3. Erstellen Sie das Logverzeichnis und die Logdatei:

   sudo mkdir -p /var/log/db2
   sudo touch /var/log/db2/db2audit.log
   sudo chmod 640 /var/log/db2/db2audit.log
   

4. Starten Sie rsyslog neu:

   sudo systemctl restart rsyslog
   

AIX (syslogd)

1. Bearbeiten Sie die Syslog-Konfigurationsdatei:

   sudo vi /etc/syslog.conf
   

2. Fügen Sie folgende Zeile hinzu:

   user.info /var/log/db2/db2audit.log
   

3. Erstellen Sie das Logverzeichnis und die Logdatei:

   sudo mkdir -p /var/log/db2
   sudo touch /var/log/db2/db2audit.log
   sudo chmod 640 /var/log/db2/db2audit.log
   

4. Starten Sie syslogd neu:

   sudo refresh -s syslogd
   

DB2-Audit-Logs in Syslog extrahieren

Archivierte Audit-Logs extrahieren und an den Syslog-Daemon des Systems senden.

Audit-Logs leeren und archivieren

• Leeren Sie vor dem Export alle ausstehenden Audit-Datensätze und archivieren Sie das aktuelle Audit-Log:

  db2audit flush
  db2audit archive
  

  Mit dem Archivierungsbefehl werden zeitgestempelte Dateien im Archivierungspfad erstellt (z. B. db2audit.instance.log.0.20250110123456).

Audit-Logs in Syslog extrahieren

• Extrahieren Sie die archivierten Audit-Logs und senden Sie sie mit der Einrichtung und Priorität user.info an Syslog:

  db2audit extract syslog user.info from files /db2audit/archive/db2audit.instance.log.0.*
  

  Dieser Befehl:

  • Extrahieren von Audit-Einträgen aus den archivierten Logdateien
  • Sendet sie mit der Einrichtung user und der Priorität info an den System-Syslog-Daemon.
  • Der Syslog-Daemon leitet die Nachrichten gemäß /etc/syslog.conf oder /etc/rsyslog.conf weiter.

Prüfen, ob Logs gesendet werden

• Prüfen Sie, ob Audit-Nachrichten in die Syslog-Datei geschrieben werden:

  tail -f /var/log/db2/db2audit.log
  

  In der Logdatei sollten DB2-Prüfdatensätze angezeigt werden.

rsyslog so konfigurieren, dass Logs an den BindPlane-Agenten weitergeleitet werden

Konfigurieren Sie rsyslog so, dass DB2-Audit-Logs an den BindPlane-Agenten weitergeleitet werden.

1. Erstellen Sie eine neue rsyslog-Konfigurationsdatei:

   sudo nano /etc/rsyslog.d/50-db2-forward.conf
   

2. Fügen Sie die folgende Konfiguration hinzu, um Logs an den Bindplane-Agent weiterzuleiten:

   # Forward DB2 audit logs to Bindplane agent
   user.info @@127.0.0.1:1514
   

   Das Präfix @@ gibt die TCP-Weiterleitung an. Verwenden Sie bei Bedarf @ für UDP.

3. Starten Sie rsyslog neu:

   sudo systemctl restart rsyslog
   

Audit-Log-Extraktion automatisieren

Skript zur Automatisierung des Prozesses zum Leeren, Archivieren und Extrahieren erstellen

Extraktionsskript erstellen

1. So erstellen Sie ein Skript zum Automatisieren des Extrahierens von Audit-Logs:

   sudo nano /usr/local/bin/db2audit-extract.sh
   

2. Fügen Sie den folgenden Inhalt hinzu:

   #!/bin/bash
   # DB2 Audit Log Extraction Script
   
   # Set DB2 environment
   export DB2INSTANCE=db2inst1
   . /home/db2inst1/sqllib/db2profile
   
   # Flush pending audit records
   db2audit flush
   
   # Archive current audit log
   db2audit archive
   
   # Extract archived logs to syslog
   db2audit extract syslog user.info from files /db2audit/archive/db2audit.instance.log.0.*
   
   # Optional: Clean up old archived logs (older than 30 days)
   find /db2audit/archive -name "db2audit.instance.log.0.*" -mtime +30 -delete
   
   exit 0
   

3. Machen Sie das Skript ausführbar:

   sudo chmod +x /usr/local/bin/db2audit-extract.sh
   

Mit Cron planen

1. Planen Sie die regelmäßige Ausführung des Skripts mit cron:

   sudo crontab -e
   

2. Fügen Sie die folgende Zeile hinzu, um das Skript stündlich auszuführen:

   Wählen Sie eine der folgenden Optionen aus:

   0 * * * * /usr/local/bin/db2audit-extract.sh >> /var/log/db2/db2audit-extract.log 2>&1
   

   Oder führen Sie den Befehl alle 15 Minuten aus, um die Daten häufiger zu extrahieren:

   */15 * * * * /usr/local/bin/db2audit-extract.sh >> /var/log/db2/db2audit-extract.log 2>&1
   

Logaufnahme in Google SecOps prüfen

1. Melden Sie sich in der Google SecOps-Konsole an.
2. Rufen Sie die Suche auf.

3. Führen Sie eine Suchanfrage aus, um zu prüfen, ob DB2-Logs aufgenommen werden:

   metadata.log_type = "DB2_DB"
   

4. Prüfen Sie, ob Logs mit dem richtigen Zeitstempel und den richtigen Feldern angezeigt werden.

   Hinweis :Es kann 5 bis 10 Minuten dauern, bis Logs nach der Erstkonfiguration in Google SecOps angezeigt werden.

UDM-Zuordnungstabelle

Logfeld	UDM-Zuordnung	Logik
msg	event.idm.read_only_udm.additional.fields	Wert aus „msg“, wenn „msg“ != „“
System	event.idm.read_only_udm.additional.fields	Wert aus dem System, wenn System != „“
Subsystem	event.idm.read_only_udm.additional.fields	Wert aus dem Subsystem, wenn Subsystem != „“
auth_mechanism	event.idm.read_only_udm.extensions.auth.mechanism	Für USER_LOGIN-Ereignisse auf „USERNAME_PASSWORD“ festlegen
CorrelationUser	event.idm.read_only_udm.intermediary.user.userid	Wert aus CorrelationUser, wenn CorrelationUser != ""
Summe	event.idm.read_only_udm.metadata.description	Wert aus Summe
date_time	event.idm.read_only_udm.metadata.event_timestamp	Konvertiert aus Datums- und Zeitfeldern in das ISO8601-Format, wenn beide != ""
leef_event_id	event.idm.read_only_udm.metadata.product_event_type	Wert aus „leef_event_id“
	event.idm.read_only_udm.metadata.event_type	Abgeleitet von leef_event_id: wenn in ["102-87", "102-83"] → USER_LOGIN; wenn in ["102-6", "102-7", "102-8", "102-10", "102-24", "102-143"] → USER_RESOURCE_ACCESS oder USER_RESOURCE_UPDATE_CONTENT basierend auf der Absicht; wenn "102-319" → USER_RESOURCE_ACCESS; andernfalls GENERIC_EVENT
	event.idm.read_only_udm.metadata.product_name	Auf „DB2“ festgelegt
	event.idm.read_only_udm.metadata.vendor_name	Auf „IBM“ festgelegt
SSID	event.idm.read_only_udm.network.session_id	Wert aus SSID, wenn SSID != „“
Job	event.idm.read_only_udm.principal.application	Der Wert wird aus dem Job übernommen, wenn job != „“
sourceServiceName	event.idm.read_only_udm.principal.application	Wert aus „sourceServiceName“
sourceHostName	event.idm.read_only_udm.principal.asset.hostname	Der Wert wird aus „sourceHostName“ übernommen, wenn „sourceHostName“ != „“
principal_ip	event.idm.read_only_udm.principal.asset.ip	Wert aus „principal_ip“ für Ereignisse vom Typ 102–319
product_id	event.idm.read_only_udm.principal.asset_id	Für Ereignisse vom Typ 102–319 auf „Produkt-ID: %{product_id}“ festlegen
sourceHostName	event.idm.read_only_udm.principal.hostname	Der Wert wird aus „sourceHostName“ übernommen, wenn „sourceHostName“ != „“
principal_ip	event.idm.read_only_udm.principal.ip	Wert aus „principal_ip“ für Ereignisse vom Typ 102–319
Ersteller	event.idm.read_only_udm.principal.user.user_display_name	Vom Creator übernommener Wert
name	event.idm.read_only_udm.principal.user.user_display_name	Wert aus dem Namen, wenn name != „“
AuthenticatedUser	event.idm.read_only_udm.principal.user.userid	Wert wird von AuthenticatedUser übernommen, wenn AuthenticatedUser != „“
sourceUserName	event.idm.read_only_udm.principal.user.userid	Wert aus „sourceUserName“
usrName	event.idm.read_only_udm.principal.user.userid	Wert aus usrName
_action	event.idm.read_only_udm.security_result.action	Abgeleitet von der Summe: Wenn „successful“ enthalten ist → ALLOW; andernfalls BLOCK für USER_LOGIN-Ereignisse
deviceHostName	event.idm.read_only_udm.target.asset.hostname	Wert aus „deviceHostName“
conn_location3	event.idm.read_only_udm.target.asset.hostname	Wert aus conn_location3, wenn conn_location3 != „“
file_name	event.idm.read_only_udm.target.file.full_path	Wert aus „file_name“, wenn „file_name“ != „“
deviceHostName	event.idm.read_only_udm.target.hostname	Wert aus „deviceHostName“
conn_location3	event.idm.read_only_udm.target.hostname	Wert aus conn_location3, wenn conn_location3 != „“
conn_location, conn_location2	event.idm.read_only_udm.target.location.name	Verkettung von conn_location und conn_location2, wenn beide != „“
deviceProcessName	event.idm.read_only_udm.target.process.command_line	Wert aus „deviceProcessName“
SQL	event.idm.read_only_udm.target.process.command_line	Wert aus SQL, wenn SQL != „“
Connection_Type	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Connection Type“ mit Wert aus Connection_Type
Plan	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Plan“ mit Wert aus „Plan“
DB2_Subsystem	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „DB2 Subsystem“ mit Wert aus DB2_Subsystem
Priv_Check_Code	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Priv Check Code“ mit Wert aus Priv_Check_Code
Table_Name	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Table Name“ mit Wert aus Table_Name
MessageType	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Message Type“ mit Wert aus MessageType
Check_type	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Check Type“ mit Wert aus „Check_type“
deviceAction	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „Device Action“ (Geräteaktion) mit Wert, der aus „deviceAction“ zugeordnet wird: G → GRANT (ERTEILEN), R → REVOKE (ENTZIEHEN)
SSID	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „SSID“ mit Wert aus SSID, wenn Wert != „“
SQL	event.idm.read_only_udm.target.resource.attribute.labels	Schlüssel „SQL Query“ mit Wert aus SQL, wenn SQL != „“
messageid	event.idm.read_only_udm.target.resource.id	Wert aus „messageid“ übernommen
Object_Class_Code	event.idm.read_only_udm.target.resource.parent	Wert aus „Object_Class_Code“
obj	event.idm.read_only_udm.target.resource.name	Wert aus „obj“
ressource_name	event.idm.read_only_udm.target.resource.name	Wert aus „resource_name“ aus SQL extrahiert, wenn SQL != „“ und nicht leer
Database_Name	event.idm.read_only_udm.target.resource.name	Wert aus „Database_Name“
objtyp	event.idm.read_only_udm.target.resource.resource_subtype	Wert aus „objtyp“ (in Großbuchstaben), wenn „objtyp“ != „“
Typ	event.idm.read_only_udm.target.resource.resource_subtype	Abgeleitet von Typ: T → TABLE, V → VIEW, X → AUXILIARY TABLE
	event.idm.read_only_udm.target.resource.resource_type	Auf „DATABASE“ festgelegt

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