Freigeben über

[Veraltet] Problembehandlung für CEF- oder Syslog-Datenconnectors

  • Artikel

Wichtig

Die Protokollsammlung aus vielen Appliances und Geräten wird jetzt vom Common Event Format (CEF) über AMA, Syslog über AMA oder benutzerdefinierte Protokolle über den AMA-Datenconnector in Microsoft Sentinel unterstützt. Weitere Informationen finden Sie unter Suchen Ihres Microsoft Sentinel-Datenconnectors.

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die den EOL-Status (End-of-Life-Status, Dienstende) erreicht hat. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS End-of-Life-Leitfaden.

In diesem Artikel werden gängige Methoden für die Überprüfung und Problembehandlung eines CEF- oder Syslog-Datenconnectors für Microsoft Sentinel beschrieben.

Wenn Ihre Protokollnachrichten beispielsweise nicht in den Tabellen Syslog oder CommonSecurityLog erscheinen, kann es sein, dass Ihre Datenquelle nicht richtig verbunden ist. Möglicherweise gibt es auch einen anderen Grund, warum Ihre Daten nicht empfangen werden.

Wenn die Datei security_events.conf oder security-omsagent.config.conf fehlt oder der rsyslog-Server nicht an Port 514 lauscht, sind dies weitere Anzeichen für eine fehlerhafte Connectorbereitstellung.

Weitere Informationen finden Sie unter Verbinden der externen Lösung mithilfe von Common Event Format und Sammeln von Daten aus Linux-basierten Quellen mithilfe von Syslog.

Wenn Sie Ihren Connector mit einer anderen als der dokumentierten Methode bereitgestellt haben und Probleme auftreten, empfehlen wir Ihnen, die Bereitstellung zu verwerfen und noch einmal von vorne zu beginnen, diesmal gemäß den dokumentierten Anweisungen.

In diesem Artikel erfahren Sie, wie Sie Probleme mit CEF- oder Syslog-Connectors mit dem Log Analytics-Agent beheben. Informationen zur Problembehandlung im Zusammenhang mit der Erfassung von CEF-Protokollen über den Azure Monitor-Agent (AMA) finden Sie unter Connectoranweisungen Common Event Format (CEF) über AMA.

Wichtig

Am 28. Februar 2023 wurden Änderungen am CommonSecurityLog-Tabellenschema eingeführt. Nach dieser Änderung müssen Sie möglicherweise benutzerdefinierte Abfragen überprüfen und aktualisieren. Weitere Informationen finden Sie im Abschnitt empfohlene Aktionen in diesem Blogbeitrag. Sofort einsetzbare Inhalte (Erkennungen, Huntingabfragen, Arbeitsmappen, Parser usw.) werden von Microsoft Sentinel aktualisiert.

Zur Verwendung dieses Artikels

Wenn die Informationen in diesem Artikel nur für Syslog oder nur für CEF-Connectors relevant sind, werden sie in unterschiedlichen Registerkarten angezeigt. Stellen Sie sicher, dass Sie die Anweisungen auf der richtigen Registerkarte für Ihren Connectortyp verwenden.

Wenn Sie beispielsweise Probleme mit einem CEF-Connector behandeln, beginnen Sie mit Überprüfen der CEF-Konnektivität. Wenn Sie die Problembehandlung für einen Syslog-Connector durchführen, beginnen Sie mit Überprüfen der Voraussetzungen für Ihren Datenconnector.

Überprüfen der CEF-Konnektivität

Nachdem Sie Ihre Protokollweiterleitung bereitgestellt und Ihre Sicherheitslösung zum Senden von CEF-Nachrichten konfiguriert haben, führen Sie die Schritte in diesem Abschnitt aus, um die Konnektivität zwischen Ihrer Sicherheitslösung und Microsoft Sentinel zu überprüfen.

