Wazuh Whodata Windows 오류 6955 해결 방법: 감사 GUID를 활용한 현지화 우회 방안
src/syscheckd/src/whodata/win_whodata.c의 set_policies() 함수는 다음과 같은 순서로 동작합니다:
auditpol /backup→ "하위 카테고리 이름", "성공", "실패"와 같은 헤더가 포함된 CSV 파일 생성- 이 CSV를 파싱하여 현재 상태 확인
auditpol /restore→ 저장된 설정 적용 시도
문제는 Windows 10/11 버전 1809부터 auditpol /restore 명령이 하위 카테고리 이름에 대해 정확히 일치해야 한다는 점입니다. CSV에서 'File System'이라고 지정했지만 auditpol에서는 'File System'을 기대한다면, 명령은 오류 코드 0x134c(5004)로 실패하게 되며, Wazuh에서는 이를 6955 오류로 해석합니다. 이는 Microsoft Docs에도 명시되어 있습니다: “/restore 명령은 로케일에 민감하며, 백업 파일이 다른 언어 설정의 시스템에서 생성되었을 경우 실패할 수 있습니다.”
핵심 통찰: 모든 감사 하위 카테고리는 OS 언어와 무관한 하드코딩된 GUID를 가지고 있습니다. 예를 들어:
- File System:
{0CCE921D-69AE-11D9-BED3-505054503030} - Handle Manipulation:
{0CCE9223-69AE-11D9-BED3-505054503030} - Registry Changes:
{0CCE9227-69AE-11D9-BED3-505054503030}
이러한 식별자는 auditpol /list /subcategory:* 명령으로 접근 가능하며, Windows Vista부터 Windows 11까지 안정적으로 유지됩니다.
로케일 의존성을 제거한 set_policies() 재작성 방법
win_whodata.c의 set_policies() 함수를 재작성하는 것이 핵심 기술 단계입니다. 새로운 구현에서는 CSV 스택을 완전히 제거하고, GUID를 직접 사용해 auditpol /set 명령만 실행하도록 변경합니다. 패치의 주요 요구 사항은 다음과 같습니다:
- 최소한의 시스템 호출: 각
system()호출 후 비영역 종료 코드를 반드시 확인 - 원자성: 한 하위 카테고리가 실패하더라도 나머지는 계속 설정 진행
- 디버깅 정보: 발생한 모든 오류는 해당 하위 카테고리와 함께 로그에 기록
- Windows Server 2016 이상과 호환: 지정된 모든 GUID는 Server Core와 Desktop Edition 모두에서 지원됩니다.
구현 과정에서 popen()이나 CreateProcessA를 사용하지 않아 콘솔 인코딩 문제를 방지합니다. 직접 system()을 호출함으로써 시스템의 코드 페이지에서 실행되도록 하여 auditpol이 GUID를 올바르게 해석하도록 합니다.
WIN_WHODATA를 포함한 WinAgent 빌드를 위한 추가 패치
Windows용 Wazuh 에이전트를 빌드하려면 빌드 과정에서 세 가지 중요한 변경이 필요합니다:
- 전처리기 정의 활성화 — Makefile의
DEFINES섹션에-DWIN_WHODATA를 추가하여syscheckd의 해당 코드 블록을 활성화 - CMake에 플래그 전달 —
syscheckd/build빌드 스트링을 수정하여-DWIN_WHODATA를 CFLAGS 컴파일 라인에 전달 - wevtapi.lib 링크 — whodata 모드에서 사용되는
EvtSubscribe,EvtNext및 기타 이벤트 로그 API 함수 호출에 필수적인 의존성
세 번째 항목이 없으면 빌드 중 EvtSubscribe에 대한 미정의 참조 오류로 인해 빌드가 실패합니다. wevtapi.lib 라이브러리는 MinGW-w64(mingw-w64-dev 패키지)에 포함되어 있으며 별도의 SDK가 필요하지 않습니다.
또한 buffer.c도 수정해야 합니다: dispatch_buffer() 함수에서 return NULL; 대신 return 0;으로 변경하세요. 이 함수의 시그니처는 void*가 아니라 int이므로, 이 버그로 인해 whodata 모드에서 이벤트 버퍼를 처리할 때 정의되지 않은 동작이 발생합니다.
테스트 및 프로덕션 배포
성공적으로 컴파일(make TARGET=winagent)된 결과물인 wazuh-agent.exe에는 완전히 독립적인 whodata 구현이 포함되어 있습니다. 검증을 위해:
ossec.conf에서whodata를 활성화한 상태로 에이전트를 시작하세요:
<syscheck>
<whodata>yes</whodata>
</syscheck>- 로그에 6955, 6915, 6916 오류가 없는지 확인
- Kibana 또는
wazuh-logtest를 통해type="whodata"속성이 있는FIM이벤트가 존재하는지 확인 ru-RU,zh-CN,es-ES등 다양한 로케일의 Windows 환경에서도 동일하게 작동하는지 확인
기업 환경에서의 배포 시에는 EV Code Signing 인증서로 실행 파일에 서명해야 합니다. auditpol /set 명령은 관리자 권한을 필요로 하며, 신뢰할 수 있는 서명이 없으면 Windows Defender Application Control(WDAC)에 의해 차단될 수 있기 때문입니다.
무엇이 중요한가
- 오류 6955는 Wazuh의 버그가 아니라, 영어가 아닌 Windows 로케일에서
auditpol /restore의 제한 때문에 발생합니다. - 하위 카테고리 이름 대신 GUID를 사용하는 것이 시스템 설정을 수정하지 않고도 크로스-로케일 호환성을 보장하는 유일한 방법입니다.
wevtapi.lib는 whodata의 필수 의존성입니다. 이 라이브러리가 없으면 감사 이벤트에 대한 실시간 구독이 불가능합니다.buffer.c패치는 안정성 확보에 매우 중요합니다. 반환 타입이 맞지 않으면 이벤트 버퍼가 오버플로우될 때 세그멘테이션 폴트가 발생합니다.- 컴파일된 에이전트는 추가 구성 요소 설치가 필요하지 않습니다. 필요한 모든 것이
wazuh-agent.exe에 내장되어 있습니다.
모든 변경 사항은 Wazuh 공식 릴리스 4.14.x와 하위 호환되며, 패치 파일과 빌드 후 스크립트를 통해 CI/CD 파이프라인에 통합할 수 있습니다. 자동화를 위해서는 사전 검증된 diff 파일과 소스 해시 검증을 통해 git apply를 사용하는 것이 좋습니다.
— Editorial Team
아직 댓글이 없습니다.