Diese Seite wurde von der Cloud Translation API übersetzt.

Linux-Audit- und AIX-Systemlogs erfassen

Unterstützt in:

Google SecOps SIEM

Dieser Parser verarbeitet Linux-Audit-Logs im SYSLOG-Format und wandelt sie in das UDM um. Es werden sowohl JSON-formatierte als auch Nur-Text-Lognachrichten verarbeitet. Dabei werden Felder mithilfe von Grok-, XML- und JSON-Parsing-Techniken extrahiert und basierend auf dem Ereignistyp den entsprechenden UDM-Feldern zugeordnet. Der Parser verarbeitet auch bestimmte Audit-Log-Formate von AIX-Systemen und reichert das UDM mit zusätzlichen Feldern wie security_result und Zwischeninformationen an.

Hinweise

Prüfen Sie, ob Sie eine Google Security Operations-Instanz haben.
Sie benötigen Root-Zugriff auf den Auditd-Host.
Prüfen Sie, ob Sie rsyslog auf dem Auditd-Host installiert haben.
Achten Sie darauf, dass Sie einen Windows 2012 SP2-Host oder höher oder einen Linux-Host mit systemd haben.
Wenn Sie die Software hinter einem Proxy ausführen, müssen die Firewallports geöffnet sein.

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.

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

Führen Sie für die Windows-Installation das folgende Skript aus:
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
Führen Sie für die Linux-Installation das folgende Skript aus:
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
Weitere Installationsoptionen finden Sie in diesem Installationsleitfaden.

Bindplane-Agent so konfigurieren, dass Syslog-Daten aufgenommen und an Google SecOps gesendet werden

Greifen Sie auf den Computer zu, auf dem BindPlane installiert ist.

Bearbeiten Sie die Datei config.yamlso:

receivers:
  tcplog:
    # Replace the below port <54525> and IP <0.0.0.0> with your specific values
    listen_address: "0.0.0.0:54525" 

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        # Adjust the creds location below according the placement of the credentials file you downloaded
        creds: '{ json file for creds }'
        # Replace <customer_id> below with your actual ID that you copied
        customer_id: <customer_id>
        endpoint: malachiteingestion-pa.googleapis.com
        # You can apply ingestion labels below as preferred
        ingestion_labels:
        log_type: SYSLOG
        namespace: auditd
        raw_log_field: body
service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - tcplog
            exporters:
                - chronicle/chronicle_w_labels

Starten Sie den Bindplane-Agent neu, um die Änderungen mit dem folgenden Befehl zu übernehmen: sudo systemctl bindplane restart

Syslog aus Auditd exportieren

Rufen Sie den Computer auf, von dem Sie Audit-Logs exportieren möchten.
Öffnen Sie die Auditd-Konfigurationsdatei (in der Regel unter /etc/audit/auditd.conf).
```
sudo vi /etc/audit/auditd.conf
```
Suchen Sie die folgenden Zeilen oder fügen Sie sie hinzu, um auditd zu konfigurieren:
```
active = yes
output = syslog
log_format = ENRICHED
dispatcher = /sbin/audispd
```

Optional: Syslog-Einrichtung angeben: Fügen Sie in auditd.conf die folgende Zeile hinzu oder ändern Sie sie:

```none
syslog_facility = LOG_AUTHPRIV
```

Öffnen Sie die audispd-Konfigurationsdatei (normalerweise unter /etc/audisp/plugins.d/syslog.conf):
```
sudo vi /etc/audisp/plugins.d/syslog.conf
```

Suchen Sie die folgenden Zeilen oder fügen Sie sie hinzu, um audispd zu konfigurieren:

active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string

Starten Sie den Auditd-Dienst neu, damit die Änderungen wirksam werden:
```
sudo systemctl restart auditd
```

Verwenden Sie ein Tool wie tail, um das Syslog zu überwachen und zu prüfen, ob Auditd-Logs gesendet werden:

tail -f /var/log/syslog | grep auditd # Follow syslog and filter for auditd messages (path may vary depending on your system)

Bearbeiten Sie die rsyslog.conf oder erstellen Sie eine benutzerdefinierte Konfiguration:
```
sudo vi /etc/rsyslog.d/50-audit-forwarding.conf
```
Regel zum Weiterleiten von Logs hinzufügen:
- if $programname == 'auditd' then @@<Bindplane_Agent>:<Bindplane_Port>
- Verwenden Sie @ für UDP oder @@ für TCP.
- Ersetzen Sie <BindPlane_Agent> durch die IP-Adresse oder den Hostnamen Ihres Servers.
- Ersetzen Sie <BindPlane_Port> durch den Port Ihres Servers.
Starten Sie den rsyslog-Dienst neu, um die Änderungen zu übernehmen:
```
sudo systemctl restart rsyslog
```

