Udostępnij za pośrednictwem

[Przestarzałe] Rozwiązywanie problemów z łącznikiem danych CEF lub Syslog

  • Artykuł

Ważne

Zbieranie dzienników z wielu urządzeń i urządzeń jest teraz obsługiwane przez format Common Event Format (CEF) za pośrednictwem amA, dziennika systemowego za pośrednictwem usługi AMA lub dzienników niestandardowych za pośrednictwem łącznika danych AMA w usłudze Microsoft Sentinel. Aby uzyskać więcej informacji, zobacz Znajdowanie łącznika danych usługi Microsoft Sentinel.

Uwaga

W tym artykule odwołuje się do systemu CentOS — dystrybucji systemu Linux, która osiągnęła stan Zakończenia życia (EOL). Rozważ odpowiednie użycie i planowanie. Aby uzyskać więcej informacji, zobacz wskazówki dotyczące zakończenia życia systemu CentOS.

W tym artykule opisano typowe metody weryfikowania i rozwiązywania problemów z łącznikiem danych CEF lub Syslog dla usługi Microsoft Sentinel.

Jeśli na przykład komunikaty dziennika nie są wyświetlane w tabelach Syslog lub CommonSecurityLog , źródło danych może nie być poprawnie połączone. Może być również inny powód, dla którego dane nie są odbierane.

Inne objawy nieudanego wdrożenia łącznika obejmują, gdy brakuje plików security_events.conf lub security-omsagent.config.conf lub jeśli serwer rsyslog nie nasłuchuje na porcie 514.

Aby uzyskać więcej informacji, zobacz Connect your external solution using Common Event Format and Collect data from Linux-based sources using Syslog (Łączenie rozwiązania zewnętrznego przy użyciu formatu Common Event Format) i Collect data from Linux-based sources using Syslog (Łączenie rozwiązania zewnętrznego przy użyciu formatu Common Event Format ) i Collect data from Linux-based sources using Syslog (Zbieranie danych ze źródeł oparty

Jeśli łącznik został wdrożony przy użyciu innej metody niż udokumentowana procedura, a jeśli masz problemy, zalecamy usunięcie wdrożenia i rozpoczęcie od nowa, tym razem zgodnie z udokumentowanymi instrukcjami.

W tym artykule pokazano, jak rozwiązywać problemy z łącznikami CEF lub Syslog za pomocą agenta usługi Log Analytics. Aby uzyskać informacje dotyczące rozwiązywania problemów związanych z pozyskiwaniem dzienników CEF za pośrednictwem agenta usługi Azure Monitor (AMA), zapoznaj się z instrukcjami dotyczącymi formatu Common Event Format (CEF) za pośrednictwem łącznika usługi AMA .

Ważne

28 lutego 2023 r. wprowadziliśmy zmiany w schemacie tabeli CommonSecurityLog. Po tej zmianie może być konieczne przejrzenie i zaktualizowanie zapytań niestandardowych. Aby uzyskać więcej informacji, zobacz sekcję zalecanych akcji w tym wpisie w blogu. Zawartość out-of-the-box (wykrycia, zapytania wyszukiwania zagrożeń, skoroszyty, analizatory itp.) została zaktualizowana przez usługę Microsoft Sentinel.

Jak używać tego artykułu

Jeśli informacje w tym artykule są istotne tylko dla dziennika systemowego lub tylko dla łączników CEF, są prezentowane na oddzielnych kartach. Upewnij się, że używasz instrukcji na właściwej karcie dla typu łącznika.

Jeśli na przykład rozwiązujesz problemy z łącznikiem CEF, zacznij od zweryfikuj łączność CEF. Jeśli rozwiązujesz problemy z łącznikiem usługi Syslog, zacznij od sekcji Weryfikowanie wymagań wstępnych łącznika danych.

Weryfikowanie łączności CEF

Po wdrożeniu usługi przesyłania dalej dzienników i skonfigurowaniu rozwiązania zabezpieczeń w celu wysyłania komunikatów CEF wykonaj kroki opisane w tej sekcji, aby zweryfikować łączność między rozwiązaniem zabezpieczeń a usługą Microsoft Sentinel.

Ta procedura jest odpowiednia tylko w przypadku połączeń CEF i nie jest odpowiednia dla połączeń dziennika systemowego.

  1. Upewnij się, że masz następujące wymagania wstępne:

    • Musisz mieć uprawnienia z podwyższonym poziomem uprawnień (sudo) na maszynie usługi przesyłania dalej dziennika.

    • Na maszynie usługi przesyłania dalej dzienników musi być zainstalowany język Python 2.7 lub 3 . python --version Użyj polecenia , aby sprawdzić.

    • W pewnym momencie tego procesu może być potrzebny identyfikator obszaru roboczego i klucz podstawowy obszaru roboczego. Można je znaleźć w zasobie obszaru roboczego w obszarze Zarządzanie agentami.

  2. W menu nawigacji usługi Microsoft Sentinel otwórz pozycję Dzienniki. Uruchom zapytanie przy użyciu schematu CommonSecurityLog , aby sprawdzić, czy otrzymujesz dzienniki z rozwiązania zabezpieczeń.

    Wyświetlenie dzienników w usłudze Log Analytics może potrwać około 20 minut.

  3. Jeśli nie widzisz żadnych wyników zapytania, sprawdź, czy rozwiązanie zabezpieczeń generuje komunikaty dziennika. Możesz też spróbować wykonać kilka akcji w celu wygenerowania komunikatów dziennika i sprawdzić, czy komunikaty są przekazywane do wyznaczonego komputera usługi przesyłania dalej syslog.

  4. Aby sprawdzić łączność między rozwiązaniem zabezpieczeń, usługą przesyłania dalej dzienników i usługą Microsoft Sentinel, uruchom następujący skrypt w usłudze przesyłania dalej dziennika (stosując identyfikator obszaru roboczego zamiast symbolu zastępczego). Ten skrypt sprawdza, czy demon nasłuchuje na odpowiednich portach, że przekazywanie jest prawidłowo skonfigurowane i że nic nie blokuje komunikacji między demonem a agentem usługi Log Analytics. Wysyła również pozorne komunikaty "TestCommonEventFormat", aby sprawdzić łączność kompleksową. 

    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]

