041. SIEM·로그 수집 — 대시보드 기초 — Discover와 검색 쿼리(DQL·KQL)

DQL Discover SIEM SIEM · 보안관제 Soc Wazuh 보안관제

SIEM · 보안관제 › A. SIEM 구조와 로그 수집 · 41/50편
학습 단계: 검색·대시보드·운영
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Wazuh 4.x 올인원 / Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

040. SIEM·로그 수집 — 수집 아키텍처 종합 점검 — 소스에서 저장까지

1. 개념

관제원이 하루 중 가장 많이 쓰는 화면은 Discover(이벤트 검색)입니다. 시간 범위를 정하고, 필드 조건으로 좁히고, 필요한 열만 골라 보는 것이 기본 동작입니다. 질의 문법은 OpenSearch Dashboards의 DQL과 Kibana의 KQL이 거의 같습니다.

Discover 검색 3요소
 ① 시간 범위   : Last 15 minutes / 절대 시각(사고 구간)
 ② 질의(DQL)   : 필드:값 조합
 ③ 표시 열     : agent.name · rule.id · rule.description · data.srcip

DQL 기본 문법
 rule.id:5716                         정확 일치
 rule.level >= 10                     범위
 agent.name:web01 and data.srcip:203.0.113.5
 rule.groups:authentication_failed and not data.srcip:192.168.56.*
 data.srcip:203.0.113.0/24            (ip 타입 필드일 때 CIDR)

핵심: 시간 범위가 틀리면 질의가 맞아도 결과가 0건

"검색 결과가 없다"는 문의의 상당수는 시간 범위나 선택한 인덱스 패턴 문제입니다. 질의를 고치기 전에 이 둘부터 확인합니다.

2. 왜 중요한가

모든 Alert 분석은 검색에서 시작합니다.
필드 기반 질의를 써야 정확하고 빠르게 범위를 좁힐 수 있습니다.
같은 질의를 저장·공유하면 팀의 분석 방식이 일관됩니다.

3. 핵심 명령어 / 설정

목적	DQL 예
특정 호스트 고위험	`agent.name:web01 and rule.level >= 10`
출발지 추적	`data.srcip:203.0.113.5`
그룹 기반	`rule.groups:authentication_failed`
제외	`not agent.name:siem01`
존재 여부	`data.srcip:*`

4. 실습 (실습 예시)

# 대시보드 질의와 같은 내용을 API로 확인 (실습 예시)
AUTH='admin:<비밀번호>'
curl -sk -u "$AUTH" -H 'Content-Type: application/json' "https://localhost:9200/wazuh-alerts-*/_search?size=3" -d '{
  "query": { "bool": { "filter": [
    { "term": { "agent.name": "web01" } },
    { "range": { "rule.level": { "gte": 10 } } },
    { "range": { "timestamp": { "gte": "now-24h" } } } ] } },
  "_source": ["timestamp","rule.id","rule.description","data.srcip"] }' | grep -E '"rule|srcip|timestamp"'

5. 정상 상태

질의: agent.name:web01 and rule.level >= 10 (Last 24 hours) → 3건
열: timestamp · rule.id · rule.description · data.srcip

시간 범위·인덱스 패턴이 맞고, 필드 질의로 원하는 이벤트만 좁혀지면 검색이 정상적으로 동작하는 상태입니다.

6. 이상 상태

질의: srcip:203.0.113.5 → 0건
실제 필드명: data.srcip (srcip 아님)

필드 경로를 잘못 쓰면 오류 없이 0건 → "공격 없음"으로 오판 위험
필드 목록(사이드바)에서 실제 경로를 확인하는 습관 필요
0건 결과는 질의·시간·인덱스를 다시 점검

7. 로그 분석 (분석 방법)

검색 결과 0건 점검 흐름입니다(가상의 예시).

[0건]
   ↓
① 시간 범위가 사건 시각을 포함하는가
② 인덱스 패턴이 맞는가(alerts vs archives)
③ 필드 경로가 정확한가(data.srcip)
④ 값 형식(대소문자·타입)이 맞는가
   ↓
 모두 맞는데 0건 → 실제로 이벤트 없음(또는 수집 공백: 020편)

실수	결과
짧은 시간 범위	사건 누락
잘못된 인덱스 패턴	전체 0건
필드 경로 오류	오류 없이 0건

alerts 인덱스에는 룰에 매칭된 이벤트만 있으므로, 룰에 안 걸린 원본까지 보려면 archives 인덱스 패턴을 선택해야 합니다(설정된 경우).

8. SOC 관제 포인트

자주 쓰는 질의를 저장 검색(Saved search)으로 공유합니다.
조사 메모에는 질의문·시간 범위·인덱스 패턴을 함께 기록합니다.
0건 결과는 점검 순서를 거친 뒤 결론을 냅니다.

9. 탐지 규칙

<!-- 실습 예시 룰: 적용 전 wazuh-logtest 및 테스트 환경 검증 필요 -->
<group name="local,siem_a,">
  <rule id="110400" level="3">
      <if_group>authentication_failed</if_group>
      <field name="srcip">\.</field>
      <description>출발지 필드가 있는 인증 실패(검색·필터 표준 예시용)</description>
    </rule>
</group>

대시보드 검색에서 자주 쓰는 조건(그룹+출발지 존재)을 룰로 옮겨 본 표시 룰입니다. 검색과 룰이 같은 필드를 쓴다는 점을 확인하는 용도입니다.

10. 대응 방법

초기 확인 — 시간 범위·인덱스 패턴·필드 경로를 확인합니다.
범위 확인 — 질의 결과의 호스트·출발지 범위를 확인합니다.
증거 확보 — 질의문과 결과를 조사 기록에 남깁니다.
차단/조치 — 필요하면 질의를 저장 검색으로 공유합니다.
재발 방지 — 표준 질의 모음을 팀 문서로 운영합니다.

11. 핵심 정리

요소	핵심
시간 범위	사건 구간 포함
인덱스	alerts / archives
질의	필드:값
0건	점검 후 결론
면접 포인트	"검색 0건은 공격 없음이 아니다 — 시간 범위, 인덱스, 필드 경로부터 의심한다"