Problembehandlung bei CEF und Syslog über AMA-Connectors

Dieser Artikel enthält Anleitungen zur Problembehandlung für das Common Event Format (CEF) und die Syslog-Datensammlung mithilfe des Azure Monitor-Agents (AMA) in Microsoft Sentinel. Verwenden Sie diesen Leitfaden, um Erfassungsprobleme mit Ihren Protokollweiterleitungscomputern zu diagnostizieren und zu beheben. Die Befehle und Konfigurationen sollten auf den Protokollweiterleitungscomputern ausgeführt werden, auf denen AMA und RSyslog/Syslog-ng installiert sind.

Bevor Sie mit der Problembehandlung beginnen, machen Sie sich mit den folgenden Artikeln vertraut:

Architekturübersicht

Das folgende Diagramm veranschaulicht den Datenfluss von Protokollquellen zu Microsoft Sentinel-/Log Analytics-Arbeitsbereichen über RSyslog und den Azure Monitor-Agent.

Diagramm: Datenfluss von der Quelle zu Log Analytics über RSyslog und AMA

Wichtige Komponenten:

  • RSyslog/Syslog-ng: Empfängt Protokolle an Port 514 und leitet sie an AMA weiter.
  • Azure Monitor-Agent: Verarbeitet Protokolle gemäß Datensammlungsregeln (Data Collection Rules, DCR)
  • Datensammlungsregel: Definiert, welche Protokolle gesammelt werden und wohin sie gesendet werden sollen.

Erste Überprüfungsschritte

Überprüfen, ob Protokolle empfangen werden

Es kann bis zu 20 Minuten dauern, bis Protokolle nach der Konfiguration in Microsoft Sentinel angezeigt werden.

  1. Führen Sie tcpdump aus, um zu überprüfen, ob Protokolle bei der Weiterleitung eintreffen:

    sudo tcpdump -i any port 514 -A -vv

  2. Vergewissern Sie sich, dass Ihre Protokollquelle so konfiguriert ist, dass Nachrichten an die richtige IP-Adresse der Weiterleitung gesendet werden.

  3. Suchen Sie nach Infrastrukturkomponenten, die sich auf die Konnektivität auswirken können:

    • Firewalls
    • Lastenausgleichsmodule
    • Netzwerksicherheitsgruppen

Überprüfen der status für Azure Monitor-Agent-Erweiterung

  1. Navigieren Sie im Azure-Portal zu Ihrem virtuellen Protokollweiterleitungscomputer.
  2. Wählen Sie Erweiterungen + Anwendungen aus.
  3. Wählen Sie die Erweiterung AzureMonitorLinuxAgent aus.
  4. Vergewissern Sie sich, dass im Status"Bereitstellung erfolgreich" angezeigt wird.

Überprüfen der Agent-Version

  1. Aktivieren Sie auf dem Blatt der AzureMonitorLinuxAgent-Erweiterung das Feld Version .
  2. Stellen Sie sicher, dass die Version eine der neuesten 2-3-Versionen ist. Die neuesten Versionen finden Sie unter Details zur AMA-Version .

Hinweis

Das Rollout neuer Versionen kann nach der ersten Veröffentlichung bis zu 5 Wochen dauern.

Problembehandlung auf Agentebene

Stellen Sie sicher, dass der Agent und die RSyslog-Dienste ausgeführt werden.

sudo systemctl status azuremonitoragent
sudo systemctl status rsyslog
sudo systemctl status syslog-ng.service # If using Syslog-ng

Überprüfen der RSyslog-Konfiguration

Die RSyslog-Konfiguration besteht aus - und - /etc/rsyslog.conf Dateien in /etc/rsyslog.d/.

  1. Überprüfen Der Portkonfiguration:

    grep -E 'imudp|imtcp' /etc/rsyslog.conf

    Erwartete Ausgabe:

    module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

  2. Überprüfen Sie, ob die AMA-Weiterleitungskonfiguration vorhanden ist:

    cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf

    Die Datei sollte mit folgendem Beginnen:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Überprüfen der port-status

Überprüfen Sie, ob die erforderlichen Ports lauschen:

sudo ss -lnp | grep -E "28330|514"

Erwartete Ausgabe:

udp   UNCONN 0      0      0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=5))
tcp   LISTEN 0      10     127.0.0.1:28330     0.0.0.0:*    users:(("mdsd",pid=1424,fd=1363))
tcp   LISTEN 0      25     0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=7))

Dadurch wird Folgendes bestätigt:

  • RSyslog lauscht an Port 514 (TCP und UDP)
  • MDSD (AMA-Komponente) lauscht an Port 28330 (TCP)

Überprüfen der Konfiguration der Datensammlungsregel

Überprüfen Sie, ob der DCR auf dem Agent ordnungsgemäß konfiguriert ist.

Für CEF-Protokolle:

sudo grep -i -r "SECURITY_CEF_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Für Cisco ASA-Protokolle:

sudo grep -i -r "SECURITY_CISCO_ASA_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Die Ausgabe sollte eine JSON-Zeichenfolge mit der DCR-Konfiguration anzeigen.

Überprüfen von Firewallregeln

Stellen Sie sicher, dass Firewallregeln die Kommunikation zwischen:

  • Protokollquelle und RSyslog (Port 514)
  • RSyslog und AMA (Port 28330)
  • AMA- und Azure-Endpunkte

Konfiguration der Datensammlungsregel

Aktivieren aller Einrichtungen für die Problembehandlung

Für die erste Problembehandlung:

  1. Navigieren Sie im Azure-Portal zu Ihrer Datensammlungsregel.
  2. Aktivieren Sie alle Syslog-Funktionen.
  3. Wählen Sie alle Protokollebenen aus.
  4. Wenn verfügbar, aktivieren Sie die Sammlung von Nachrichten ohne Einrichtung oder Schweregrad.

Weitere Informationen finden Sie unter Auswählen von Einrichtungen und Schweregraden.

CEF-Überprüfung (Common Event Format)

CEF-Formatanforderungen

CEF verwendet Syslog als Transportmechanismus mit dieser Struktur:

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

Beispiel:

Jan 18 11:07:53 host CEF:0|Vendor|Product|1.0|100|EventName|5|src=10.0.0.1 dst=10.0.0.2

Häufige PROBLEME bei der CEF-Formatierung

Falsches Headerformat

  • Stellen Sie sicher, dass die CEF-Version vorhanden ist: CEF:0|
  • Alle Kopfzeilenfelder müssen vorhanden sein und durch Pipezeichen (|) getrennt sein.

Ungültiges Escapezeichen

  • Pipezeichen (|) in Headerwerten müssen mit Escapezeichen versehen werden: \|
  • Umgekehrte Schrägstriche () müssen mit Escapezeichen versehen werden: \\
  • Gleichheitszeichen (=) in Erweiterungen müssen mit Escapezeichen versehen werden: \=

Fehlende oder nicht zugeordnete Werte

  • Wenn ein Wert einem Standardfeld nicht zugeordnet werden kann, wird er in der AdditionalExtensions Spalte gespeichert.
  • Weitere Informationen finden Sie unter CEF- und CommonSecurityLog-Feldzuordnungen für Feldzuordnungen.

Die vollständige CEF-Spezifikation finden Sie in der Dokumentation "Implementing ArcSight Common Event Format (CEF)".

Erweiterte Problembehandlung

Aktivieren der Diagnoseablaufverfolgung

Warnung

Aktivieren Sie Ablaufverfolgungsflags nur für Problembehandlungssitzungen. Ablaufverfolgungsflags generieren eine umfangreiche Protokollierung, die schnell Speicherplatz auf dem Datenträger füllen kann.

  1. Bearbeiten Sie die AMA-Konfigurationsdatei:

    sudo vim /etc/default/azuremonitoragent

  2. Fügen Sie der MDSD_OPTIONS Zeile Ablaufverfolgungsflags hinzu:

    export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"

  3. Starten Sie den Agent neu:

    sudo systemctl restart azuremonitoragent

  4. Reproduzieren Sie das Problem, und warten Sie einige Minuten.

  5. Überprüfen Sie Debuginformationen in /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Entfernen Sie das Ablaufverfolgungsflag, und starten Sie den Agent nach der Problembehandlung neu.