Objaśniono skrypt weryfikacji cef

W poniższej sekcji opisano skrypt weryfikacji CEF dla demona rsyslog i demona syslog-ng.

demon rsyslog

W przypadku demona rsyslog skrypt weryfikacji CEF uruchamia następujące testy:

  1. Sprawdza, czy plik
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    istnieje i jest prawidłowy.

  2. Sprawdza, czy plik zawiera następujący tekst:

    <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. Sprawdza, czy analizowanie zdarzeń zapory Cisco ASA jest skonfigurowane zgodnie z oczekiwaniami, używając następującego polecenia:

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

    • Jeśli wystąpi problem z analizowaniem, skrypt generuje komunikat o błędzie kierujący Cię do ręcznego uruchomienia następującego polecenia (zastosowanie identyfikatora obszaru roboczego zamiast symbolu zastępczego). Polecenie zapewnia poprawne analizowanie i ponowne uruchamianie agenta.

      # 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. Sprawdza, czy pole Komputer w źródle dziennika systemowego jest prawidłowo mapowane w agencie usługi Log Analytics, używając następującego polecenia:

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

    • Jeśli występuje problem z mapowaniem, skrypt generuje komunikat o błędzie kierujący Cię do ręcznego uruchomienia następującego polecenia (zastosowanie identyfikatora obszaru roboczego zamiast symbolu zastępczego). Polecenie zapewnia poprawne mapowanie i ponownie uruchamia agenta.

      # 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. Sprawdza, czy na maszynie istnieją jakiekolwiek ulepszenia zabezpieczeń, które mogą blokować ruch sieciowy (np. zaporę hosta).

  6. Sprawdza, czy demon dziennika systemowego (rsyslog) jest prawidłowo skonfigurowany do wysyłania komunikatów (zidentyfikowanych jako CEF) do agenta usługi Log Analytics na porcie TCP 25226:

    Plik konfiguracji: /etc/rsyslog.d/security-config-omsagent.conf

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

  7. Uruchamia ponownie demona dziennika systemowego i agenta usługi Log Analytics:

    service rsyslog restart

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

  8. Sprawdza, czy nawiązano niezbędne połączenia: tcp 514 do odbierania danych, tcp 25226 na potrzeby komunikacji wewnętrznej między demonem dziennika systemowego a agentem usługi Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Sprawdza, czy demon dziennika systemowego odbiera dane na porcie 514 i czy agent odbiera dane na porcie 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Wysyła dane MOCK do portu 514 na hoście lokalnym. Te dane powinny być widoczne w obszarze roboczym usługi Microsoft Sentinel, uruchamiając następujące zapytanie:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

