AMA 커넥터를 통해 CEF 및 Syslog 문제 해결

이 문서에서는 Microsoft Sentinel AMA(Azure Monitor Agent)를 사용하여 CEF(Common Event Format) 및 Syslog 데이터 수집에 대한 문제 해결 지침을 제공합니다. 이 가이드를 사용하여 로그 전달자 컴퓨터의 수집 문제를 진단하고 resolve. 명령 및 구성은 AMA 및 RSyslog/Syslog-ng가 설치된 로그 전달자 컴퓨터에서 실행되어야 합니다.

문제 해결을 시작하기 전에 다음 문서를 숙지하세요.

• Azure Monitor 에이전트를 사용하여 Microsoft Sentinel syslog 및 CEF 메시지 수집
• AMA 데이터 커넥터를 통한 CEF - 특정 어플라이언스 또는 디바이스 구성
• 에이전트 모니터링 개요 Azure

아키텍처 개요

다음 다이어그램에서는 RSyslog 및 Azure Monitor 에이전트를 통해 로그 원본에서 Microsoft Sentinel/로그 분석 작업 영역으로의 데이터 흐름을 보여 줍니다.

주요 구성 요소:

• RSyslog/Syslog-ng: 포트 514에서 로그를 수신하고 AMA에 전달합니다.
• Azure Monitor 에이전트: DCR(데이터 수집 규칙)에 따라 로그를 처리합니다.
• 데이터 수집 규칙: 수집할 로그와 보낼 위치를 정의합니다.

초기 확인 단계

로그가 수신되고 있는지 확인

로그는 구성 후 Microsoft Sentinel 표시되는 데 최대 20분이 걸릴 수 있습니다.

1. tcpdump를 실행하여 로그가 전달자에 도착하는지 확인합니다.

   sudo tcpdump -i any port 514 -A -vv
   

2. 로그 원본이 올바른 전달자 IP 주소로 메시지를 보내도록 구성되어 있는지 확인합니다.

3. 연결에 영향을 줄 수 있는 인프라 구성 요소를 확인합니다.

   • 방화벽
   • 부하 분산 장치
   • 네트워크 보안 그룹

Azure 에이전트 확장 상태 모니터링 확인

1. Azure Portal 로그 전달자 가상 머신으로 이동합니다.
2. 확장 + 애플리케이션을 선택합니다.
3. AzureMonitorLinuxAgent 확장을 선택합니다.
4. 상태가프로비저닝 성공으로 표시되는지 확인합니다.

에이전트 버전 확인

1. AzureMonitorLinuxAgent 확장 블레이드에서 버전 필드를 검사.
2. 버전이 최신 릴리스 2-3개 중 하나인지 확인합니다. 최신 버전은 AMA 버전 세부 정보를 참조하세요.

에이전트 수준 문제 해결

에이전트 및 RSyslog 서비스가 실행 중인지 확인합니다.

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

RSyslog 구성 확인

RSyslog 구성은 의 /etc/rsyslog.conf 및 파일로 /etc/rsyslog.d/구성됩니다.

1. 포트 구성 확인:

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

   예상 출력:

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

2. AMA 전달 구성이 있는지 확인합니다.

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

   파일은 다음으로 시작해야 합니다.

   # Azure Monitor Agent configuration: forward logs to azuremonitoragent
   

포트 상태 확인

필요한 포트가 수신 대기하고 있는지 확인합니다.

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

예상 출력:

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

이렇게 하면 다음이 확인됩니다.

• RSyslog가 포트 514(TCP 및 UDP)에서 수신 대기 중
• 포트 28330(TCP)에서 수신 대기 중인 MDSD(AMA 구성 요소)

데이터 수집 규칙 구성 확인

DCR이 에이전트에 올바르게 구성되어 있는지 확인합니다.

CEF 로그의 경우:

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

Cisco ASA 로그의 경우:

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

출력에는 DCR 구성이 포함된 JSON 문자열이 표시됩니다.

방화벽 규칙 검토

방화벽 규칙이 다음 간의 통신을 허용하는지 확인합니다.

• 로그 원본 및 RSyslog(포트 514)
• RSyslog 및 AMA(포트 28330)
• AMA 및 Azure 엔드포인트

