Problembehandlung bei CEF und Syslog über AMA-Connectors

Dieser Artikel enthält Anleitungen zur Problembehandlung für common Event Format (CEF) und Syslog-Datensammlung mit dem Azure Monitor Agent (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:

• Erfassen von syslog- und CEF-Nachrichten für Microsoft Sentinel mit dem Azure Monitor-Agent
• CEF über AMA-Datenverbinder – Konfigurieren einer bestimmten Appliance oder eines bestimmten Geräts
• Übersicht über den Azure Monitor-Agent

Architekturübersicht

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

Wichtige Komponenten:

• RSyslog/Syslog-ng: Empfängt Protokolle am Port 514 und leitet sie an AMA weiter.
• Azure Monitor Agent: Verarbeitet Protokolle gemäß Datensammlungsregeln (DATA Collection Rules, DCR)
• Datensammlungsregel: Definiert, welche Protokolle erfasst werden sollen und wo 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 sicherzustellen, dass Protokolle beim Forwarder ankommen.

   sudo tcpdump -i any port 514 -A -vv
   

2. Überprüfen Sie, ob Die Protokollquelle so konfiguriert ist, dass Nachrichten an die richtige Weiterleitungs-IP-Adresse gesendet werden.

3. Überprüfen Sie auf Infrastrukturkomponenten, die sich auf die Konnektivität auswirken können:

   • Firewalls
   • Lastenausgleichsgeräte
   • Netzwerksicherheitsgruppen

Überprüfen des Status der Erweiterung des Azure Monitor-Agents

1. Navigieren Sie im Azure-Portal zu Ihrem virtuellen Protokollweiterleitungscomputer.
2. Wählen Sie Erweiterungen und Anwendungen aus.
3. Wählen Sie die AzureMonitorLinuxAgent-Erweiterung aus.
4. Stellen Sie sicher, dass der Status zeigt, dass die Bereitstellung erfolgreich war.

Überprüfen der Agentversion

1. Überprüfen Sie im AzureMonitorLinuxAgent-Erweiterungsblatt das Feld Version.
2. Stellen Sie sicher, dass die Version eine der 2-3 neuesten Versionen ist. Weitere Informationen zu den neuesten Versionen finden Sie unter AMA-Versionsdetails .

Problembehandlung auf Agentebene

Stellen Sie sicher, dass der Agent und der RSyslog-Dienst ausgeführt sind.

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 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:

   # Azure Monitor Agent configuration: forward logs to azuremonitoragent
   

Überprüfen des Portstatus

Ü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 bestätigt:

• RSyslog überwacht Port 514 (TCP und UDP)
• MDSD (AMA-Komponente) überwacht Port 28330 (TCP)

Überprüfen der Konfiguration der Datenerfassungsregeln

Überprüfen Sie, ob der DCR für den Agent ordnungsgemäß konfiguriert ist.

Für CEF-Logs:

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

Sicherstellen, dass Firewallregeln die Kommunikation zwischen ermöglichen:

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

Konfiguration der Datensammlungsregel

Aktivieren aller Einrichtungen zur Problembehandlung

Für die anfängliche Problembehandlung:

1. Navigieren Sie im Azure-Portal zu Ihrer Datensammlungsregel.
2. Aktivieren Sie alle Syslog-Einrichtungen.
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.

Common Event Format (CEF)-Validierung

Anforderungen an das CEF-Format

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

Allgemeine 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 keinem Standardfeld zugeordnet werden kann, wird er in der AdditionalExtensions Spalte gespeichert.
• Siehe CEF und CommonSecurityLog-Feldzuordnungen für Feldzuordnungen

Suchen Sie für die vollständige CEF-Spezifikation nach der Dokumentation "Implementing ArcSight Common Event Format (CEF)".

Erweiterte Problembehandlung

Aktivieren der Diagnoseablaufverfolgung

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 Trace-Flag, und starten Sie den Agenten nach der Problembehandlung wieder 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 spezifische Systemprotokolle:

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

Überprüfen der erfolgreichen Protokollverarbeitung

Wenn Trace-Flags aktiviert sind, können Sie anhand der Debug-Ausgabe überprüfen, ob die Protokolle korrekt verarbeitet werden.

ASA-Log-Erfassungsbeispiel

Bei Cisco ASA-Protokollen wird die erfolgreiche Verarbeitung in den Protokollen angezeigt als:

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 anerkannt.
• Das Protokoll wird in ODS (Operations Data Service) hochgeladen.
• Eine Anforderungs-ID wird zur Nachverfolgung generiert.
• Die Nutzlast enthält ordnungsgemäß formatierte JSON-Daten.

CEF-Log-Erfassungsbeispiel

Die erfolgreiche Verarbeitung von CEF-Protokollen wird 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

Sammeln von Diagnoseinformationen

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

Führen Sie die AMA-Problembehandlung aus

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 gespeichert in /tmp/troubleshooter_output_file.log.

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

• Aufnehmen von Syslog- und CEF-Nachrichten mit Azure Monitor Agent
• Übersicht über CEF und Syslog via AMA-Connectoren
• Problembehandlung für den Azure Monitor-Agent
• Datensammlungsregeln in Azure Monitor