WEF 및 WEC를 사용한 중앙 로그 수집의 핵심

지난주에는 이벤트 로깅의 핵심을 다루었습니다. 즉, 모든 시스템이 시스템에서 발생하는 중요한 이벤트나 활동에 관한 로그를 기록하도록 보장하는 방법을 살펴보았습니다. 이번 주에는 이러한 이벤트 로그를 Windows 이벤트 수집기(WEC) 서버에 중앙 수집한 후 Elastic Security로 전달하는 방법의 핵심을 다룹니다.

WEF 및 WEC

최신 버전의 Windows에는 WS-관리(WSman) 프로토콜을 구현하는 Windows 원격 관리(WinRM) 서비스가 포함되어 있습니다. 약어가 더 복잡해지지만, 이 모든 것은 Windows 관리 계측(WMI)의 일부입니다. WinRM의 한 구성 요소가 Windows 이벤트 전달(WEF) 서비스이므로, WinRM 등을 활성화해야 합니다. WEF는 Windows 이벤트 로그를 Windows 이벤트 수집기(WEC) 서비스를 실행하는 Windows Server로 전달할 수 있습니다.

전달에는 두 가지 모드가 있습니다.

1. 원본 시작: WEF 서비스가 WEC 서버에 연결
2. 수집기 시작: WEC 서비스가 WEF 서비스에 연결

두 모드 모두 WSman을 사용해 로그를 전달하며, WinRM이 실행 중이어야 합니다.

WEF와 WEC를 설정할 때는 여러 가지 함정과 장애물이 있습니다. WEC Cookbook을 따르면 이를 피할 수 있습니다. 그러나 더 폭넓은 관점과 풍부한 컨텍스트를 제공하기 위해, 여기에서는 이러한 문제와 Cookbook에서 채택한 해결 방법을 함께 설명합니다.

'Forwarded Events' 이벤트 로그 파일

Windows 이벤트 로그 시스템에는 채널이 있습니다. 이러한 채널은 궁극적으로 해당 채널에 기록되는 모든 이벤트 로그를 저장하는 이벤트 로그 파일을 기반으로 합니다. Windows 시스템에는 미리 정의된 채널 세트가 제공되며, 애플리케이션은 새 'Provider'를 등록하여 자체 채널을 추가할 수 있습니다.

즉, 기본 상태의 WEC 서버에는 일반적인 Windows 서버가 자체 로그를 위해 보유하는 채널만 있습니다. 그렇다면 WEC 서버로 전달되는 모든 로그는 어디에 저장해야 할까요? 세 가지 옵션을 살펴보겠습니다.

1. 원격 채널과 일치하는 로컬 채널에 저장합니다(즉, 원격 'Security' 채널 이벤트를 WEC의 로컬 'Security' 채널에 저장).

함정:

• 모든 원격 로그가 로컬 로그와 뒤섞입니다. 
• WEC 서버가 자체 이벤트 로그를 이 채널로 다시 전달하는 루프가 발생할 수 있습니다. 
• 로그 관리와 액세스 제어가 매우 어려워집니다.

2. 모든 원격 로그를 로컬 'Forwarded Events' 채널에 저장합니다.

함정:

• 모든 쓰기 작업이 단일 파일에서 이루어지므로 쓰기 성능이 저하됩니다.
• 이벤트가 별도의 파일로 분할되지 않으므로 검색/읽기 성능이 저하됩니다.
• 데이터 수명 주기는 로그 파일별로 관리되므로, 전달된 모든 이벤트가 동일하게 처리되어 데이터 수명 주기 관리가 부실해집니다.
• 모든 작업이 단일 파일에서 병목 상태에 빠지므로 WEC 서버의 리소스 활용률이 낮아집니다.
• 별도 파일을 사용하면 파일별로 차별화된 액세스 제어를 적용할 수 있지만, 이 방식에서는 액세스 관리가 부실해집니다.
• 위 문제로 인해 많은 조직이 전달할 이벤트 로그를 크게 제한하므로, 수집 범위와 가시성에 공백이 생깁니다.

3. WEC 서버용 새 채널을 생성합니다. 

이는 생각만큼 명확한 방법이 아니며, 이 옵션이 있다는 사실을 몰랐더라도 충분히 이해할 만합니다.

많은 WEC 서버가 위의 옵션 1 또는 2로 설정되어 있었습니다. 그러다 약 15년 전에 Microsoft 내부 보안 팀이 Windows SDK를 사용하여 옵션 3을 구현한 방법을 블로그 글로 작성했습니다. 여기에는 2016년에 게시된 유사한 개정판이 있습니다.

새 WEC 이벤트 채널