Dieses Verfahren ist nur für CEF-Verbindungen und nicht für Syslog-Verbindungen relevant.

  1. Stellen Sie sicher, dass Sie folgenden Voraussetzungen erfüllt sind:

    • Sie müssen über erhöhte Berechtigungen (sudo) auf dem Computer mit der Protokollweiterleitung verfügen.

    • Auf dem Computer mit der Protokollweiterleitung muss Python 2.7 oder 3 installiert sein. Verwenden Sie den Befehl python --version zum Überprüfen dieser Voraussetzung.

    • Möglicherweise benötigen Sie während dieses Vorgangs die ID und den Primärschlüssel des Arbeitsbereichs. Sie finden diese in der Arbeitsbereichsressource unter Agent-Verwaltung.

  2. Öffnen Sie im Microsoft Sentinel-Navigationsmenü den Menüpunkt Protokolle. Führen Sie mithilfe des Schemas CommonSecurityLog eine Abfrage aus, um zu überprüfen, ob Sie Protokolle von Ihrer Sicherheitslösung erhalten.

    Es kann möglicherweise ca. 20 Minuten dauern, bis Ihre Protokolle in Log Analytics angezeigt werden.

  3. Wenn Sie keine Ergebnisse der Abfrage sehen, überprüfen Sie, ob Ihre Sicherheitslösung Protokollnachrichten erzeugt. Oder versuchen Sie, einige Aktionen durchzuführen, um Protokollnachrichten zu erzeugen, und überprüfen Sie, ob die Nachrichten an den von Ihnen bestimmten Syslog-Forwarder weitergeleitet werden.

  4. Um die Konnektivität zwischen Ihrer Sicherheitslösung, dem Log-Forwarder und Microsoft Sentinel zu überprüfen, führen Sie das folgende Skript auf dem Log-Forwarder aus (wobei Sie die Arbeitsbereichs ID anstelle des Platzhalters verwenden). Das Skript überprüft, ob der Daemon an den richtigen Ports lauscht, die Weiterleitung ordnungsgemäß konfiguriert ist und die Kommunikation zwischen dem Daemon und dem Log Analytics-Agent nicht blockiert wird. Außerdem sendet es auch TestCommonEventFormat-Pseudonachrichten, um die End-to-End-Konnektivität zu überprüfen. 

    sudo wget -O cef_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_troubleshoot.py&&sudo python cef_troubleshoot.py [WorkspaceID]

    • Möglicherweise werden Sie in einer Meldung aufgefordert, einen Befehl auszuführen, um ein Problem mit der Zuordnung im Feld Computer zu beheben. Ausführliche Informationen finden Sie in der Erläuterung im Validierungsskript.

    • Möglicherweise werden Sie in einer Meldung aufgefordert, einen Befehl auszuführen, um ein Problem mit der Analyse von Cisco ASA-Firewallprotokollen zu beheben. Ausführliche Informationen finden Sie in der Erläuterung im Validierungsskript.

Erläuterung des CEF-Überprüfungsskripts

Im folgenden Abschnitt wird das CEF-Überprüfungsskript für den rsyslog-Daemon und den syslog-ng-Daemon beschrieben.

rsyslog-Daemon

