Rozwiązywanie problemów z formatem CEF i dziennikiem syslog za pośrednictwem łączników usługi AMA

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

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

• Importowanie wiadomości syslog i CEF do usługi Microsoft Sentinel przy użyciu agenta Azure Monitor
• CEF za pośrednictwem łącznika danych usługi AMA — konfigurowanie określonego urządzenia lub aplikacji
• Omówienie agenta usługi Azure Monitor

Przegląd architektury

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

Kluczowe składniki:

• RSyslog/Syslog-ng: Odbiera dzienniki na porcie 514 i przesyła je do usługi AMA
• Agent usługi Azure Monitor: przetwarza dzienniki zgodnie z regułami zbierania danych (DCR)
• Reguła zbierania danych: definiuje dzienniki do zebrania i miejsca ich wysyłania

Początkowe kroki weryfikacji

Sprawdź, czy dzienniki są odbierane

Po skonfigurowaniu dzienniki mogą pojawić się w usłudze Microsoft Sentinel w ciągu 20 minut.

1. Uruchom tcpdump, aby sprawdzić, czy dzienniki docierają do forwardera.

   sudo tcpdump -i any port 514 -A -vv
   

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

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

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

Sprawdzanie stanu rozszerzenia agenta usługi Azure Monitor

1. W witrynie Azure Portal przejdź do maszyny wirtualnej usługi przesyłania dalej dziennika.
2. Wybierz opcję Rozszerzenia i aplikacje.
3. Wybierz rozszerzenie AzureMonitorLinuxAgent .
4. Sprawdź, czy stan wskazuje prowizjonowanie zakończone sukcesem.

Zweryfikuj wersję agenta

1. W bloku rozszerzenia AzureMonitorLinuxAgent zaznacz pole Wersja .
2. Upewnij się, że wersja jest jedną z 2-3 najnowszych wersji. Zobacz szczegóły wersji usługi AMA , aby uzyskać 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

Weryfikowanie konfiguracji RSyslog

Konfiguracja RSyslog składa się z /etc/rsyslog.conf i 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 konfiguracja przekazywania usługi AMA istnieje:

   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 TCP 28330.

Sprawdź konfigurację reguły gromadzenia danych

Sprawdź, czy DCR jest prawidłowo skonfigurowany na agencie.

W przypadku dzienników CEF:

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

W przypadku dzienników Cisco ASA:

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

Dane wyjściowe powinny pokazywać ciąg JSON zawierający konfigurację DCR.

Przejrzyj reguły zapory ogniowej

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 usługi AMA i platformy Azure

Konfiguracja reguły zbierania danych

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

W przypadku początkowego rozwiązywania problemów:

1. W witrynie Azure Portal przejdź do reguły zbierania danych.
2. Włącz wszystkie obiekty dziennika systemowego.
3. Wybierz wszystkie poziomy dziennika.
4. Jeśli jest dostępna, włącz zbieranie komunikatów bez funkcji ani ważności.

Aby uzyskać więcej informacji, zobacz Wybierz funkcje i istotności.

Walidacja formatu Common Event Format (CEF)

Wymagania dotyczące formatu CEF

Format CEF używa protokołu Syslog jako mechanizmu transportu w 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 formatu CEF jest obecna: CEF:0|
• Wszystkie pola nagłówka muszą być obecne i rozdzielane znakami pionowej kreski (|)

Niewłaściwy znak ucieczki

• Znaki kreski kreskowej (|) w wartościach nagłówka muszą zostać uniknięci: \|
• Ukośniki odwrotne () muszą zostać uniknięci: \\
• Znaki równości (=) w rozszerzeniach muszą zostać uniknięci: \=

Brakujące lub nieskojarzone wartości

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

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

Zaawansowane rozwiązywanie problemów

Włączanie śledzenia diagnostycznego

1. Edytuj plik konfiguracji usługi 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. Zreplikuj problem i zaczekaj kilka minut.

5. Przejrzyj informacje o debugowaniu w pliku /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świetl dzienniki przychodzące w miarę 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 określone dzienniki systemowe:

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

Weryfikowanie pomyślnego przetwarzania dzienników

Po włączeniu flag śledzenia można sprawdzić, czy dzienniki są przetwarzane prawidłowo, sprawdzając wynik debugowania.

Przykład pobierania dzienników ASA

W przypadku dzienników Cisco ASA pomyślne przetwarzanie pojawi się w dziennikach jako:

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 AMA

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

• --cef: w przypadku dzienników Common Event Format
• --asa: w przypadku dziennikó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]

Treści powiązane

• Pozyskiwanie komunikatów syslog i CEF za pomocą agenta usługi Azure Monitor
• Omówienie CEF i Syslog przez łączniki AMA
• Rozwiązywanie problemów z agentem usługi Azure Monitor
• Reguły zbierania danych w usłudze Azure Monitor