UDM-Zuordnungstabelle

Logfeld	UDM-Zuordnung	Bemerkung
`acct`	`target.user.user_display_name`	Der Wert von `acct` aus dem Rohlog wird dem Feld `target.user.user_display_name` im UDM zugeordnet. Das Konto, das mit dem Ereignis verknüpft ist.
`addr`	`principal.ip`	Der Wert von `addr` aus dem Rohlog wird dem Feld `principal.ip` im UDM zugeordnet. Dies ist die IP-Adresse des Hauptkontos, das an der Aktion beteiligt ist.
`additional.fields`	`additional.fields`	Dem `additional.fields`-Array im UDM werden zusätzliche Felder aus geparsten Schlüssel/Wert-Paaren oder Labels hinzugefügt.
`agent.googleapis.com/log_file_path`	(Nicht zugeordnet)	Dieses Label ist in einigen Rohlogs vorhanden, wird aber nicht dem IDM-Objekt im UDM zugeordnet.
`algo`	(In diesem Beispiel nicht verwendet)	Dieses Feld ist zwar im Parser und in einigen Rohlogs vorhanden, wird aber im bereitgestellten Beispiel nicht verwendet und ist nicht im endgültigen UDM enthalten.
`application`	`principal.application`	Abgeleitet vom Feld `terminal` im Rohlog oder von anderen Feldern wie `exe`, je nach Logtyp. Stellt die beteiligte Anwendung dar.
`arch`	`security_result.about.platform_version`	Die Architektur aus dem Feld `arch` des Rohlogs wird `security_result.about.platform_version` zugeordnet.
`auid`	`about.user.userid`, `security_result.detection_fields.auid`	Die Audit-Nutzer-ID (`auid`) wird `about.user.userid` zugeordnet und als Erkennungsfeld in `security_result` hinzugefügt.
`cmd`	`target.process.command_line`	Der Befehl aus dem Feld `cmd` des Rohlogs wird `target.process.command_line` zugeordnet.
`collection_time`	(Nicht zugeordnet)	Dieses Feld enthält den Zeitpunkt der Protokollerfassung und wird nicht dem IDM-Objekt im UDM zugeordnet.
`comm`	`principal.application`	Der Befehlsname (`comm`) wird `principal.application` zugeordnet.
`COMMAND`	`target.process.command_line`
`compute.googleapis.com/resource_name`	`principal.hostname`	Der Ressourcenname dieses Labels wird `principal.hostname` zugeordnet.
`create_time`	(Nicht zugeordnet)	Dieses Feld ist im UDM nicht dem IDM-Objekt zugeordnet.
`cwd`	`security_result.detection_fields.cwd`	Das aktuelle Arbeitsverzeichnis (`cwd`) wird als Erkennungsfeld in `security_result` hinzugefügt.
`data`	(Verarbeitet)	Das Feld `data` enthält die Hauptprotokollnachricht und wird vom Parser verarbeitet, um verschiedene Felder zu extrahieren. Es wird nicht direkt einem einzelnen UDM-Feld zugeordnet.
`exe`	`target.process.file.full_path`	Der Programmdateipfad (`exe`) ist `target.process.file.full_path` zugeordnet.
`extensions.auth.type`	`extensions.auth.type`	Der Authentifizierungstyp wird von der Parserlogik basierend auf dem Ereignistyp festgelegt. Wird häufig auf `MACHINE` oder `AUTHTYPE_UNSPECIFIED` festgelegt.
`fp`	`network.tls.client.certificate.sha256`	Der Fingerabdruck (`fp`) wird geparst, um den SHA256-Hash zu extrahieren und `network.tls.client.certificate.sha256` zuzuordnen.
`_Item_Id`	`metadata.product_log_id`
`insertId`	(Nicht zugeordnet)	Dieses Feld ist im UDM nicht dem IDM-Objekt zugeordnet.
`jsonPayload.message`	(Verarbeitet)	Dieses Feld enthält die Hauptprotokollnachricht im JSON-Format und wird vom Parser verarbeitet.
`key`	`security_result.about.registry.registry_key`	Das Schlüsselfeld wird `security_result.about.registry.registry_key` zugeordnet.
`labels`	(Verarbeitet)	Labels aus dem Rohlog werden verarbeitet und verschiedenen UDM-Feldern zugeordnet oder `additional.fields` hinzugefügt.
`logName`	(Nicht zugeordnet)	Dieses Feld ist im UDM nicht dem IDM-Objekt zugeordnet.
`metadata.product_event_type`	SECCOMP	Die Kurve für den Schlüsselaustausch wird aus dem Rohlog extrahiert und diesem Feld zugeordnet.
`msg`	`security_result.summary`	Die Nachricht (`msg`) wird häufig verwendet, um das Feld `security_result.summary` auszufüllen.
`network.application_protocol`	`network.application_protocol`	Wird von der Parserlogik basierend auf dem Ereignistyp festgelegt (z.B. SSH, HTTP).
`network.direction`	`network.direction`	Wird von der Parserlogik basierend auf dem Ereignistyp festgelegt (z.B. INBOUND, OUTBOUND).
`network.ip_protocol`	`network.ip_protocol`	Wird von der Parserlogik festgelegt, in der Regel auf TCP für SSH-Ereignisse.
`network.session_id`	`network.session_id`	Wird aus dem Feld `ses` zugeordnet oder aus anderen Feldern abgeleitet.
`network.tls.cipher`	`network.tls.cipher`	Die Chiffrierinformationen werden aus dem Rohprotokoll extrahiert und diesem Feld zugeordnet.
`network.tls.curve`	`network.tls.curve`	Die Kurve für den Schlüsselaustausch wird aus dem Rohlog extrahiert und diesem Feld zugeordnet.
`pid`	`principal.process.pid`, `target.process.pid`	Die Prozess-ID (`pid`) wird je nach Kontext entweder `principal.process.pid` oder `target.process.pid` zugeordnet.
`ppid`	`principal.process.parent_process.pid`, `target.process.parent_process.pid`	Die ID des übergeordneten Prozesses (`ppid`) wird je nach Kontext entweder `principal.process.parent_process.pid` oder `target.process.parent_process.pid` zugeordnet.
`principal.asset.hostname`	`principal.asset.hostname`	Kopiert von `principal.hostname`.
`principal.asset.ip`	`principal.asset.ip`	Kopiert von `principal.ip`.
`principal.platform`	`principal.platform`	Wird von der Parserlogik basierend auf dem Betriebssystem festgelegt (z.B. LINUX).
`principal.port`	`principal.port`	Die Portnummer, die mit dem Prinzipal verknüpft ist.
`principal.user.group_identifiers`	`principal.user.group_identifiers`	Gruppen-IDs, die dem Hauptnutzer zugeordnet sind.
`process.name`	`target.process.file.full_path`
`receiveTimestamp`	(Nicht zugeordnet)	Dieses Feld enthält den Zeitstempel für den Empfang des Logs und wird nicht dem IDM-Objekt im UDM zugeordnet.
`res`	`security_result.action_details`	Das Ergebnis (`res`) wird `security_result.action_details` zugeordnet.
`_Resource_Id`	`target.resource.product_object_id`
`resource.labels`	(Nicht zugeordnet)	Diese Labels sind in einigen Rohlogs vorhanden, werden aber nicht dem IDM-Objekt im UDM zugeordnet.
`resource.type`	(Nicht zugeordnet)	Dieses Feld ist in einigen Rohlogs vorhanden, wird aber nicht dem IDM-Objekt im UDM zugeordnet.
`security_result.action`	`security_result.action`	Wird von der Parserlogik basierend auf dem Feld `res` festgelegt (z.B. ALLOW, BLOCK).
`security_result.detection_fields`	`security_result.detection_fields`	Diesem Array werden verschiedene Felder aus dem Rohlog als Schlüssel/Wert-Paare für den Kontext hinzugefügt.
`security_result.rule_id`	`security_result.rule_id`	Wird von der Parserlogik festgelegt, häufig auf `type_name` für Syscall-Ereignisse.
`security_result.severity`	`security_result.severity`	Wird von der Parserlogik basierend auf dem Schweregrad im Rohlog festgelegt.
`security_result.summary`	`security_result.summary`	Eine Zusammenfassung des Ereignisses, die oft aus dem Feld `msg` oder anderen relevanten Feldern abgeleitet wird.
`ses`	`network.session_id`	Die Sitzungs-ID (`ses`) wird `network.session_id` zugeordnet.
`source`	(Nicht zugeordnet)	Dieses Feld enthält Metadaten zur Logquelle und wird nicht dem IDM-Objekt im UDM zugeordnet.
`subj`	(Verarbeitet)	Das Betrefffeld (`subj`) wird verarbeitet, um Nutzer- und Sicherheitskontextinformationen zu extrahieren.
`syscall`	`security_result.about.labels.Syscall`	Die Syscall-Nummer wird als Label in `security_result.about` hinzugefügt.
`target.administrative_domain`	`target.administrative_domain`	Die Domain des Zielnutzers.
`target.group.group_display_name`	`target.group.group_display_name`	Der Name der Zielgruppe.
`target.ip`	`target.ip`	Die IP-Adresse des Ziels.
`target.port`	`target.port`	Die mit dem Ziel verknüpfte Portnummer.
`target.process.command_line`	`target.process.command_line`	Die Befehlszeile des Zielprozesses.
`target.resource.type`	`target.resource.type`	Der Typ der Zielressource, der von der Parserlogik festgelegt wird (z.B. ANMELDEINFORMATIONEN, EINSTELLUNG).
`target.user.attribute.permissions`	`target.user.attribute.permissions`	Berechtigungen, die sich auf den Zielnutzer beziehen.
`target.user.group_identifiers`	`target.user.group_identifiers`	Gruppen-IDs, die dem Zielnutzer zugeordnet sind.
`target.user.userid`	`target.user.userid`	Die Nutzer-ID des Ziels.
`TenantId`	`metadata.product_deployment_id`
`textPayload`	(Verarbeitet)	Die Textnutzlast des Logs, die vom Parser verarbeitet wird, um verschiedene Felder zu extrahieren.
`timestamp`	`metadata.event_timestamp`	Der Zeitstempel des Ereignisses.
`tty`	`security_result.about.labels.tty`	Das TTY wird als Label in `security_result.about` hinzugefügt.
`type`	`metadata.product_event_type`	Der Ereignistyp (`type`) wird `metadata.product_event_type` zugeordnet.
`uid`	`target.user.userid`	Die Nutzer-ID (`uid`) wird `target.user.userid` zugeordnet.