임의의 이벤트 채널을 생성할 수 있게 되었다면, 무엇을 생성해야 할까요? WEC 서버는 어떻게 구성하고 아키텍처를 설계해야 할까요? 이에 대해서는 다양한 접근 방식이 있습니다. WEC Cookbook에서는 로그의 액세스 제어와 데이터 수명 주기를 그에 맞게 관리할 수 있도록 엔터프라이즈 자산을 함께 그룹화합니다.

더 자세히 살펴보기 전에 다른 접근 방식을 보겠습니다. Palantir의 WEC 아키텍처와 가이드라인을 보신 적이 있을 수 있습니다. Palantir는 PowerShell, WMI, DNS, 방화벽 등 이벤트 로그 유형별로 채널을 생성했습니다. 이 채널에는 모든 자산 유형(도메인 컨트롤러, 도메인 서버, 도메인 워크스테이션)과 부서/사업 단위/OU의 로그가 포함됩니다. 또한 계층 구조로 구성되어 있지 않으므로 이벤트 뷰어에서는 긴 목록으로만 표시됩니다. 각 채널에는 해당하는 WEC 구독도 있습니다. Palantir는 권장 감사 정책도 제공합니다.

이처럼 Palantir의 방식과 같은 다른 접근 방식을 언급하는 이유는 하나의 방식이 모든 조직에 꼭 들어맞지는 않으며, Palantir의 접근 방식이 저희 Cookbook에서 제시한 방식보다 조직에 더 적합할 수 있기 때문입니다.

Palantir의 채널 목록을 살펴보셨다면 숫자 #가 채널 7개마다 증가하는 'WEC#-Something' 형식을 보셨을 것입니다. 이는 Windows 이벤트 로그 시스템에서 채널이 'Provider'라고 하는 항목으로 정의되고, 각 Provider는 최대 8개의 채널만 정의할 수 있기 때문입니다.

하지만 Windows SDK 개발자가 아닌 보안 담당자들이 사용하던 'ecmangen' 도구의 오프바이원 버그 때문에, Provider당 7개를 초과하는 채널을 사용하기가 번거로웠습니다.

Microsoft는 이 도구의 수많은 버그를 수정하는 대신 Windows SDK에서 ecmangen을 제외한 것으로 보입니다. 즉, 이전 SDK를 사용하거나 선호하는 XML 편집기 등을 사용해 Manifest XML 파일을 직접 만들어야 합니다.

다른 사람들과 마찬가지로 저도 처음에는 ecmangen을 사용했고, 작업을 쉽게 하기 위해 채널 수를 7개로 제한했습니다. 현재 Cookbook은 XML을 생성하는 PowerShell 스크립트를 기반으로 합니다. 더 이상 ecmangen이 필요하지 않으므로 원한다면 8개의 채널을 사용할 수 있습니다. 다만 Cookbook에서는 여전히 7개의 권장 채널만 사용합니다.

참고: Provider는 채널 8개가 담긴 상자라고 생각하면 됩니다. 각 채널은 궁극적으로 별도의 로그 파일입니다.

자산별 구성

원하는 수만큼 Provider를 둘 수 있다는 점을 활용하면 자산별로 구성할 수 있습니다. AD 환경에서는 이미 도메인 멤버를 자산 유형(예: 도메인 서버, 도메인 컨트롤러, 워크스테이션 등)별 및/또는 해당 자산이 속한 부서, 즉 조직 구성 단위별로 그룹화했을 가능성이 높습니다.

따라서 Cookbook에서는 부서(사업 단위 또는 OU)별, 자산 유형별 및/또는 자산 중요도별(랩/테스트/프로덕션) Provider와 같이, AD 구성에 맞는 Provider를 쉽게 생성할 수 있습니다.

자산 유형별로 분리하면 액세스 제어와 로그 수명 주기를 더 효과적으로 관리할 수 있다는 이점도 있습니다. 특정 자산 유형의 로그를 확인해야 할 때 해당 로그의 위치를 알 수 있습니다.

간단하게 하기 위해 모든 Provider에 동일한 채널 세트(최대 8개)를 적용합니다. 그런 다음 시스템을 Provider에 매핑하고(OU를 통해), 해당 시스템의 이벤트 로그를 그 Provider 내 채널에 매핑합니다.

기본적으로 AD 아키텍처에 맞게 WEC 서버를 구성하는 데 사용되는 'wec_config.ps1' 스크립트에는 일부 Provider 및 자산 할당이 정의되어 있습니다.