demon syslog-ng

W przypadku demona syslog-ng skrypt weryfikacji CEF uruchamia następujące testy:

  1. Sprawdza, czy plik
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    istnieje i jest prawidłowy.

  2. Sprawdza, czy plik zawiera następujący tekst:

    <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. Sprawdza, czy analizowanie zdarzeń zapory Cisco ASA jest skonfigurowane zgodnie z oczekiwaniami, używając następującego polecenia:

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

    • Jeśli wystąpi problem z analizowaniem, skrypt generuje komunikat o błędzie kierujący Cię do ręcznego uruchomienia następującego polecenia (zastosowanie identyfikatora obszaru roboczego zamiast symbolu zastępczego). Polecenie zapewnia poprawne analizowanie i ponowne uruchamianie agenta.

      # 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. Sprawdza, czy pole Komputer w źródle dziennika systemowego jest prawidłowo mapowane w agencie usługi Log Analytics, używając następującego polecenia:

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

    • Jeśli występuje problem z mapowaniem, skrypt generuje komunikat o błędzie kierujący Cię do ręcznego uruchomienia następującego polecenia (zastosowanie identyfikatora obszaru roboczego zamiast symbolu zastępczego). Polecenie zapewnia poprawne mapowanie i ponownie uruchamia agenta.

      # 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. Sprawdza, czy na maszynie istnieją jakiekolwiek ulepszenia zabezpieczeń, które mogą blokować ruch sieciowy (np. zaporę hosta).

  6. Sprawdza, czy demon dziennika systemowego (syslog-ng) jest prawidłowo skonfigurowany do wysyłania komunikatów, które identyfikuje jako CEF (przy użyciu wyrażenia regularnego) do agenta usługi Log Analytics na porcie TCP 25226:

    • Plik konfiguracji: /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. Uruchamia ponownie demona dziennika systemowego i agenta usługi Log Analytics:

    service syslog-ng restart

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

  8. Sprawdza, czy nawiązano niezbędne połączenia: tcp 514 do odbierania danych, tcp 25226 na potrzeby komunikacji wewnętrznej między demonem dziennika systemowego a agentem usługi Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Sprawdza, czy demon dziennika systemowego odbiera dane na porcie 514 i czy agent odbiera dane na porcie 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Wysyła dane MOCK do portu 514 na hoście lokalnym. Te dane powinny być widoczne w obszarze roboczym usługi Microsoft Sentinel, uruchamiając następujące zapytanie:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

Weryfikowanie wymagań wstępnych łącznika danych

Skorzystaj z poniższych sekcji, aby sprawdzić wymagania wstępne dotyczące łącznika danych CEF lub Syslog.

Maszyna wirtualna platformy Azure jako moduł zbierający CEF

Jeśli używasz maszyny wirtualnej platformy Azure jako modułu zbierającego CEF, sprawdź następujące kwestie:

  • Przed wdrożeniem skryptu języka Python łącznika common Event Format Data Connector upewnij się, że maszyna wirtualna nie jest jeszcze połączona z istniejącym obszarem roboczym usługi Log Analytics. Te informacje można znaleźć na liście Maszyny wirtualnej obszaru roboczego usługi Log Analytics, gdzie maszyna wirtualna połączona z obszarem roboczym dziennika systemu jest wyświetlana jako Połączono.

  • Upewnij się, że usługa Microsoft Sentinel jest połączona z poprawnym obszarem roboczym usługi Log Analytics z zainstalowanym rozwiązaniem SecurityInsights .

    Aby uzyskać więcej informacji, zobacz Krok 1. Wdrażanie usługi przesyłania dalej dziennika.

  • Upewnij się, że rozmiar maszyny jest prawidłowy z co najmniej minimalnymi wymaganymi wymaganiami wstępnymi. Aby uzyskać więcej informacji, zobacz Wymagania wstępne dotyczące formatu CEF.

Lokalna lub nienależące do platformy Azure maszyna wirtualna

Jeśli używasz maszyny lokalnej lub maszyny wirtualnej spoza platformy Azure dla łącznika danych, upewnij się, że skrypt instalacyjny został uruchomiony w nowej instalacji obsługiwanego systemu operacyjnego Linux:

