Wazuh의 Agent·Decoder·Rule·FIM

01개념과 구성 요소

• Agent엔드포인트 로그·파일 변화·인벤터리·정책 검사 결과를 수집한다.
• ServerAgent를 관리하고 decoder·rule로 메시지를 분석한다.
• Indexer·Dashboard검색용 저장과 조사 화면을 담당하며 자료 종류·버전에 따라 전달 경로가 다를 수 있다.

02JSON 로그가 Wazuh 경보가 되는 순서

1. localfile 읽기Agent가 location과 log_format에 맞는 파일을 읽는다. 파일 접근권한과 회전 후 경로도 입력에 영향을 준다.
2. Manager 수신이벤트 연결로 자료가 Server에 도착한다. Agent 등록 성공은 이 자료의 도착 증명과 다르다.
3. 필드 추출메시지 형식에 따라 pre-decoding과 decoder가 헤더·JSON 필드 등을 해석한다.
4. Rule 평가decoded_as·field·상속·빈도 같은 조건을 평가하고 최종 rule ID·level·group을 결정한다.
5. 경보 저장·전달기록 임계값에 맞는 경보를 alerts에 남기고 해당 전달 경로로 indexer에 보낸다. 모든 수신 이벤트가 경보인 것은 아니다.
6. 조회·선택적 대응시간·권한·index 조건으로 조회하고 설정된 Active Response가 있을 때 별도 대상·만료 정책으로 실행한다.

03Agent·Server·Indexer·Dashboard

• 구성요소Agent는 엔드포인트 로그·FIM·인벤터리·설정 검사 결과를 수집하고 Server는 agent 관리와 decoder·rule 분석을 수행한다. Indexer는 검색을 위한 저장, Dashboard는 조사·관리 화면을 담당한다.
• 배치와 역할모든 구성요소가 한 호스트에 있는 학습 환경과 역할별로 나뉜 환경에서도 이 책임 구분은 유지된다.
• 자료별 전달4.x 경보와 선택적 archive는 Filebeat 전달 경로를 사용하지만 인벤터리·취약점 등 일부 데이터는 버전에 따라 indexer connector 경로를 사용한다. 모든 종류가 같은 파일과 전송기를 거친다고 단정하면 일부 화면의 실패를 잘못 진단한다.
• Active의 범위Agent가 Active라는 것은 연결 상태의 근거이며 원하는 로그·모듈이 실제 이벤트를 보내는 증거와는 다르다.

04등록·이벤트·API 경로를 나누어 읽기

• 포트와 목적기본 예의 agent 등록 1515/TCP, 이벤트 1514/TCP, server API 55000/TCP, indexer API 9200/TCP, dashboard HTTPS 443/TCP는 서로 다른 역할이다. 등록이 성공해 키를 받았어도 이후 이벤트 연결이나 파일 읽기가 실패할 수 있다.
• 변경된 구성실제 구성에서 변경된 포트·프로토콜도 고려해야 한다.
• Agent IDAgent ID·호스트 이름·IP는 동일한 개념이 아니다. DHCP나 NAT·클론 VM 때문에 주소와 표시 이름이 같거나 바뀔 수 있다.
• 시점별 자산사건을 추적할 때는 agent 고유 식별과 사건 시점의 자산 정보를 연결해야 하며, 단지 같은 host.name이라는 이유만으로 모든 이벤트를 한 자산으로 합치면 안 된다.

05localfile은 무엇을 어떤 문법으로 읽을지 정한다

• Location·Formatlocalfile의 location은 실제 파일 위치이고 log_format은 그 파일의 메시지 형식이다. JSON 한 줄을 syslog로 해석하거나 여러 줄 이벤트 경계를 잘못 설정하면 필요한 필드가 추출되지 않는다.
• 읽기 권한파일이 존재해도 agent 실행 계정이 읽지 못하거나 회전 후 새 파일에 접근하지 못하면 수집은 멈출 수 있다.
• 설정 조각아래는 가상 교육 JSON 로그를 읽는 부분 설정이다. 기존 ossec.conf를 이 조각으로 덮어쓰는 예가 아니다.
• 전달 단계파일에 문장이 기록됨→agent가 읽음→manager가 수신함→규칙이 일치함→indexer로 전달됨은 서로 다른 단계이다.

