Wazuh 디코더와 룰 이해

Wazuh Analysis Engine 동작 흐름과 디코더, 룰 구조 및 커스텀 룰 작성 방식에 대한 이해를 작성.

 

- Wazuh Decoder 구조와 원리

- Wazuh Rule 기본 구조

- Default Rule과 Custom Rule

- Wazuh Rule Order

 

Analysis Engine

 

로그의 라이프사이클은 생성 -> 수집 및 전송 -> 수신 -> 디코딩 -> 롤 평가 -> 경고 생성 단계를 거친다.

Analysis Engine 은 Wazuh 서버 내에서 동작하는 핵심 분석 프로세스로 로그를 단순히 저장하는 것이 아니라 위협 가능성을 실시간으로 평가하는 역할을 한다.

 

Wazuh는 수신된 로그 메세지를 일관되게 해석하고 분석하기 위해 디코더를 사용한다.

Apache 는 HTTP 로그를, SSH는 로그인 실패 로그를, Windows는 이벤트 ID 기반으로 로그를 기록을 한다. 그래서 이런 서로 다른 로그 포멧들을 Wazuh는 디코딩을 활용해 정규표현식을 기반으로 필드형식으로 변환하여 모두 같은 룰셋으로 판단하여 비교하고 저장할 수 있다.

 

Decoder

 

디코더는 XML 형식으로 저장되며, 디코딩된 결과는 내부에서 JSON 형식으로 저장 및 처리 된다.

Apache, Auditd , Windows, Journald등과 같은 주요 로그 소스에 대해서는 Wazuh에서 기본 디코더를 자동으로 제공하여 로그에서 필요한 필드를 자동 추출하게 된다. 하지만 기본 디코더가 지원하지 않는 특수한 로그 형식을 처리하려면 사용자가 직접 커스텀 디코더를 XML로 작성하여 로그를 디코딩할 수 있다. 

기본 디코더는 /var/ossec/ruleset/decoders/ 에 위치한다.

 

아래는 ssh 접속 실패 로그를 위한 디코더 설정이다.

 

prematch는 "sshd~ invalid user" 문장이 필수로 들어가있어야만 뒤의 정규표현식 검사를 할 수 있다.

<regex> 는 정규표현식으로 괄호로 감싼 부분이 추출 대상이다. 여기서는 사용자명, 출발 IP, 포트 번호를 추출한다.

<order> 추출된 값을 어떤 필드에 매핑할지 순서를 지정한다. 여기서는 dstuser, srcip, srcport 순으로 매핑된다.

 

예시 로그를 보자.

 

로그 내용에 따르면 존재하지 않는 사용자 guest로 로그인 시도가 있었고, 접속 시도 IP는 192.168.1.50, 포트는 55432다.

 

 

이 로그를 디코딩하기 전에 Pre-decoding 단계를 거쳐야 한다.

이 단계에서는 로그 형식과 무관하게 모든 로그에서 공통적인 기본 정보를 추출한다.

timestamp, hostname, program_name(로그를 생성한 프로세스) 을 추출한다.

 

이제 Decoding 단계에서는 다음과 같은 데이터가 추출된다.

dstuser : guest

srcip : 192.168.1.50

srcport : 55432

 

이렇게 되면 로그 한 줄이 간단하게 보안 로그로 변환된다.

 

Windows Decoder

로그의 종류마다 각기 다른 디코더가 존재하며, 각각의 디코더는 로그의 소스, 이벤트 타입, 세부 필드를 식별하여 구조화된 데이터로 전환하다.

디코더 파일은 /varossec/ruleset/decoders 디렉터리에 저장되어있으며, 0380-windows_decoders.xml에는 윈도우 환경에서 흔히 발생하는 다양한 로그를 분석할 수 있는 디코더가 담겨있다.

 

그 종류에는 윈도우 방화벽 로그, IIS 웹 로그, Sysmon 이벤트로그 windows Defender 로그 등이 있다.

 

Sysmon의 이벤트 로그는 일반적인 로그와는 다르게, 하나의 이벤트가 여러 줄에 걸쳐 다양한 정보를 포함하고있는 구조다.

예를들면 프로세스 ID, 실행된 이미지 경로, 커맨드라인, 유저 정보, 해시값, 부모 프로세스 정보 등이 줄바꿈된 상태로 각각 출력된다.

이처럼 여러줄로 구성된 멀티라인 로그를 분석하기 위해 Wazuh는 여러개의 디코더를 체인처럼 연결해서 사용한다.

이 디코더는 Sysmon ID 1번을 디코딩하는 디코더다.

 

이 경로의 sysmon 이벤트 1번 룰이 들어있는 xml 파일을 확인해보자.

 

룰 id 92002번을 보면 커맨드라인에 cmd.exe가 포함되어있을 경우 룰이 작동한다는 의미이다.

하지만 커맨드라인에 cmd.exe만 있다고해서 룰이 작동되는 것은 아니다. 왜냐하면 if_sid의  92000 부분에서 id가 92000번인 룰에 매칭 되고 났을 때만 적용된다.

 

룰 id 92000을 찾아가보면 cscript 또는 wscript가 부모 프로세스인 경우에 매칭되는 룰이다. VB스크립트 또는 JS 스크립트 를 실행하는 스크립트 엔진이다.

 

따라서 Wazuh는 이런식으로 여러 룰들을 체인형태로 연결하여 하나의 이상징후만 보지않고 다양한 상황을 보고 탐지하여 오탐율을 줄일 수 있다.