Napiwek

Ten skrypt można również znaleźć na stronie łącznika danych Common Event Format w usłudze 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>

Włączanie infrastruktury CEF i zbierania ważności dziennika

Serwer syslog, rsyslog lub syslog-ng, przekazuje wszystkie dane zdefiniowane w odpowiednim pliku konfiguracji, który jest automatycznie wypełniany przez ustawienia zdefiniowane w obszarze roboczym usługi Log Analytics.

Pamiętaj, aby dodać szczegółowe informacje na temat poziomów dzienników obiektów i ważności, które mają być pozyskiwane do usługi Microsoft Sentinel. Proces konfiguracji może potrwać około 20 minut.

Aby uzyskać więcej informacji, zobacz Wyjaśnienie skryptu wdrażania.

Na przykład w przypadku serwera rsyslog uruchom następujące polecenie, aby wyświetlić bieżące ustawienia przesyłania dalej usługi Syslog i przejrzyj wszelkie zmiany w pliku konfiguracji:

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

W takim przypadku dla polecenia rsyslog powinny być wyświetlane dane wyjściowe podobne do następujących:

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

Rozwiązywanie problemów z systemem operacyjnym

W tej sekcji opisano sposób rozwiązywania problemów, które z pewnością pochodzą z konfiguracji systemu operacyjnego.

Aby rozwiązać problemy z systemem operacyjnym:

  1. Jeśli jeszcze tego nie zrobiliśmy, sprawdź, czy pracujesz z obsługiwanym systemem operacyjnym i wersją języka Python. Aby uzyskać więcej informacji, zobacz Wymagania wstępne dotyczące formatu CEF.

  2. Jeśli maszyna wirtualna znajduje się na platformie Azure, sprawdź, czy sieciowa grupa zabezpieczeń zezwala na przychodzące połączenie TCP/UDP z klienta dziennika (Nadawca) na porcie 514.

  3. Sprawdź, czy pakiety docierają do modułu zbierającego dziennik systemu. Aby przechwycić pakiety dziennika systemowego odbierane do modułu zbierającego dziennik systemu, uruchom polecenie:

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

  4. Wykonaj jedną z następujących czynności:

    • Jeśli nie widzisz żadnych przychodzących pakietów, potwierdź uprawnienia grupy zabezpieczeń sieciowej grupy zabezpieczeń i ścieżkę routingu do modułu zbierającego dziennik systemowy.

    • Jeśli widzisz przychodzące pakiety, upewnij się, że nie są one odrzucane.

    Jeśli widzisz odrzucone pakiety, upewnij się, że tabele IP nie blokują połączeń.

    Aby potwierdzić, że pakiety nie są odrzucane, uruchom polecenie:

    watch -n 2 -d iptables -nvL

  5. Sprawdź, czy serwer CEF przetwarza dzienniki. Uruchom:

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

    Wszystkie przetwarzane dzienniki CEF są wyświetlane w postaci zwykłego tekstu.

  6. Upewnij się, że serwer rsyslog nasłuchuje na porcie TCP/UDP 514. Uruchom:

    netstat -anp | grep syslog

    Jeśli masz jakiekolwiek dzienniki CEF lub ASA wysyłane do modułu zbierającego dzienniki systemu, powinno zostać wyświetlone nawiązane połączenie na porcie TCP 25226.

    Na przykład:

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    Jeśli połączenie jest zablokowane, być może masz zablokowane połączenie SELinux z agentem pakietu OMS lub zablokowany proces zapory. Aby ustalić problem, skorzystaj z odpowiednich instrukcji.

SeLinux blokujące połączenie z agentem pakietu OMS

W tej procedurze opisano sposób potwierdzania, czy narzędzie SELinux jest obecnie w permissive stanie, czy blokuje połączenie z agentem pakietu OMS. Ta procedura jest istotna, gdy system operacyjny jest dystrybucją z systemu RedHat lub CentOS oraz łącznikami danych CEF i Syslog.

Uwaga