<localfile>
  <log_format>json</log_format>
  <location>/var/log/training/events.json</location>
</localfile>

교육 이벤트:
{"event":"training_auth","user":"learner","result":"failure"}

원리를 설명하는 가상 학습 예시입니다.

06Pre-decoding·Decoder·Rule

• Pre-decoding·DecoderSyslog 형태라면 pre-decoding이 시각·호스트·프로그램 이름 같은 앞부분을 읽을 수 있다. Decoder는 메시지 내용을 필드로 분해하고 Rule은 그 필드와 문맥이 특정 조건을 만족하는지 평가한다.
• 필드와 경보Decoder가 값을 뽑았다는 사실만으로 경보가 생기지 않으며, 다른 decoder가 먼저 일치하면 기대한 필드가 없을 수 있다.
• JSON DecoderJSON 형식은 기존 JSON decoder를 활용할 수 있다. 아래 규칙은 무해한 training_auth 이벤트 중 result=failure인 것만 찾는다.
• Rule 필드decoded_as는 적용 decoder 조건, field는 추출된 필드의 조건, level은 경보 수준, group은 분류 정보다. 실제 적용은 기존 규칙과 ID 중복·상속 관계까지 확인해야 한다.

<group name="training,">
  <rule id="100100" level="5">
    <decoded_as>json</decoded_as>
    <field name="event">^training_auth$</field>
    <field name="result">^failure$</field>
    <description>Training authentication failure</description>
  </rule>
</group>

사용자 규칙 범위의 학습 예입니다. 기존 정책과 충돌하지 않는 ID 선택 및 logtest가 필요합니다.

10문자열 Decoder의 캡처 그룹과 필드 순서

• Regex·Order구조가 없는 앱 로그에서는 program_name 또는 prematch로 메시지 종류를 좁히고 regex의 캡처 그룹을 order에 나열한 필드로 연결할 수 있다. 정규식 그룹 순서와 order가 어긋나면 user 자리에 result가 들어가는 식의 조용한 오류가 생긴다.
• 문법·누락부분 일치·공백·PID·누락 값과 사용하는 정규식 엔진의 문법도 결과를 바꾼다.
• 부모·자식 Decoder부모 decoder는 공통 헤더를 인식하고 자식이 세부 패턴을 추출하는 데 활용할 수 있다. 그러나 특정 프로그램 이름을 흉내 낸 메시지가 자동으로 신뢰되는 것은 아니다.
• 출처 신뢰수집 경로·발생 호스트·원본 보존이 함께 있어야 추출 필드를 실제 행위의 근거로 사용할 수 있다.

11wazuh-logtest가 증명하는 것

• Logtest 단계logtest에서는 한 원본 메시지를 넣고 pre-decoding, decoder 이름·추출 필드, 최종 rule ID·level·group을 단계별로 읽는다. 성공한 로그, 실패 로그, 필드가 빠진 로그를 비교하면 파서가 지원하는 범위가 보인다.
• 빈도 규칙빈도 상관 규칙은 여러 입력의 순서·시각·같은 필드 조건이 필요하므로 단일 줄 시험만으로 충분하지 않다.
• SSH 규칙 구분모든 SSH 인증 실패가 rule 5710으로 분류되는 것은 아니다. Wazuh 4.14 규칙의 invalid/illegal user 패턴과 일반 인증 실패 패턴은 구분되며 부모·자식 규칙에 따라 최종 ID가 달라진다.
• 전달 검증 한계입력 메시지의 실제 내용과 설치한 규칙 버전을 기준으로 읽는다. logtest 통과는 Filebeat나 Dashboard까지 전달되었다는 증명이 아니다.

