Dela via


[Inaktuell] Felsöka din CEF- eller Syslog-dataanslutning

Viktigt!

Logginsamling från många enheter och enheter stöds nu av Common Event Format (CEF) via AMA, Syslog via AMA eller anpassade loggar via AMA-dataanslutningen i Microsoft Sentinel. Mer information finns i Hitta din Microsoft Sentinel-dataanslutningsapp.

Varning

Den här artikeln refererar till CentOS, en Linux-distribution som har nått EOL-status (End Of Life). Överväg att använda och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledningen.

I den här artikeln beskrivs vanliga metoder för att verifiera och felsöka en CEF- eller Syslog-dataanslutning för Microsoft Sentinel.

Om dina loggmeddelanden till exempel inte visas i Syslog - eller CommonSecurityLog-tabellerna kanske datakällan inte ansluter korrekt. Det kan också finnas en annan anledning till att dina data inte tas emot.

Andra symptom på en misslyckad anslutningsdistribution är när antingen security_events.conf - eller security-omsagent.config.conf-filerna saknas eller om rsyslog-servern inte lyssnar på port 514.

Mer information finns i Ansluta din externa lösning med Common Event Format och Samla in data från Linux-baserade källor med Syslog.

Om du distribuerade anslutningsappen med en annan metod än den dokumenterade proceduren, och om du har problem, rekommenderar vi att du skrotar distributionen och börjar om, den här gången enligt de dokumenterade anvisningarna.

Den här artikeln visar hur du felsöker CEF- eller Syslog-anslutningsappar med Log Analytics-agenten. Om du vill felsöka information som rör inmatning av CEF-loggar via Azure Monitor Agent (AMA) läser du CEF (Common Event Format) via AMA-anslutningsanvisningar .

Viktigt!

Den 28 februari 2023 introducerade vi ändringar i CommonSecurityLog-tabellschemat. Efter den här ändringen kan du behöva granska och uppdatera anpassade frågor. Mer information finns i avsnittet rekommenderade åtgärder i det här blogginlägget. Det färdiga innehållet (identifieringar, jaktfrågor, arbetsböcker, parsare osv.) har uppdaterats av Microsoft Sentinel.

Så här använder du den här artikeln

När information i den här artikeln endast är relevant för Syslog eller endast för CEF-anslutningsappar visas den på separata flikar. Kontrollera att du använder anvisningarna på rätt flik för anslutningstypen.

Om du till exempel felsöker en CEF-anslutning börjar du med Verifiera CEF-anslutning. Om du felsöker en Syslog-anslutningsapp börjar du med Verifiera dina krav för dataanslutningsappen.

Verifiera CEF-anslutning

När du har distribuerat loggvidare och konfigurerat din säkerhetslösning för att skicka CEF-meddelanden till den använder du stegen i det här avsnittet för att verifiera anslutningen mellan din säkerhetslösning och Microsoft Sentinel.

Den här proceduren är endast relevant för CEF-anslutningar och är inte relevant för Syslog-anslutningar.

  1. Kontrollera att du har följande förutsättningar:

    • Du måste ha utökade behörigheter (sudo) på loggvidaredatorn.

    • Python 2.7 eller 3 måste vara installerat på loggvidaredatorn. python --version Använd kommandot för att kontrollera.

    • Du kan behöva arbetsyte-ID och primärnyckel för arbetsyta någon gång i den här processen. Du hittar dem i arbetsyteresursen under Agenthantering.

  2. Öppna Loggar från Microsoft Sentinel-navigeringsmenyn. Kör en fråga med hjälp av CommonSecurityLog-schemat för att se om du tar emot loggar från din säkerhetslösning.

    Det kan ta cirka 20 minuter innan loggarna börjar visas i Log Analytics.

  3. Om du inte ser några resultat från frågan kontrollerar du att din säkerhetslösning genererar loggmeddelanden. Eller prova att vidta några åtgärder för att generera loggmeddelanden och kontrollera att meddelandena vidarebefordras till den avsedda Syslog-vidarebefordraren.

  4. Om du vill kontrollera anslutningen mellan din säkerhetslösning, loggvidare och Microsoft Sentinel kör du följande skript på loggvidare (tillämpa arbetsytans ID i stället för platshållaren). Det här skriptet kontrollerar att daemon lyssnar på rätt portar, att vidarebefordran är korrekt konfigurerad och att ingenting blockerar kommunikationen mellan daemonen och Log Analytics-agenten. Den skickar också falska meddelanden "TestCommonEventFormat" för att kontrollera anslutningen från slutpunkt till slutpunkt.

    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]
    
    • Du kan få ett meddelande som instruerar dig att köra ett kommando för att åtgärda ett problem med mappningen av fältet Dator. Mer information finns i förklaringen i valideringsskriptet .

    • Du kan få ett meddelande som instruerar dig att köra ett kommando för att åtgärda ett problem med parsningen av Cisco ASA-brandväggsloggar. Mer information finns i förklaringen i valideringsskriptet .

