Rozwiązywanie problemów z CEF i Syslog przy użyciu łączników AMA

Ten artykuł zawiera wskazówki dotyczące rozwiązywania problemów dotyczących zbierania danych w formacie Common Event Format (CEF) i Syslog przy użyciu agenta Azure Monitor (AMA) w Microsoft Sentinel. Skorzystaj z tego przewodnika, aby diagnozować i rozwiązywać problemy z pozyskiwaniem danych na maszynach przekazujących logi. Polecenia i konfiguracje powinny być uruchamiane na maszynach usługi przesyłania dalej dzienników, na których są zainstalowane rozwiązania AMA i RSyslog/Syslog-ng.

Przed rozpoczęciem rozwiązywania problemów zapoznaj się z następującymi artykułami:

• Pozyskiwanie komunikatów syslog i CEF w usłudze Microsoft Sentinel przy użyciu agenta Azure Monitor
• CEF za pomocą łącznika danych AMA — konfigurowanie określonego urządzenia lub sprzętu
• Omówienie agenta Azure Monitor

Omówienie architektury

Na poniższym diagramie przedstawiono przepływ danych ze źródeł dzienników do obszarów roboczych Microsoft Sentinel/log analytics za pośrednictwem usługi RSyslog i agenta Azure Monitor.

Kluczowe składniki:

• RSyslog/Syslog-ng: odbiera logi na porcie 514 i przekazuje je do AMA
• Azure Monitor Agent: przetwarza dzienniki zgodnie z regułami zbierania danych (DCR)
• Reguła zbierania danych: określa, które dzienniki mają być zbierane i gdzie je wysyłać

Początkowe kroki weryfikacji

Sprawdź, czy logi są odbierane

Wyświetlenie dzienników w Microsoft Sentinel po konfiguracji może potrwać do 20 minut.

1. Uruchom polecenie tcpdump, aby sprawdzić, czy dzienniki docierają do serwera przekazującego:

   sudo tcpdump -i any port 514 -A -vv
   

2. Sprawdź, czy źródło dziennika jest skonfigurowane do wysyłania komunikatów na prawidłowy adres IP usługi przesyłania dalej.

3. Sprawdź składniki infrastruktury, które mogą mieć wpływ na łączność:

   • Zapory
   • Moduły równoważenia obciążenia
   • Sieciowe grupy zabezpieczeń

Sprawdzanie stanu rozszerzenia agenta Azure Monitor

1. W portalu Azure przejdź do maszyny wirtualnej usługi przesyłania dzienników.
2. Wybierz pozycję Rozszerzenia i aplikacje.
3. Wybierz rozszerzenie AzureMonitorLinuxAgent .
4. Sprawdź, czy stan pokazuje, że aprowizowanie zakończyło się pomyślnie.

Zweryfikuj wersję agenta

1. W bloku rozszerzenia AzureMonitorLinuxAgent sprawdź pole Wersja .
2. Upewnij się, że jest to jedno z 2–3 najnowszych wydań. Zobacz szczegóły wersji AMA, aby sprawdzić najnowsze wersje.

Rozwiązywanie problemów na poziomie agenta

Upewnij się, że agent i usługi RSyslog są uruchomione.

sudo systemctl status azuremonitoragent
sudo systemctl status rsyslog
sudo systemctl status syslog-ng.service # If using Syslog-ng

Zweryfikuj konfigurację rsyslog

Konfiguracja RSyslog składa się z /etc/rsyslog.conf oraz plików w /etc/rsyslog.d/.

1. Sprawdź konfigurację portu:

   grep -E 'imudp|imtcp' /etc/rsyslog.conf
   

   Oczekiwane dane wyjściowe:

   module(load="imudp")
   input(type="imudp" port="514")
   module(load="imtcp")
   input(type="imtcp" port="514")
   

2. Sprawdź, czy istnieje konfiguracja przekazywania AMA:

   cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
   

   Plik powinien zaczynać się od:

   # Azure Monitor Agent configuration: forward logs to azuremonitoragent
   

Weryfikowanie stanu portu

Sprawdź, czy wymagane porty nasłuchują:

sudo ss -lnp | grep -E "28330|514"

Oczekiwane dane wyjściowe:

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

Potwierdza to:

• RSyslog nasłuchuje na porcie 514 (TCP i UDP)
• MDSD (składnik AMA) nasłuchuje na porcie 28330 (TCP)

Weryfikowanie konfiguracji reguły zbierania danych

Sprawdź, czy funkcja DCR jest prawidłowo skonfigurowana dla agenta.

Dla logów CEF:

sudo grep -i -r "SECURITY_CEF_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

W przypadku dzienników usługi Cisco ASA:

sudo grep -i -r "SECURITY_CISCO_ASA_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Dane wyjściowe powinny zawierać ciąg JSON zawierający konfigurację dcr.

Przejrzyj reguły zapory

Upewnij się, że reguły zapory zezwalają na komunikację między:

• Źródło logów i RSyslog (port 514)
• RSyslog i AMA (port 28330)
• Punkty końcowe AMA i platformy Azure

Konfiguracja reguły zbierania danych

Włącz wszystkie funkcje na potrzeby rozwiązywania problemów

Na potrzeby wstępnego rozwiązywania problemów:

1. W Azure Portal przejdź do reguły zbierania danych.
2. Włącz wszystkie urządzenia dziennika systemowego.
3. Wybierz wszystkie poziomy rejestrowania.
4. Jeśli ta opcja jest dostępna, włącz zbieranie komunikatów bez facility lub poziomu ważności.

Aby uzyskać więcej informacji, zobacz Wybór obiektów i poziomów ważności.

Walidacja formatu Common Event Format (CEF)

Wymagania dotyczące formatu CEF

Program CEF używa dziennika systemowego jako mechanizmu transportu o tej strukturze:

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

Przykład:

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

Typowe problemy z formatowaniem CEF

Nieprawidłowy format nagłówka

• Upewnij się, że wersja CEF jest obecna: CEF:0|
• Wszystkie pola nagłówka muszą być obecne i oddzielone znakiem pionowej kreski (|)

Nieprawidłowe maskowanie znaków

• Znaki „|” w wartościach nagłówka muszą być poprzedzone znakiem ucieczki: \|
• Ukośniki odwrotne () muszą być poprzedzone znakiem ucieczki: \\
• Znaki równości (=) w rozszerzeniach muszą zostać zmienione: \=

Brakujące lub niezamapowane wartości

• Jeśli nie można zamapować wartości na pole standardowe, jest ona przechowywana w kolumnie AdditionalExtensions
• Zobacz Mapowanie pól CEF i CommonSecurityLog dla mapowań pól

Aby uzyskać pełną specyfikację CEF, wyszukaj dokumentację "Implementing ArcSight Common Event Format (CEF)".

Zaawansowane rozwiązywanie problemów

Włączanie śledzenia diagnostycznego

1. Edytuj plik konfiguracji AMA:

   sudo vim /etc/default/azuremonitoragent
   

2. Dodaj flagi śledzenia do wiersza MDSD_OPTIONS:

   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. Uruchom ponownie agenta:

   sudo systemctl restart azuremonitoragent
   

4. Odtwórz problem i poczekaj kilka minut.

5. Przejrzyj informacje debugowania w programie /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

6. Usuń flagę śledzenia i uruchom ponownie agenta po rozwiązaniu problemów.

Monitorowanie przetwarzania dzienników w czasie rzeczywistym

Wyświetlanie dzienników przychodzących podczas ich przetwarzania:

tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Filtruj pod kątem określonych typów dzienników:

sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.* | grep -a "CEF"

Przejrzyj konkretne dzienniki obiektu:

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

Weryfikowanie pomyślnego przetwarzania dziennika

Po włączeniu flag śledzenia można sprawdzić, czy dzienniki są przetwarzane poprawnie, sprawdzając dane wyjściowe debugowania.

Przykład pozyskiwania logów ASA

W przypadku dzienników usługi Cisco ASA pomyślne przetwarzanie jest wyświetlane w dziennikach w następujący sposób:

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

Kluczowe wskaźniki pomyślnego przetwarzania:

• Zdarzenie jest rozpoznawane jako zdarzenie CiscoASA
• Dziennik jest przekazywany do usługi ODS (Operations Data Service)
• Identyfikator żądania jest generowany na potrzeby śledzenia
• Ładunek zawiera prawidłowo sformatowane dane JSON

Przykład pozyskiwania logów CEF

W przypadku dzienników CEF pomyślne przetwarzanie jest wyświetlane jako:

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

Kluczowe wskaźniki pomyślnego przetwarzania CEF:

• Typ danych jest SECURITY_CEF_BLOB
• Żądanie przesłania zawiera prawidłowy punkt końcowy
• Struktura komunikatów CEF jest zachowywana w ładunku
• Metryki kompresji pokazują, że dane są zoptymalizowane pod kątem transferu

Zbieranie informacji diagnostycznych

Przed otwarciem zgłoszenia do pomocy technicznej zbierz następujące informacje:

Uruchom narzędzie do rozwiązywania problemów z usługą AMA

Skrypt można uruchomić z określonymi flagami dla różnych typów dzienników.

• --cef: Dla dzienników Common Event Format
• --asa: Dla logów Cisco ASA
• --ftd: W przypadku dzienników usługi Cisco Firepower Threat Defense

Dane wyjściowe są zapisywane w pliku /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]

Zawartość pokrewna

• Pozyskiwanie komunikatów dziennika systemowego i CEF za pomocą agenta Azure Monitor
• Omówienie łączników CEF i Syslog za pośrednictwem AMA
• Rozwiązywanie problemów z agentem monitora Azure
• Reguły zbierania danych w usłudze Azure Monitor