Überwachen der Protokollverarbeitung in Echtzeit

Anzeigen eingehender Protokolle während der Verarbeitung:

tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Filtern nach bestimmten Protokolltypen:

sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.* | grep -a "CEF"

Überprüfen Sie bestimmte Facility-Protokolle:

grep local0.info /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Überprüfen der erfolgreichen Protokollverarbeitung

Wenn Ablaufverfolgungsflags aktiviert sind, können Sie überprüfen, ob Protokolle ordnungsgemäß verarbeitet werden, indem Sie die Debugausgabe untersuchen.

Beispiel für die ASA-Protokollerfassung

Für Cisco ASA-Protokolle wird die erfolgreiche Verarbeitung in den Protokollen wie folgt angezeigt:

2022-01-18T22:00:14.8650520Z: virtual bool Pipe::SyslogCiscoASAPipeStage::PreProcess(std::shared_ptr<CanonicalEntity>) (.../mdsd/PipeStages.cc +604) [PipeStage] Processing CiscoASA event '%ASA-1-105003: (Primary) Monitoring on 123'

2022-01-18T22:00:14.8651330Z: virtual void ODSUploader::execute(const MdsTime&) (.../mdsd/ODSUploader.cc +325) Uploading 1 SECURITY_CISCO_ASA_BLOB rows to ODS.

2022-01-18T22:00:14.8653090Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CISCO_ASA_BLOB. Payload: {"DataType":"SECURITY_CISCO_ASA_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:28:49.775619Z","HostIP":"127.0.0.1","Message":" (Primary) Monitoring on 123","ProcessId":"","Severity":"info","Host":"localhost","ident":"%ASA-1-105003"}]}. Uncompressed size: 443. Request size: 322

Schlüsselindikatoren für eine erfolgreiche Verarbeitung:

  • Das Ereignis wird als CiscoASA-Ereignis erkannt.
  • Das Protokoll wird in ODS (Operations Data Service) hochgeladen.
  • Eine Anforderungs-ID wird für die Nachverfolgung generiert.
  • Die Nutzlast enthält ordnungsgemäß formatierte JSON-Daten.

Beispiel für die CEF-Protokollerfassung

Für CEF-Protokolle wird die erfolgreiche Verarbeitung wie folgt angezeigt:

2022-01-14T23:09:13.9087860Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CEF_BLOB. Payload: {"DataType":"SECURITY_CEF_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:08:49.731862Z","HostIP":"127.0.0.1","Message":"0|device1|PAN-OS|8.0.0|general|SYSTEM|3|rt=Nov 04 2018 07:15:46 GMTcs3Label=Virtual","ProcessId":"","Severity":"info","Host":"localhost","ident":"CEF"}]}. Uncompressed size: 482. Request size: 350

Schlüsselindikatoren für eine erfolgreiche CEF-Verarbeitung:

  • Der Datentyp ist SECURITY_CEF_BLOB
  • Die Uploadanforderung enthält einen gültigen Endpunkt.
  • Die CEF-Nachrichtenstruktur wird in der Nutzlast beibehalten.
  • Komprimierungsmetriken zeigen, dass die Daten für die Übertragung optimiert werden

Wichtig

Denken Sie daran, ablaufverfolgungsflags nach Abschluss der Untersuchung zu deaktivieren, um eine übermäßige Datenträgernutzung zu verhindern.

Sammeln von Diagnoseinformationen

Sammeln Sie vor dem Öffnen eines Supportfalls die folgenden Informationen:

Ausführen der AMA-Problembehandlung

Das Skript kann mit bestimmten Flags für verschiedene Protokolltypen ausgeführt werden.

  • --cef: Für Protokolle im allgemeinen Ereignisformat
  • --asa: Für Cisco ASA-Protokolle
  • --ftd: Für Cisco Firepower Threat Defense-Protokolle

Die Ausgabe wird in /tmp/troubleshooter_output_file.loggespeichert.

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py && sudo python3 Sentinel_AMA_troubleshoot.py [--cef | --asa | --ftd]

Verwandte Inhalte

  • Last updated on