Für einen rsyslog-Daemon führt das CEF-Überprüfungsskript die folgenden Prüfungen aus:

  1. Überprüft, ob die Datei
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    vorhanden und gültig ist.

  2. Überprüft, ob die Datei den folgenden Text enthält:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. Überprüft anhand des folgenden Befehls, ob die Analyse für Cisco ASA-Firewallereignisse wie erwartet konfiguriert ist:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • Wenn ein Problem mit der Analyse vorliegt, generiert das Skript eine Fehlermeldung, in der Sie aufgefordert werden, den folgenden Befehl manuell auszuführen (ersetzen Sie den Platzhalter durch die Arbeitsbereichs-ID). Mit dem Befehl wird die korrekte Analyse sichergestellt, und der Agent wird neu gestartet.

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. Überprüft anhand des folgenden Befehls, ob das Feld Computer in der Syslog-Quelle im Log Analytics-Agent ordnungsgemäß zugeordnet ist:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • Wenn ein Problem mit der Zuordnung vorliegt, generiert das Skript eine Fehlermeldung, in der Sie aufgefordert werden, den folgenden Befehl manuell auszuführen (ersetzen Sie den Platzhalter durch die Arbeitsbereichs-ID). Mit dem Befehl wird die korrekte Zuordnung sichergestellt, und der Agent wird neu gestartet.

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. Überprüft, ob auf dem Computer Sicherheitsverbesserungen vorhanden sind, die möglicherweise den Netzwerkverkehr blockieren (z. B. eine Hostfirewall).

  6. Überprüft, ob der Syslog-Daemon (rsyslog) ordnungsgemäß konfiguriert ist und Nachrichten, die er als CEF identifiziert, an den Log Analytics-Agent an TCP-Port 25226 senden kann:

    Konfigurationsdatei: /etc/rsyslog.d/security-config-omsagent.conf

    if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

  7. Startet den Syslog-Daemon und den Log Analytics-Agent neu:

    service rsyslog restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. Überprüft, ob die erforderlichen Verbindungen hergestellt wurden: TCP 514 für das Empfangen von Daten, TCP 25226 für die interne Kommunikation zwischen dem Syslog-Daemon und dem Log Analytics-Agent:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Überprüft, ob der Syslog-Daemon Daten an Port 514 empfängt und ob der Agent Daten an Port 25226 empfängt:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Sendet Pseudodaten an Port 514 von localhost. Diese Daten sollten mithilfe der folgenden Abfrage im Microsoft Sentinel-Arbeitsbereich zu erkennen sein:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

syslog-ng daemon