1. 시험 메시지 입력wazuh-logtest에 실제 형식의 정상·실패·누락 필드 표본을 각각 넣는다.
2. 추출 단계 확인Pre-decoding과 decoder 이름·필드가 기대한 값인지 확인한다.
3. 최종 규칙 대조Rule ID·level·group을 비교하고 빈도 규칙은 필요한 입력 순서와 같은 주체 조건을 함께 재현한다.
4. 전달 단계 분리Logtest 결과와 실제 Agent→Server→Indexer→Dashboard의 전달 시험은 별도 근거로 남긴다.

12FIM 기준선·해시·속성·내용 차이

• 기준선·변화FIM은 감시 경로의 기준 상태를 만든 뒤 생성·수정·삭제·권한·해시 등 변화를 비교한다. 실시간 감시와 주기 검사는 관찰 시점과 지원 조건이 다르다.
• 내용 차이변경 탐지와 변경 전후 내용을 저장하는 report_changes는 별도 기능이며, 해시가 달라졌다는 사실만으로 어떤 줄이 바뀌었는지 알 수 없다.
• Nodiffnodiff는 비밀이 들어 있는 파일의 내용 차이 보관을 제외하는 설정이다. 정상 배포·패치도 파일을 바꾸므로 FIM 경보는 변경 사실을 알려 주며 악성 의도를 자동 증명하지 않는다.
• 변경 승인파일 경로·agent·시각·변경 속성과 승인된 변경 기록을 연결한다. 전체 루트를 감시하는 것보다 의미 있는 구성 파일부터 정의하면 잡음과 비용을 통제할 수 있다.

13alerts와 archives는 서로 다른 집합

• Alertsalerts.json에는 규칙과 기록 임계값에 맞는 경보가 저장된다. 수신 이벤트 모두가 경보가 되지 않으므로 경보 검색에서 결과가 없다고 미수집으로 확정할 수 없다.
• Archives선택적으로 logall_json을 켜면 원본 이벤트 archive를 남길 수 있고 indexer 검색을 원하면 해당 전달도 별도로 구성해야 한다.
• 보관 비용archive 보관은 디스크·개인정보·비밀 유입과 보존량을 늘린다. “Wazuh는 원본을 저장하지 않아 항상 가볍다”는 비교는 맞지 않는다.
• 검색 시각archive의 timestamp와 다른 제품의 @timestamp를 혼동하면 문서는 저장되어도 화면 시간 필터에서 빠질 수 있다.

14SCA·Inventory·취약점 결과의 의미

• SCA·InventorySCA는 정책이 정의한 설정 조건을 점검하고 인벤터리는 패키지·운영체제 등의 상태를 수집한다. 점수 하나는 적용 정책과 점검 가능 항목의 범위를 반영하며 시스템 전체의 안전을 수치 하나로 보증하지 않는다.
• 취약점 조건취약점 결과도 패키지 버전·배포판·벤더의 수정 정보와 실제 적용 조건을 읽어야 한다.
• 갱신 시점Agent 로그 탐지와 인벤터리 상태의 갱신 주기가 다르면 화면의 시각도 다를 수 있다. 패치 직후 이전 상태가 표시될 때 수집 시점과 재평가를 구분한다.
• 분류 메타데이터외부 취약점 번호·MITRE 기술·규정 매핑은 분류와 조사 경로를 돕는 메타데이터이지 공격 성공이나 규정 준수의 자동 증거는 아니다.

15Active Response와 저장 흐름의 끝

• Active ResponseActive Response는 경보에 따라 제한된 조치를 수행하는 별도 실행 경로다. 경보의 srcip를 잘못 파싱하면 엉뚱한 대상이 차단될 수 있으므로 규칙 정확성과 대응 대상의 의미가 선행한다.
• 대응 상태반복 동작·만료·예외·실패·복구 상태를 명시해야 경보가 늘어날 때 대응 시스템 자체가 장애를 만들지 않는다.
• 누락 추적화면에 이벤트가 없을 때는 source 파일→agent 수집→manager 분석→alerts/archive→전달 인증·권한→index→조회 기간을 따라간다. 한 단계가 정상이어도 이후 수집·분석·저장·조회 단계는 별도로 실패할 수 있다.