• Domain Controllers: 여기서는 멤버 할당이 명확하다고 생각합니다.
• Domain Servers: 도메인 내 서버
• Domain Clients: 사용자 워크스테이션(데스크톱/노트북)
• Domain Privileged: 권한 수준이 더 높은 시스템(예: 점프 호스트 또는 WEC 서버)
• Domain Members: 다른 그룹에 속하지 않는 일반 도메인 멤버를 위한 포괄 그룹
• Domain Misc: 적합한 그룹이 없는 호스트를 위한 기타 그룹

AD 환경에 맞도록 이 목록을 세분화하고 편집하는 것이 좋습니다.

기본으로 제공되어 즉시 사용할 수 있는 채널 목록은 다음과 같습니다.

• Application: 'Application' 및 유사 로그
• Security: 'Security' 및 유사 로그
• Sysmon: “Microsoft-Windows-Sysmon/Operational”
• System: 'System', 'HardwareEvents', DNS-Client, DHCP-Client, 'Setup' 및 유사 로그
• Script: 'Windows PowerShell' 및 유사 로그
• Service: DNS-Server, DHCP-Server 및 기타 서비스 로그
• Misc: 기타 모든 로그

다시 말하지만, 필요에 맞게 이를 변경할 수 있습니다.

WEC 구독

WEC 구독은 다음을 정의합니다.

• 전달할 이벤트를 선택하는 이벤트 로그(XPath) 필터
• 수신한 이벤트를 WEC 서버에 저장할 대상 채널
• 유형:
  • 수집기 시작: WEC가 WEF 서비스에 연결
    • 대상 컴퓨터: 연결할 컴퓨터 목록
  • 원본 시작: WEF가 WEC 서버에 연결
    • 컴퓨터 그룹: 컴퓨터 멤버가 이 구독에 액세스할 수 있는 AD 그룹
• 대역폭/지연 시간 및/또는 HTTP/HTTPS를 제어하기 위한 이벤트 전송 옵션
• 형식 유형: RenderedText 또는 이벤트 XML만 사용

Cookbook 스크립트, 특히 setup_subscriptions.ps1은 이벤트 XML 형식 유형을 구성합니다. 이벤트 XML은 훨씬 작으므로 처리량이 높아지고, 더 많은 로그를 저장할 수 있으며, 부하와 대역폭 사용량이 줄어듭니다. 하지만 원본 Provider(원격 시스템의 Provider)가 WEC 서버의 이벤트 로그 시스템에 로컬로 등록되어 있지 않으면 이벤트 뷰어에서 현지 언어로 된 메시지의 텍스트 설명을 표시할 수 없다는 단점이 있습니다. 그러나 RenderedText 이벤트를 전송하는 데는 리소스가 너무 많이 필요하므로 이를 정당화하기 어렵습니다.

처음에 WEF는 WinRM의 기능이라고 언급했습니다. 이 WinRM 구성 요소는 로컬 시스템의 'Network Service' 사용자로 실행됩니다. 즉, WEF는 실제로 대부분의 시스템 로그를 읽을 수 없으며, WEC 서버는 설명 정보가 거의 없는 Event ID 111 메시지와 그 외의 로그를 받지 못하게 됩니다. 이러한 이유로 Cookbook에서는 'Network Service'를 로컬 'Event Log Readers' 그룹에 추가하는 GPO를 만드는 과정을 안내합니다.

.

WinRM은 WEF 구성을 어떻게 가져올까요? 위에서 언급한 동일한 GPO에서 해당 서버의 모든 WEC 구독을 나열하는 WSman URL도 게시합니다. 실제로 여러 WEC 서버의 WSman 구독 URL을 여러 개 나열할 수 있으며, WEF 서비스는 이들을 모두 가져와 실행하려고 시도합니다. 따라서 중복 WEC 서버를 사용할 수 있습니다.

모든 구독이 적용된다고요? 워크스테이션의 이벤트 로그가 도메인 컨트롤러의 로그 파일로 전송되는 것은 원하지 않을 것입니다. 구독을 나타내는 WSman 항목에는 구독 구성에서 설정한 AD 그룹 권한이 적용됩니다. 즉, WEF가 실행 중인 컴퓨터가 해당 구독을 읽을 권한이 있는 AD 그룹의 멤버가 아니라면, 그 구독을 가져와 실행할 수 없습니다. 또한 주의하지 않아 컴퓨터가 둘 이상의 WEC 구독 AD 그룹에 속하면, 해당 WEF 호스트의 동일한 이벤트 로그가 WEC에 여러 건 수집됩니다.