Für einen syslog-ng-Daemon führt das CEF-Überprüfungsskript die folgenden Prüfungen aus:

  1. Überprüft, ob die Datei
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    vorhanden und gültig ist.

  2. Überprüft, ob die Datei den folgenden Text enthält:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. Überprüft anhand des folgenden Befehls, ob die Analyse für Cisco ASA-Firewallereignisse wie erwartet konfiguriert ist:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • Wenn ein Problem mit der Analyse vorliegt, generiert das Skript eine Fehlermeldung, in der Sie aufgefordert werden, den folgenden Befehl manuell auszuführen (ersetzen Sie den Platzhalter durch die Arbeitsbereichs-ID). Mit dem Befehl wird die korrekte Analyse sichergestellt, und der Agent wird neu gestartet.

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. Überprüft anhand des folgenden Befehls, ob das Feld Computer in der Syslog-Quelle im Log Analytics-Agent ordnungsgemäß zugeordnet ist:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • Wenn ein Problem mit der Zuordnung vorliegt, generiert das Skript eine Fehlermeldung, in der Sie aufgefordert werden, den folgenden Befehl manuell auszuführen (ersetzen Sie den Platzhalter durch die Arbeitsbereichs-ID). Mit dem Befehl wird die korrekte Zuordnung sichergestellt, und der Agent wird neu gestartet.

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. Überprüft, ob auf dem Computer Sicherheitsverbesserungen vorhanden sind, die möglicherweise den Netzwerkverkehr blockieren (z. B. eine Hostfirewall).

  6. Überprüft, ob der Syslog-Daemon (rsyslog-ng) ordnungsgemäß konfiguriert ist und Nachrichten, die er (über einen regulären Ausdruck) als CEF identifiziert, an den Log Analytics-Agent an TCP-Port 25226 senden kann:

    • Konfigurationsdatei: /etc/syslog-ng/conf.d/security-config-omsagent.conf

      filter f_oms_filter {match(\"CEF\|ASA\" ) ;};destination oms_destination {tcp(\"127.0.0.1\" port(25226));};
log {source(s_src);filter(f_oms_filter);destination(oms_destination);};

  7. Startet den Syslog-Daemon und den Log Analytics-Agent neu:

    service syslog-ng restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. Überprüft, ob die erforderlichen Verbindungen hergestellt wurden: TCP 514 für das Empfangen von Daten, TCP 25226 für die interne Kommunikation zwischen dem Syslog-Daemon und dem Log Analytics-Agent:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Überprüft, ob der Syslog-Daemon Daten an Port 514 empfängt und ob der Agent Daten an Port 25226 empfängt:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Sendet Pseudodaten an Port 514 von localhost. Diese Daten sollten mithilfe der folgenden Abfrage im Microsoft Sentinel-Arbeitsbereich zu erkennen sein:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

Überprüfen der Voraussetzungen für Ihren Datenconnector

Verwenden Sie die folgenden Abschnitte, um die Voraussetzungen für den CEF- oder Syslog-Datenconnector zu überprüfen.

Virtueller Azure-Computer als CEF-Collector

Wenn Sie einen virtuellen Azure-Computer als CEF-Collector verwenden, überprüfen Sie Folgendes:

  • Stellen Sie vor dem Bereitstellen des Python-Skripts für den Common Event Format-Datenconnector sicher, dass Ihr virtueller Computer noch nicht mit einem vorhandenen Log Analytics-Arbeitsbereich verbunden ist. Sie finden diese Informationen in der VM-Liste für den Log Analytics-Arbeitsbereich, in der eine mit einem Syslog-Arbeitsbereich verbundene VM als Verbunden aufgeführt wird.

  • Stellen Sie sicher, dass Microsoft Sentinel mit dem richtigen Log Analytics-Arbeitsbereich verbunden und die SecurityInsights-Lösung installiert ist.

    Weitere Informationen finden Sie unter Schritt 1: Bereitstellen der Protokollweiterleitung.

  • Stellen Sie sicher, dass Ihr Computer geringstenfalls mit den erforderlichen Mindestanforderungen ordnungsgemäß dimensioniert ist. Weitere Informationen finden Sie unter Voraussetzungen.

Lokale VM oder Nicht-Azure-VM

Wenn Sie einen lokalen Computer oder eine Nicht-Azure-VM für Ihren Datenconnector verwenden, stellen Sie sicher, dass Sie das Installationsskript unter einer Neuinstallation eines unterstützten Linux-Betriebssystems ausgeführt haben:

Tipp

Sie finden dieses Skript auch auf der Datenconnectorseite Common Event Format in Microsoft Sentinel.

sudo wget -O cef_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_installer.py&&sudo python cef_installer.py <WorkspaceId> <Primary Key>

Aktivieren der CEF-Komponente und der Protokollschweregradsammlung

Der Syslog-Server, entweder rsyslog oder syslog-ng, leitet alle in der relevanten Konfigurationsdatei definierten Daten weiter, die automatisch durch die in Ihrem Log Analytics-Arbeitsbereich definierten Einstellungen aufgefüllt werden.

Stellen Sie sicher, dass Sie Details zu den Facilitys und Schweregraden der Protokolle hinzufügen, die Sie in Microsoft Sentinel erfassen möchten. Der Konfigurationsvorgang dauert etwa 20 Minuten.

Weitere Informationen finden Sie unter Erläuterung des Bereitstellungsskripts.

Führen Sie beispielsweise für einen rsyslog-Server den folgenden Befehl aus, um die aktuellen Einstellungen für die Syslog-Weiterleitung anzuzeigen, und überprüfen Sie alle Änderungen an der Konfigurationsdatei:

cat /etc/rsyslog.d/security-config-omsagent.conf

In diesem Fall sollte für rsyslog eine Ausgabe ähnlich der folgenden angezeigt werden:

if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

Beheben von Betriebssystemproblemen

Im Rahmen dieses Abschnitts wird beschrieben, wie Sie Probleme beheben, die sehr wahrscheinlich mit der Betriebssystemkonfiguration zusammenhängen.

So beheben Sie Betriebssystemprobleme:

  1. Falls Sie diesen Schritt noch nicht ausgeführt haben, überprüfen Sie, ob Sie mit einem unterstützten Betriebssystem und einer unterstützten Python-Version arbeiten. Weitere Informationen finden Sie unter Voraussetzungen.

  2. Wenn sich Ihr virtueller Computer in Azure befindet, überprüfen Sie, ob die Netzwerksicherheitsgruppe (NSG) eingehende TCP/UDP-Verbindungen von Ihrem Protokollclient (Sender) an Port 514 zulässt.

  3. Vergewissern Sie sich, dass Pakete beim Syslog-Collector eintreffen. Führen Sie Folgendes aus, um die Syslog-Pakete zu erfassen, die am Syslog-Collector eintreffen:

    tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv

  4. Führen Sie eines der folgenden Verfahren aus:

    • Wenn keine Pakete eintreffen, bestätigen Sie die Sicherheitsgruppenberechtigungen für die Netzwerksicherheitsgruppe (NSG) und den Routingpfad zum Syslog-Collector.

    • Wenn Pakete eintreffen, vergewissern Sie sich, dass sie nicht abgelehnt werden.

    Wenn abgelehnte Pakete angezeigt werden, vergewissern Sie sich, dass die IP-Tabellen die Verbindungen nicht blockieren.

    Führen Sie Folgendes aus, um zu bestätigen, dass Pakete nicht abgelehnt werden:

    watch -n 2 -d iptables -nvL

  5. Überprüfen Sie, ob der CEF-Server die Protokolle verarbeitet. Führen Sie folgenden Befehl aus:

    tail -f /var/log/messages or tail -f /var/log/syslog

    Alle CEF-Protokolle, die verarbeitet werden, werden im Nur-Text-Format angezeigt.

  6. Vergewissern Sie sich, dass der rsyslog-Server an TCP/UDP-Port 514 lauscht. Führen Sie Folgendes aus:

    netstat -anp | grep syslog

    Wenn CEF- oder ASA-Protokolle an Ihren Syslog-Collector gesendet werden, sollte für TCP-Port 25226 eine hergestellte Verbindung angezeigt werden.

    Zum Beispiel:

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    Wenn die Verbindung blockiert wird, verwenden Sie möglicherweise eine blockierte SELinux-Verbindung mit dem OMS-Agent, oder ein Firewallprozess wird blockiert. Verwenden Sie die weiter unten angegebenen relevanten Anweisungen, um das Problem zu ermitteln.

SELinux blockiert die Verbindung mit dem OMS-Agent

Im Rahmen dieses Verfahrens wird beschrieben, wie Sie überprüfen, ob SELinux derzeit den Status permissive aufweist oder eine Verbindung mit dem OMS-Agent blockiert. Dieses Verfahren ist relevant, wenn Ihr Betriebssystem eine Distribution von RedHat oder CentOS und sowohl für CEF- als auch Syslog-Datenconnectors vorgesehen ist.

Hinweis

Die Microsoft Sentinel-Unterstützung für CEF und Syslog umfasst nur die FIPS-Härtung. Andere Härtungsmethoden wie SELinux oder CIS werden derzeit nicht unterstützt.

  1. Führen Sie Folgendes aus:

    sestatus

    Der Status wird mit einer der folgenden Optionen angezeigt:

    • disabled. Diese Konfiguration wird für Ihre Verbindung mit Microsoft Sentinel unterstützt.
    • permissive. Diese Konfiguration wird für Ihre Verbindung mit Microsoft Sentinel unterstützt.
    • enforced. Diese Konfiguration wird nicht unterstützt, und Sie müssen entweder den Status deaktivieren oder auf permissive festlegen.

  2. Wenn der Status derzeit auf enforced festgelegt ist, deaktivieren Sie ihn vorübergehend, um zu überprüfen, ob die Verbindung deshalb blockiert wurde. Führen Sie Folgendes aus:

    setenforce 0

    Hinweis

    Durch diesen Schritt wird SELinux nur deaktiviert, bis der Server neu gestartet wird. Ändern Sie die SELinux-Konfiguration so, dass sie deaktiviert ist.

  3. Führen Sie Folgendes aus, um zu überprüfen, ob die Änderung erfolgreich war:

    getenforce

    Der Status permissive sollte zurückgegeben werden.

Wichtig

Dieses Einstellungsupdate geht verloren, wenn das System neu gestartet wird. Ändern Sie die Datei /etc/selinux/config, indem Sie den Wert SELINUX in SELINUX=permissive ändern, um diese Einstellung dauerhaft auf permissive zu aktualisieren.

Weitere Informationen finden Sie in der RedHat-Dokumentation.

Blockierte Firewallrichtlinie

Im Rahmen dieses Verfahrens wird beschrieben, wie Sie überprüfen, ob eine Firewallrichtlinie die Verbindung zwischen dem Rsyslog-Daemon und dem OMS-Agent blockiert, und wie Sie sie bei Bedarf deaktivieren. Dieses Verfahren ist sowohl für CEF- als auch für Syslog-Datenconnectors relevant.

  1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob in den IP-Tabellen Ablehnungen enthalten sind, und geben Sie den Datenverkehr an, der von der Firewallrichtlinie gelöscht wird:

    watch -n 2 -d iptables -nvL

  2. Erstellen Sie eine Richtlinienregel, um die Verbindungen zuzulassen und die Firewallrichtlinie aktiviert zu lassen. Fügen Sie nach Bedarf Regeln hinzu, um die TCP/UDP-Ports 25226 und 25224 über die aktive Firewall zuzulassen.

    Zum Beispiel:

    Every 2.0s: iptables -nvL                      rsyslog: Wed Jul  7 15:56:13 2021

Chain INPUT (policy ACCEPT 6185K packets, 2466M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 6792K packets, 6348M bytes)
 pkts bytes target     prot opt in     out     source               destination

  3. Fügen Sie nach Bedarf Regeln hinzu, um eine Regel zu erstellen, die die TCP/UDP-Ports 25226 und 25224 über die aktive Firewall zulässt.

    1. Führen Sie zum Installieren des Firewallrichtlinien-Editors Folgendes aus:

      yum install policycoreutils-python

    2. Fügen Sie der Firewallrichtlinie die Firewallregeln hinzu. Zum Beispiel:

      sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25226  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p udp --dport 25224  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25224  -j ACCEPT

    3. Überprüfen Sie, ob die Ausnahme hinzugefügt wurde. Führen Sie Folgendes aus:

      sudo firewall-cmd --direct --get-rules ipv4 filter INPUT

    4. Laden Sie die Firewall erneut. Führen Sie Folgendes aus:

      sudo firewall-cmd --reload

Hinweis

Führen Sie sudo systemctl disable firewalld aus, um die Firewall zu deaktivieren.

Wenn das Problem mit den zuvor im Artikel beschriebenen Schritten nicht behoben werden kann, liegt möglicherweise ein Konnektivitätsproblem zwischen dem OMS-Agent und dem Microsoft Sentinel-Arbeitsbereich vor.

Setzen Sie in solchen Fällen die Problembehandlung fort, indem Sie Folgendes überprüfen:

  • Stellen Sie sicher, dass Pakete, die am TCP/UDP-Port 514 eintreffen, im Syslog-Collector angezeigt werden.

  • Stellen Sie sicher, dass Sie in die lokale Protokolldatei geschriebene Protokolle anzeigen können (entweder /var/log/messages oder /var/log/syslog).

  • Stellen Sie sicher, dass Datenpakete über Port 25226 übertragen werden.

  • Stellen Sie sicher, dass Ihr virtueller Computer über eine ausgehende Verbindung mit Port 443 über TCP verfügt oder eine Verbindung mit den Log Analytics-Endpunkten herstellen kann.

  • Stellen Sie sicher, dass Sie über Ihre Firewallrichtlinie Zugriff auf die erforderlichen URLs aus Ihrem CEF-Collector haben. Weitere Informationen finden Sie unter Firewallanforderungen.

Führen Sie den folgenden Befehl aus, um zu ermitteln, ob der Agent erfolgreich mit Azure kommuniziert oder ob die Verbindung des OMS-Agents mit dem Log Analytics-Arbeitsbereich blockiert ist.

Heartbeat
 | where Computer contains "<computername>"
 | sort by TimeGenerated desc

Ein Protokolleintrag wird zurückgegeben, wenn der Agent erfolgreich kommuniziert. Andernfalls wird der OMS-Agent möglicherweise blockiert.