Obsługa formatu CEF i dziennika systemowego w usłudze Microsoft Sentinel obejmuje tylko wzmacnianie zabezpieczeń ze standardem FIPS. Inne metody wzmacniania zabezpieczeń, takie jak SELinux lub CIS, nie są obecnie obsługiwane.

  1. Uruchom:

    sestatus

    Stan jest wyświetlany jako jeden z następujących:

    • disabled. Ta konfiguracja jest obsługiwana w przypadku połączenia z usługą Microsoft Sentinel.
    • permissive. Ta konfiguracja jest obsługiwana w przypadku połączenia z usługą Microsoft Sentinel.
    • enforced. Ta konfiguracja nie jest obsługiwana i należy ją wyłączyć lub ustawić na permissive.

  2. Jeśli stan jest obecnie ustawiony na enforced, wyłącz go tymczasowo, aby potwierdzić, czy był to bloker. Uruchom:

    setenforce 0

    Uwaga

    Ten krok wyłącza funkcję SELinux tylko do momentu ponownego uruchomienia serwera. Zmodyfikuj konfigurację SELinux, aby zachować ją wyłączoną.

  3. Aby sprawdzić, czy zmiana zakończyła się pomyślnie, uruchom polecenie:

    getenforce

    Stan permissive powinien zostać zwrócony.

Ważne

Ta aktualizacja ustawienia zostanie utracona po ponownym uruchomieniu systemu. Aby trwale zaktualizować to ustawienie na permissive, zmodyfikuj plik /etc/selinux/config , zmieniając SELINUX wartość na SELINUX=permissive.

Aby uzyskać więcej informacji, zobacz dokumentację oprogramowania RedHat.

Zablokowane zasady zapory

W tej procedurze opisano sposób sprawdzania, czy zasady zapory blokują połączenie z demona Rsyslog do agenta pakietu OMS oraz jak wyłączyć je zgodnie z potrzebami. Ta procedura jest odpowiednia zarówno dla łączników danych CEF, jak i Syslog.

  1. Uruchom następujące polecenie, aby sprawdzić, czy w tabelach IP istnieją jakiekolwiek odrzucenia, wskazując ruch, który jest porzucony przez zasady zapory:

    watch -n 2 -d iptables -nvL

  2. Aby zachować włączone zasady zapory, utwórz regułę zasad zezwalaną na połączenia. Dodaj reguły zgodnie z potrzebami, aby zezwolić na porty TCP/UDP 25226 i 25224 za pośrednictwem aktywnej zapory.

    Na przykład:

    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. Aby utworzyć regułę zezwalania na porty TCP/UDP 25226 i 25224 za pośrednictwem aktywnej zapory, dodaj reguły zgodnie z potrzebami.

    1. Aby zainstalować edytor zasad zapory, uruchom polecenie:

      yum install policycoreutils-python

    2. Dodaj reguły zapory do zasad zapory. Na przykład:

      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. Sprawdź, czy wyjątek został dodany. Uruchom:

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

    4. Załaduj ponownie zaporę. Uruchom:

      sudo firewall-cmd --reload

Uwaga

Aby wyłączyć zaporę, uruchom polecenie: sudo systemctl disable firewalld

Jeśli kroki opisane wcześniej w tym artykule nie rozwiążą problemu, może wystąpić problem z łącznością między agentem pakietu OMS a obszarem roboczym usługi Microsoft Sentinel.

W takich przypadkach kontynuuj rozwiązywanie problemów, sprawdzając następujące kwestie:

  • Upewnij się, że pakiety przychodzące na porcie TCP/UDP 514 są widoczne w module zbierającym dziennik systemowy

  • Upewnij się, że dzienniki są zapisywane w lokalnym pliku dziennika: /var/log/messages lub /var/log/syslog

  • Upewnij się, że pakiety danych przepływają na porcie 25226

  • Upewnij się, że maszyna wirtualna ma połączenie wychodzące z portem 443 za pośrednictwem protokołu TCP lub może nawiązać połączenie z punktami końcowymi usługi Log Analytics

  • Upewnij się, że masz dostęp do wymaganych adresów URL z modułu zbierającego CEF za pośrednictwem zasad zapory. Aby uzyskać więcej informacji, zobacz Wymagania zapory agenta usługi Log Analytics.

Uruchom następujące polecenie, aby określić, czy agent komunikuje się pomyślnie z platformą Azure, czy agent pakietu OMS nie może nawiązać połączenia z obszarem roboczym usługi Log Analytics.

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

Jeśli agent pomyślnie komunikuje się, zostanie zwrócony wpis dziennika. W przeciwnym razie agent pakietu OMS może zostać zablokowany.