UDM-Abgleichsdelta-Referenz

Am 23. September 2025 hat Google SecOps eine neue Version des Okta-Parsers veröffentlicht, die erhebliche Änderungen bei der Zuordnung von Okta-Logfeldern zu UDM-Feldern und bei der Zuordnung von Ereignistypen enthält.

Delta der Zuordnung von Logfeldern

In der folgenden Tabelle ist das Zuordnungsdelta für Okta-Log-zu-UDM-Felder aufgeführt, die vor dem 23. September 2025 und danach verfügbar waren (in den Spalten Alte Zuordnung bzw. Aktuelle Zuordnung).

Logfeld	Alte Zuordnung	Aktuelle Zuordnung	Beispiel für Referenzlog
`1.1.1.1` (IP-Adresse)	`src.ip`	`principal.ip`	"<163>Apr 10 09:00:05 hostname.com sshd[3318513]: Accepted password for abc from 1.1.1.1 port 33988 ssh2"
`1.1.1.1` (IP-Adresse)	`principal.ip`	`target.ip`	"<29>Oct 5 08:37:16 abc ProxySG: E0000 Access Log HTTP (main): Connecting to server 1.1.1.1 on port 4433.(0) NORMAL_EVENT alog_stream_http.cpp 261"
`abc` (Nutzer)	`principal.user.userid`	`target.user.userid`	"<85>Feb 27 08:26:55 offozcav login: FAILED LOGIN 1 FROM ::ffff:1.1.1.1 FOR abc, Authentication failure\r\n\r\n"
`abc.abc` (Nutzer)	`principal.user.userid`	`target.user.userid`	"<86>Feb 27 08:29:19 offozcav login: LOGIN ON pts/43 BY abc.abc FROM\r\n\r\n::ffff:1.1.1.1"
`COMMAND`	`principal.process.command_line`	`target.process.command_line`	"<85>Sep 24 14:33:59 abc sudo: abc : \r\nTTY=unknown ; PWD=/abc ; USER=abc ; COMMAND=/sbin/iptables -t nat -nL \r\n--line-number"
`exe`	`target.process.file.full_path`	`principal.process.file.full_path`
`_ItemId`	`additional.fields`	`metadata.product_log_id`
`metadata.product_event_type`	`PATH`	`SECCOMP`
`process.name`	`principal.process.file.full_path`	`target.process.file.full_path`
`_ResourceId`	`additional.fields`	`target.resource.product_object_id`
`TenantId`	`additional.fields`	`metadata.product_deployment_id`
`uid`	`principal.user.userid`	`target.user.userid`
`USER`	`principal.user.user_display_name`	`target.user.userid`	"<85>Sep 24 14:33:59 abc sudo: abc : \r\nTTY=unknown ; PWD=/abc ; USER=abc ; COMMAND=/sbin/iptables -t nat -nL \r\n--line-number"
`user`	`principal.user.userid`	`target.user.userid`	„29>Jan 16 11:28:00 san-auth-1-irl2 tac_plus[17329]: login failure: user 1.1.1.1 (1.1.1.1) vty0“
`user`	`principal.user.userid`	`target.user.userid`	"<87>Jul 15 10:27:01 xpgjrconfdb01 crond[1045]: pam_unix(crond:account): expired password for user root (password aged)"