Wazuh Rule

룰은 수집된 로그 메세지를 평가하여 경고를 생성할지 결정하는 조건의 집합이다.

로그가 디코딩된 후, 해당 로그의 필드 값과 룰의 조건을 비교하여 위협 여부를 판단한다. (위협 탐지, 경고 생성, 상관 분석, MITRE ATT&ACK 패밍, 자동화 대응 정책)

 

각 룰은 고유 ID, 심각도, 매칭 조건, 설명, 그룹으로 이루어져있다.

심각도별 설명

 

Wazuh Default Rules

기본으로 포함되는 내장 룰들로, 다양한 시스템과 보안 이벤트에 대응할 수 있도록 설계 되어있다. 해당 룰 파일들은 Wazuh 서버의 /var/ossec/ruleset/rules/ 경로에 위치하며 수정하여 사용할 수 있다.

Wazuh 팀에 의해 지속적으로 유지보수 및 업데이트되며, 최신 위협에 대응하고 탐지 역량을 강화하는데 중요한 역할을 한다.

 

 

아래의 예시 룰을 봐보자.

이 룰은 sshd 로그에서 로그인 실패 시도를 탐지하는데 사용되는 룰이다.

이러한 시도는 공격자가 시스템 계정 정보를 탐색하거나, Brute Force 공격의 사전 단계일 가능성이 있다.

만약 동일한 IP에서 이와 같은 시도가 짧은 시간 내 반복될 경우, 상위 룰이 추가로 매칭되어 SSH Brute-force 공격으로 탐지된다. 

 

<rule id="5710" level="5">

- 해당 룰의 ID는 5710, 심각도는 5.

 

<decoded_as> sshd </decoded_as>

- 로그가 sshd디코더로 해석된 경우에만 이 룰이 적용된다.

 

<match> Failed password for </match>

- 로그 메세지에 이 문자열이 포함되어있을 때 룰이 매칭된다.

- 이는 존재하지 않는 사용자이거나 잘못된 비밀번호를 입력한 SSH 인증 실패 상황을 의미한다.

 

<desciprtion>

- 룰이 트리거되면 대시보드나 alerts.json에 표시되는 설명이다.

 

<group>

- 해당 룰이 속하는 카테고리 그룹이다.

- authentication_failed 또는 sshd로 룰을 필터링하거나 상속 조건으로 설정할 수 있다.

 

Wazuh Custom Rules

직접 탐지 조건을 조직에 맞게 정의할 수 있다.

/var/ossec/etc/rules/local_rules.xml 에 작성하면되며, 기존 룰과 충돌을 피하기 위해 100000~120000의 ID를 사용하는 것이 권고된다.

 

same_srcip 는 이벤트의 출발지 IP가 동일한 경우에만 누적 조건을 계산하겠다는 의미이고, 60초 안에 10번 이상의 실패가 생겼을 경우를 의미한다. 경고 레벨은 10으로 지정되어있어 높은 위협으로 분류된다. 

 

이렇게 커스텀 룰을 활용하면 단순 이벤트를 기반으로 반복성, 패턴, 시간 조건까지 고려한 정밀 탐지가 가능해진다.

 

그럼 업무 시간 외에 PC에서 접속 기록이 생성되는 것을 탐지하는 커스텀 룰을 작성해보자.

해당 XML 파일을 수정한다.

 

<if_sid> 92027 </if_sid>

<time>6 pm - 8 am</time>

 

이 부분은 정상 로그인이라도 비업무 시간이면 위험 신호로 본다는 관제 정책을 구현한 예이다.

powershell.exe를 실행했을 시 트리거 되도록 하기위해 if_sid값을 92027을 넣어줬다. 

그러면 powershell.exe가 실행됐는데, 그이후 조건이 업무 외 시간에 만족한다면 이 룰이 탐지될 것이다.

 

업무외 시간인 6시 이후에 powershell 실행 하니 실제로 커스텀 설정한 100500 rule id가 탐지되었다.

 

Wazuh Rule Order

Wazuh는 룰 간 관계를 고려하여 순서대로 처리한다.

룰이 평가되기 전에 특정 조건이 먼저 충족되어야 하는 경우 이를 "if 조건"으로 설정한다.

이렇게 앞에 if_sid 5710 은 5710 룰이 트리거 된 뒤 조건이 만족해야만 매칭된다는 뜻이다.

 

 

요약

- 로그의 라이프사이클은 생성 -> 수집 및 전송 -> 수신 -> 디코딩 -> 롤 평가 -> 경고 생성 단계를 거친다.

- 디코더는 다양한 형식의 로그를 공통된 구조로 표준화하여 분석이 가능하도록 도와준다.

- 룰은 디코딩된 로그 필드에 기반해 조건을 비교하고 위협이 감지되면 경고를 생성한다.

- 또한 기본 룰 외에 조직 환경에 맞는 커스텀 룰 작성을 통해 탐지 능력을 유연하게 확장할 수 있다.

 

- 디코더는 멀티라인 로그의 구조를 처리하기 위해 여러 개의 디코더가 체이닝 방식으로 연결된다.

- 룰은 디코더로 구조화된 로그를 읽어 조건에 맞으면 alert를 발생한다.

- 기본 룰셋은 일반적인 보안 상황에 맞춰 설계되어 있기 때문에 조직의 보안 정책, 운영 시간, 중요 사용자, 민감한 시스템 등을 고려한 맞춤형 탐지가 어렵기 때문에 커스텀 룰 작성은 필수다.