Beskrivning av CEF-valideringsskript

I följande avsnitt beskrivs CEF-valideringsskriptet för daemonen rsyslog och daemonen syslog-ng.

rsyslog daemon

För en rsyslog-daemon kör CEF-valideringsskriptet följande kontroller:

  1. Kontrollerar att filen
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    finns och är giltig.

  2. Kontrollerar att filen innehåller följande text:

    <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. Kontrollerar att parsningen för Cisco ASA Firewall-händelser har konfigurerats som förväntat med hjälp av följande kommando:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb
    
    • Om det finns ett problem med parsningen skapar skriptet ett felmeddelande som instruerar dig att manuellt köra följande kommando (tillämpa arbetsyte-ID:t i stället för platshållaren). Kommandot säkerställer korrekt parsning och startar om agenten.

      # 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. Kontrollerar att fältet Dator i syslog-källan är korrekt mappat i Log Analytics-agenten med hjälp av följande kommando:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb
    
    • Om det finns ett problem med mappningen skapar skriptet ett felmeddelande som instruerar dig att manuellt köra följande kommando (tillämpa arbetsyte-ID:t i stället för platshållaren). Kommandot säkerställer rätt mappning och startar om agenten.

      # 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. Kontrollerar om det finns några säkerhetsförbättringar på datorn som kan blockera nätverkstrafik (till exempel en värdbrandvägg).

  6. Kontrollerar att syslog-daemon (rsyslog) är korrekt konfigurerad för att skicka meddelanden (som identifieras som CEF) till Log Analytics-agenten på TCP-port 25226:

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

    if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226
    
  7. Startar om syslog-daemonen och Log Analytics-agenten:

    service rsyslog restart
    
    /opt/microsoft/omsagent/bin/service_control restart [workspaceID]
    
  8. Kontrollerar att nödvändiga anslutningar har upprättats: tcp 514 för att ta emot data, tcp 25226 för intern kommunikation mellan syslog-daemon och Log Analytics-agenten:

    netstat -an | grep 514
    
    netstat -an | grep 25226
    
  9. Kontrollerar att syslog-daemon tar emot data på port 514 och att agenten tar emot data på port 25226:

    sudo tcpdump -A -ni any port 514 -vv
    
    sudo tcpdump -A -ni any port 25226 -vv
    
  10. Skickar MOCK-data till port 514 på localhost. Dessa data bör kunna observeras på Microsoft Sentinel-arbetsytan genom att köra följande fråga:

    CommonSecurityLog
    | where DeviceProduct == "MOCK"
    

syslog-ng daemon

För en syslog-ng-daemon kör CEF-valideringsskriptet följande kontroller:

  1. Kontrollerar att filen
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    finns och är giltig.

  2. Kontrollerar att filen innehåller följande text:

    <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. Kontrollerar att parsningen för Cisco ASA Firewall-händelser har konfigurerats som förväntat med hjälp av följande kommando:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb
    
    • Om det finns ett problem med parsningen skapar skriptet ett felmeddelande som instruerar dig att manuellt köra följande kommando (tillämpa arbetsyte-ID:t i stället för platshållaren). Kommandot säkerställer korrekt parsning och startar om agenten.

      # 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. Kontrollerar att fältet Dator i syslog-källan är korrekt mappat i Log Analytics-agenten med hjälp av följande kommando:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb
    
    • Om det finns ett problem med mappningen skapar skriptet ett felmeddelande som instruerar dig att manuellt köra följande kommando (tillämpa arbetsyte-ID:t i stället för platshållaren). Kommandot säkerställer rätt mappning och startar om agenten.

      # 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. Kontrollerar om det finns några säkerhetsförbättringar på datorn som kan blockera nätverkstrafik (till exempel en värdbrandvägg).

  6. Kontrollerar att syslog-daemon (syslog-ng) är korrekt konfigurerad för att skicka meddelanden som identifieras som CEF (med en regex) till Log Analytics-agenten på TCP-port 25226:

    • Konfigurationsfil: /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. Startar om syslog-daemonen och Log Analytics-agenten:

    service syslog-ng restart
    
    /opt/microsoft/omsagent/bin/service_control restart [workspaceID]
    
  8. Kontrollerar att nödvändiga anslutningar har upprättats: tcp 514 för att ta emot data, tcp 25226 för intern kommunikation mellan syslog-daemon och Log Analytics-agenten:

    netstat -an | grep 514
    
    netstat -an | grep 25226
    
  9. Kontrollerar att syslog-daemon tar emot data på port 514 och att agenten tar emot data på port 25226:

    sudo tcpdump -A -ni any port 514 -vv
    
    sudo tcpdump -A -ni any port 25226 -vv
    
  10. Skickar MOCK-data till port 514 på localhost. Dessa data bör kunna observeras på Microsoft Sentinel-arbetsytan genom att köra följande fråga:

    CommonSecurityLog
    | where DeviceProduct == "MOCK"
    