컴퓨터 그룹을 사용해야 하나요? 하지만 컴퓨터가 배치된 OU를 기준으로 컴퓨터를 매핑하고 싶을 수 있습니다. 안타깝게도 WEF/WEC/WinRM/WSman은 그러한 방식으로 작동하지 않습니다. 그러나 Cookbook은 특정 그룹의 멤버십을 지정된 OU 아래의 컴퓨터와 동기화하는 메커니즘을 제공합니다. 따라서 모든 작업이 OU를 통해 이루어지는 것처럼 처리할 수 있습니다.

종합하기

효과적인 통합 가시성 또는 보안 사용 사례를 위해 WEF와 WEC를 설정할 때는 올바르게 구성해야 하는 복잡한 요소와 구성 요소가 많습니다.

하지만 걱정하지 마세요. Cookbook과 대부분의 단계를 자동화하는 PowerShell 스크립트 세트가 준비되어 있습니다. 따라서 실수할 여지가 줄어들고, 작업을 재현할 수 있어 실수를 더 쉽게 수정할 수 있습니다.

모든 작업은 원하는 대로 편집할 수 있는 wec_config.ps1 스크립트에서 시작됩니다. 이후의 모든 스크립트는 이를 기준으로 작동합니다. 예를 들어, wec_config.ps1에서 전달할 이벤트 로그를 선택하는 데 사용되는 이벤트 로그 필터를 변경한 다음, setup_subscriptions.ps1을 다시 실행하여 변경 사항을 적용할 수 있습니다.

스크립트의 역할을 살펴보겠습니다(Cookbook에서는 사용 방법을 훨씬 자세히 설명합니다).

• wec_config.ps1 - 다른 스크립트에서 참조하는 WEC 서버 구성
• gen_manifest.ps1 - Windows SDK용 모든 Provider와 해당 채널을 설명하는 Manifest XML을 생성합니다(ecmangen은 더 이상 필요하지 않습니다!)
• Manifest를 사용해 설치되는 모든 시스템(일반적으로 WEC 서버)에서 새 Provider와 채널을 구현하는 Windows 이벤트 하위 시스템 모듈 DLL을 빌드합니다.
• install_channels.ps1 - DLL과 Manifest를 로컬 시스템에 설치합니다.
• configure_channels.ps1 - 새로 설치한 모든 채널에 로그 경로 및 로그 크기 구성(wec_config.ps1의 구성)을 적용합니다.
• setup_subscriptions.ps1 - WEC 서버에서 Provider/채널에 대한 모든 구독을 설정(생성 또는 재구성)합니다.
• map_ou2group.ps1 - AD의 OU를 사용하고 싶겠지만, WEC 구독은 AD 그룹을 통해 컴퓨터를 선택합니다. 이 스크립트는 wec_config.ps1의 구성을 다시 사용하여, 지정된 OU 아래의 컴퓨터와 특정 그룹의 멤버십을 동기화합니다.
• gen_winlogbeat_config.ps1 - Winlogbeat와 함께 제공되는 구성은 추가 WEC 구독 채널을 모두 인식하지 못하므로, 이 스크립트가 해당 구성을 업데이트합니다.
• beat_cmd.ps1 - PowerShell에서 Beat 명령어와 상호 작용하기 위한 도우미 스크립트

안타깝게도 그룹 정책과 같은 AD 측 구성은 여전히 수동으로 해야 합니다. 하지만 Cookbook에는 스크린샷이 포함된 단계별 가이드가 있습니다. 언젠가는 이 작업을 위한 스크립트도 작성할 수 있으니, 계속 지켜봐 주세요.

마지막으로, 모든 WEC 로그를 Elastic Security로 전송하도록 Winlogbeat를 구성해야 합니다. Cookbook에서 이 과정도 안내합니다.

결론

이 블로그 글과 Cookbook 자체를 읽은 후에는 시작하기 전에 내려야 할 의사 결정과 엔터프라이즈에 적합한 WEC 서버를 만드는 데 필요한 모든 지침 및 도구를 충분히 이해하셨기를 바랍니다.

이제 적절한 감사 정책을 마련하고, WEF를 구성했으며, AD 도메인의 이벤트 로그를 Elastic Security로 전달할 WEC 서버도 설정했습니다. 다음 블로그 글에서는 Elastic Security에서 매우 중요하고 유용한 이 로그 데이터로 무엇을 할 수 있는지 살펴보겠습니다.

Elastic Security를 처음 사용한다면 Elastic Cloud의 Elasticsearch 서비스에서 최신 버전을 체험해 볼 수 있습니다. 또한 성공적인 시작을 위해 빠른 시작 교육도 꼭 활용해 보세요.

제가 작성한 다른 Cookbook 가이드도 확인해 보세요. https://ela.st/tjs-cookbook-lib