Problembehandlung für CEF und Syslog mithilfe von AMA-Connectoren

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. Nutzen Sie diesen Leitfaden, um Probleme bei der Datenerfassung Ihrer Log-Forwarder-Maschinen 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
    • Lastenausgleiche
    • Netzwerksicherheitsgruppen

Status der Azure Monitor-Agent-Erweiterung überprüfen

  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. Überprüfen Sie auf dem AzureMonitorLinuxAgent-Erweiterungsblatt das Feld Version.
  2. Stellen Sie sicher, dass die Version eine der 2 bis 3 neuesten 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-Dienst und der RSyslog-Dienst 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 /etc/rsyslog.conf und den Dateien in /etc/rsyslog.d/.

  1. Portkonfiguration überprüfen:

    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

Portstatus überprüfen

Überprüfen Sie, ob die erforderlichen Ports aktiv sind (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 die Firewallregeln die Kommunikation zwischen folgenden Elementen ermöglichen:

  • 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. Falls verfügbar, sollte die Erfassung von Meldungen ohne Angabe von Gründen oder Schweregrad aktiviert werden.

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.

Fehlerhafte Zeichenmaskierung

  • Pipe-Zeichen (|) in Header-Werten müssen maskiert werden: \|
  • Backslashes () müssen maskiert werden: \\
  • Gleichheitszeichen (=) in Erweiterungen müssen maskiert werden: \=

Fehlende oder nicht zugeordnete Werte

  • Wenn ein Wert einem Standardfeld nicht zugeordnet werden kann, wird er in der AdditionalExtensions Spalte gespeichert.
  • Informationen zu Feldzuordnungen finden Sie unter CEF- und CommonSecurityLog-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 Traceflags nur während Fehlerbehebungssitzungen. Ablaufverfolgungsflags generieren umfangreiche Protokolle, die den Festplattenspeicher schnell füllen können.

  1. Bearbeiten Sie die AMA-Konfigurationsdatei:

    sudo vim /etc/default/azuremonitoragent

  2. Fügen Sie der Zeile MDSD_OPTIONS Traceflags 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 Traceflag und starten Sie den Agent nach Abschluss 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 Anlagenprotokolle:

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

Überprüfen der erfolgreichen Protokollverarbeitung

Wenn Traceflags aktiviert sind, können Sie anhand der Debugausgabe überprüfen, ob Protokolldateien korrekt verarbeitet werden.

ASA-Log-Erfassungsbeispiel

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, Traceflags nach Abschluss Ihrer Untersuchung zu deaktivieren, um eine übermäßige Datenträgernutzung zu verhindern.

Sammeln von Diagnoseinformationen

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

AMA-Problembehandlung ausführen

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