Verifiera kraven för dataanslutningsappen

Använd följande avsnitt för att kontrollera kraven för din CEF- eller Syslog-dataanslutning.

Azure Virtual Machine som CEF-insamlare

Om du använder en virtuell Azure-dator som CEF-insamlare kontrollerar du följande:

  • Innan du distribuerar Python-skriptet common event format data connector kontrollerar du att den virtuella datorn inte redan är ansluten till en befintlig Log Analytics-arbetsyta. Du hittar den här informationen i listan Log Analytics Workspace Virtual Machine, där en virtuell dator som är ansluten till en Syslog-arbetsyta visas som Ansluten.

  • Kontrollera att Microsoft Sentinel är anslutet till rätt Log Analytics-arbetsyta med SecurityInsights-lösningen installerad.

    Mer information finns i Steg 1: Distribuera loggvidare.

  • Kontrollera att datorn har rätt storlek med minst de minimikrav som krävs. Mer information finns i KRAV för CEF.

Lokalt eller en virtuell dator som inte är en Azure-dator

Om du använder en lokal dator eller en virtuell dator som inte är en Azure-dator för dataanslutningen kontrollerar du att du har kört installationsskriptet på en ny installation av ett Linux-operativsystem som stöds:

Dricks

Du hittar även det här skriptet från sidan common event format data connector i 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>

Aktivera din CEF-anläggning och loggens allvarlighetsgradssamling

Syslog-servern, antingen rsyslog eller syslog-ng, vidarebefordrar alla data som definierats i den relevanta konfigurationsfilen, som fylls i automatiskt av de inställningar som definierats i Log Analytics-arbetsytan.

Se till att lägga till information om de anläggningar och allvarlighetsgradsloggnivåer som du vill mata in i Microsoft Sentinel. Konfigurationsprocessen kan ta cirka 20 minuter.

Mer information finns i Förklaring av distributionsskript.

För en rsyslog-server kör du till exempel följande kommando för att visa de aktuella inställningarna för syslog-vidarebefordran och granska eventuella ändringar i konfigurationsfilen:

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

I det här fallet bör utdata som liknar följande visas för rsyslog:

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

Felsöka problem med operativsystemet

I det här avsnittet beskrivs hur du felsöker problem som verkligen härleds från operativsystemets konfiguration.

Så här felsöker du operativsystemproblem:

  1. Om du inte har gjort det ännu kontrollerar du att du arbetar med ett operativsystem som stöds och Python-versionen. Mer information finns i KRAV för CEF.

  2. Om den virtuella datorn finns i Azure kontrollerar du att nätverkssäkerhetsgruppen (NSG) tillåter inkommande TCP/UDP-anslutning från loggklienten (avsändaren) på port 514.

  3. Kontrollera att paketen kommer till Syslog-insamlaren. Om du vill samla in syslog-paketen som kommer till Syslog-insamlaren kör du:

    tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv
    
  4. Gör något av följande:

    • Om du inte ser några paket som kommer bekräftar du NSG-säkerhetsgruppens behörigheter och routningssökvägen till Syslog Collector.

    • Om du ser paket som kommer bekräftar du att de inte avvisas.

    Om du ser avvisade paket kontrollerar du att IP-tabellerna inte blockerar anslutningarna.

    Kontrollera att paketen inte avvisas genom att köra:

    watch -n 2 -d iptables -nvL
    
  5. Kontrollera om CEF-servern bearbetar loggarna. Kör:

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

    Alla CEF-loggar som bearbetas visas i oformaterad text.

  6. Bekräfta att rsyslog-servern lyssnar på TCP/UDP-port 514. Kör:

    netstat -anp | grep syslog
    

    Om du har cef- eller ASA-loggar som skickas till sysloginsamlaren bör du se en upprättad anslutning på TCP-port 25226.

    Till exempel:

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd
    

    Om anslutningen blockeras kan du ha en blockerad SELinux-anslutning till OMS-agenten eller en blockerad brandväggsprocess. Använd de relevanta anvisningarna ytterligare för att fastställa problemet.