데이터 수집 규칙 구성

문제 해결을 위해 모든 기능 사용

초기 문제 해결의 경우:

1. Azure Portal 데이터 수집 규칙으로 이동합니다.
2. 모든 syslog 기능을 사용하도록 설정합니다.
3. 모든 로그 수준을 선택합니다.
4. 사용 가능한 경우 기능이나 심각도가 없는 메시지 수집을 사용하도록 설정합니다.

자세한 내용은 시설 및 심각도 선택을 참조하세요.

CEF(Common Event Format) 유효성 검사

CEF 형식 요구 사항

CEF는 다음 구조의 전송 메커니즘으로 Syslog를 사용합니다.

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

예:

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

일반적인 CEF 서식 문제

잘못된 헤더 형식

• CEF 버전이 있는지 확인합니다. CEF:0|
• 모든 헤더 필드가 있고 파이프(|) 문자로 구분되어야 합니다.

부적절한 문자 이스케이프

• 헤더 값의 파이프 문자(|)를 이스케이프해야 합니다. \|
• 백슬라이쉬()를 이스케이프해야 합니다. \\
• 확장의 등호(=)를 이스케이프해야 합니다. \=

누락되거나 매핑되지 않은 값

• 값을 표준 필드에 매핑할 수 없는 경우 열에 AdditionalExtensions 저장됩니다.
• 필드 매핑 은 CEF 및 CommonSecurityLog 필드 매핑을 참조하세요.

전체 CEF 사양을 보려면 "ArcSight CEF(Common Event Format) 구현" 설명서를 검색합니다.

고급 문제 해결 방법

진단 추적 사용

1. AMA 구성 파일을 편집합니다.

   sudo vim /etc/default/azuremonitoragent
   

2. 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. 에이전트를 다시 시작합니다.

   sudo systemctl restart azuremonitoragent
   

4. 문제를 재현하고 몇 분 정도 기다립니다.

5. 에서 디버그 정보를 검토합니다 /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

6. 추적 플래그를 제거하고 문제 해결 후 에이전트를 다시 시작합니다.

실시간으로 로그 처리 모니터링

들어오는 로그가 처리될 때 다음을 확인합니다.

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

특정 로그 유형에 대한 필터:

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

특정 시설 로그를 검토합니다.

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

성공적인 로그 처리 확인

추적 플래그를 사용하도록 설정하면 디버그 출력을 검사하여 로그가 올바르게 처리되고 있는지 확인할 수 있습니다.

ASA 로그 수집 예제

Cisco ASA 로그의 경우 성공적인 처리가 로그에 다음과 같이 표시됩니다.

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

성공적인 처리의 주요 지표:

• 이 이벤트는 CiscoASA 이벤트로 인식됩니다.
• 로그가 ODS(Operations Data Service)에 업로드됩니다.
• 추적을 위해 요청 ID가 생성됩니다.
• 페이로드에 올바르게 서식이 지정된 JSON 데이터가 포함됩니다.

CEF 로그 수집 예제

CEF 로그의 경우 성공적인 처리가 다음과 같이 표시됩니다.

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

성공적인 CEF 처리의 주요 지표:

• 데이터 형식이 SECURITY_CEF_BLOB
• 업로드 요청에는 유효한 엔드포인트가 포함됩니다.
• CEF 메시지 구조는 페이로드에 유지됩니다.
• 압축 메트릭은 데이터가 전송에 최적화되고 있음을 보여 줍니다.

진단 정보 수집

지원 사례를 열기 전에 다음 정보를 수집합니다.

AMA 문제 해결사 실행

스크립트는 다른 로그 형식에 대한 특정 플래그를 사용하여 실행할 수 있습니다.

• --cef: 일반적인 이벤트 형식 로그의 경우
• --asa: Cisco ASA 로그의 경우
• --ftd: Cisco Firepower Threat Defense 로그의 경우

출력은 에 /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]

관련 콘텐츠

• Azure Monitor 에이전트를 사용하여 syslog 및 CEF 메시지 수집
• AMA 커넥터를 통한 CEF 및 Syslog 개요
• Azure Monitor 에이전트 문제 해결
• Azure Monitor의 데이터 수집 규칙