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

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

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

아키텍처 개요

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

주요 구성 요소:

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

초기 확인 단계

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

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

tcpdump를 실행하여 로그가 전달자에 도착하는지 확인합니다.
```
sudo tcpdump -i any port 514 -A -vv
```
로그 원본이 올바른 전달자 IP 주소로 메시지를 보내도록 구성되어 있는지 확인합니다.
연결에 영향을 줄 수 있는 인프라 구성 요소를 확인합니다.
- Firewalls
- 부하 분산 장치
- 네트워크 보안 그룹

Azure Monitor 에이전트 확장 상태 확인

Azure Portal에서 로그 전달자 가상 머신으로 이동합니다.
확장 프로그램 + 애플리케이션을 선택하세요.
AzureMonitorLinuxAgent 확장을 선택합니다.
상태가프로비전에 성공했음을 보여 주는지 확인합니다.

에이전트 버전 확인

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

비고

새 버전은 초기 릴리스 후에 배포하는 데 최대 5주가 걸릴 수 있습니다.

에이전트 수준 문제 해결

에이전트 및 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/에 있는 파일로 구성됩니다.

포트 구성 확인:

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

예상 출력:

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

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 엔드포인트

데이터 수집 규칙 구성

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

초기 문제 해결의 경우:

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

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

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) 구현" 설명서를 검색합니다.

고급 문제 해결 방법

진단 추적 활성화

경고

문제 해결 세션에 대해서만 추적 플래그를 사용하도록 설정합니다. 추적 플래그는 디스크 공간을 빠르게 채울 수 있는 광범위한 로깅을 생성합니다.

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

sudo vim /etc/default/azuremonitoragent

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"

에이전트를 다시 시작합니다.

sudo systemctl restart azuremonitoragent

문제를 재현하고 몇 분 정도 기다립니다.
/var/opt/microsoft/azuremonitoragent/log/mdsd.info에서 디버그 정보를 검토합니다.
추적 플래그를 제거하고 문제 해결 후 에이전트를 다시 시작합니다.

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

처리 중인 들어오는 로그를 봅니다.

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]

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-01-12