Delta der Ereignistypzuordnung

Mehrere Ereignisse, die zuvor als generisches Ereignis klassifiziert wurden, werden jetzt korrekt mit aussagekräftigen Ereignistypen klassifiziert.

In der folgenden Tabelle ist die Änderung bei der Verarbeitung von Okta-Ereignistypen vor dem 23. September 2025 und danach aufgeführt (in den Spalten Old event_type und Current event_type).

eventType aus dem Log	Alter event_type	Aktueller event_type
`aix_event_type=CRON_Start`	`USER_LOGIN`	`PROCESS_LAUNCH`
`CRYPTO_KEY_USER`	`NETWORK_CONNECTION`	`USER_LOGIN`
`FILE_Mknod`	`USER_LOGIN`	`FILE_CREATION`
`FILE_Rename`	`USER_LOGIN`	`FILE_MODIFICATION`
`FILE_Stat`	`USER_LOGIN`	`FILE_OPEN`
`FILE_Unlink`	`USER_LOGIN`	`FILE_DELETION`
`FS_Chabc`	`USER_LOGIN`	`PROCESS_UNCATEGORIZED`
`FS_Mkdir`	`USER_LOGIN`	`FILE_CREATION`
`FS_Rmdir`	`USER_LOGIN`	`FILE_DELETION`
`PROC_Execute`	`USER_LOGIN`	`PROCESS_LAUNCH`
`type=ANOM_ABEND`	`STATUS_UPDATE`	`PROCESS_TERMINATION`
`type=ANOM_PROMISCUOUS`		`SETTING_MODIFICATION`
`type=CRED_REFR`	`USER_LOGIN`	`USER_CHANGE_PERMISSIONS`
`type=PROCTILE`	`PROCESS_UNCATEGORIZED`	`PROCESS_LAUNCH`
`type=SERVICE_START`	`USER_RESOURCE_ACCESS`	`SERVICE_START`
`type=SERVICE_STOP`	`USER_RESOURCE_ACCESS`	`SERVICE_STOP`
`type=USER_ACCT`	`USER_LOGIN/SETTING_MODIFICTION`	`USER_LOGIN`
`type=USER_MGMT`	`SETTING_MODIFICATION/GROUP_MODIFICATION`	`GROUP_MODIFICATION`
`USER_ERR`	`USER_LOGOUT`	`USER_LOGIN`

Weitere Änderungen

Die doppelte Zuordnung von res wurde aus security_result.description entfernt. Das wird in security_result.action_details erfasst.
Unnötige auditd_msg_data aus zusätzlichen Feldern entfernt.
Unnötige auditd_msg_data aus security_result.summary entfernt.
Am type=ADD_USER wurde die doppelte Zuordnung von acct zu target.user.display_name entfernt. Sie ist bereits unter target.user.userid zugeordnet.
Die doppelte Zuordnung von comm wurde aus principal.process.command_line und principal.process.file.names entfernt. Das wird in principal.application erfasst.
Die doppelte Zuordnung von target.hostname wurde entfernt, wenn der Wert in principal vorhanden ist.
Unnötige fest codierte Zuordnung von target.resource.type zu SETTING wurde entfernt.
Die Zuordnungen für „Über“-Labels wurden entfernt, da sie eingestellt wurden.
Korrigierte Zuordnung: IPs werden jetzt an principal.ip und nicht an principal.hostname weitergeleitet.
Die Wiederholung von Ereignissen wurde korrigiert.

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