SELinux blockerar anslutningen till OMS-agenten

Den här proceduren beskriver hur du bekräftar om SELinux för närvarande är i ett permissive tillstånd eller blockerar en anslutning till OMS-agenten. Den här proceduren är relevant när operativsystemet är en distribution från RedHat eller CentOS och för både CEF- och Syslog-dataanslutningar.

Kommentar

Microsoft Sentinel-stöd för CEF och Syslog innehåller endast FIPS-härdning. Andra härdningsmetoder, till exempel SELinux eller CIS, stöds inte för närvarande.

  1. Kör:

    sestatus
    

    Statusen visas som något av följande:

    • disabled. Den här konfigurationen stöds för din anslutning till Microsoft Sentinel.
    • permissive. Den här konfigurationen stöds för din anslutning till Microsoft Sentinel.
    • enforced. Den här konfigurationen stöds inte och du måste antingen inaktivera statusen eller ange den till permissive.
  2. Om statusen för närvarande är inställd enforcedpå inaktiverar du den tillfälligt för att bekräfta om detta var blockeraren. Kör:

    setenforce 0
    

    Kommentar

    Det här steget inaktiverar endast SELinux tills servern startas om. Ändra SELinux-konfigurationen så att den är inaktiverad.

  3. Kontrollera om ändringen lyckades genom att köra:

    getenforce
    

    Tillståndet permissive ska returneras.

Viktigt!

Den här inställningsuppdateringen går förlorad när systemet startas om. Om du vill uppdatera den här inställningen permanent till ändrar du filen /etc/selinux/config genom att ändra SELINUX värdet till SELINUX=permissive.permissive

Mer information finns i RedHat-dokumentationen.

Blockerad brandväggsprincip

Den här proceduren beskriver hur du kontrollerar om en brandväggsprincip blockerar anslutningen från Rsyslog-daemonen till OMS-agenten och hur du inaktiverar den efter behov. Den här proceduren är relevant för både CEF- och Syslog-dataanslutningar.

  1. Kör följande kommando för att kontrollera om det finns några avslag i IP-tabellerna, vilket anger trafik som tas bort av brandväggsprincipen:

    watch -n 2 -d iptables -nvL
    
  2. Om du vill aktivera brandväggsprincipen skapar du en principregel som tillåter anslutningarna. Lägg till regler efter behov för att tillåta TCP/UDP-portarna 25226 och 25224 via den aktiva brandväggen.

    Till exempel:

    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. Om du vill skapa en regel för att tillåta TCP/UDP-portarna 25226 och 25224 via den aktiva brandväggen lägger du till regler efter behov.

    1. Om du vill installera redigeraren brandväggsprincip kör du:

      yum install policycoreutils-python
      
    2. Lägg till brandväggsreglerna i brandväggsprincipen. Till exempel:

      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. Kontrollera att undantaget har lagts till. Kör:

      sudo firewall-cmd --direct --get-rules ipv4 filter INPUT
      
    4. Ladda om brandväggen. Kör:

      sudo firewall-cmd --reload
      

Kommentar

Om du vill inaktivera brandväggen kör du: sudo systemctl disable firewalld

Om stegen som beskrivs tidigare i den här artikeln inte löser problemet kan du ha ett anslutningsproblem mellan OMS-agenten och Microsoft Sentinel-arbetsytan.

I sådana fall fortsätter du att felsöka genom att verifiera följande:

  • Kontrollera att du kan se paket som anländer till TCP/UDP-port 514 på Syslog-insamlaren

  • Kontrollera att du kan se loggar som skrivs till den lokala loggfilen, antingen /var/log/messages eller /var/log/syslog

  • Kontrollera att du kan se datapaket som flödar på port 25226

  • Kontrollera att den virtuella datorn har en utgående anslutning till port 443 via TCP eller kan ansluta till Log Analytics-slutpunkterna

  • Kontrollera att du har åtkomst till nödvändiga URL:er från din CEF-insamlare via brandväggsprincipen. Mer information finns i Brandväggskrav för Log Analytics-agenten.

Kör följande kommando för att avgöra om agenten kommunicerar med Azure eller om OMS-agenten blockeras från att ansluta till Log Analytics-arbetsytan.

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

En loggpost returneras om agenten kommunicerar korrekt. Annars kan OMS-agenten blockeras.