📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 239편
이전 글: 238. Suricata Scan 탐지 · 다음 글: 240. Source IP 분석
1. 개념
Wazuh는 에이전트가 수집한 호스트 로그(인증 로그, 방화벽 로그, 웹 로그 등)와 외부 장비 로그(Suricata EVE 등)를 매니저에서 디코더로 해석하고 규칙으로 판정해 Alert를 만드는 HIDS·SIEM 계열 플랫폼입니다. Wazuh의 네트워크 이벤트 수집 구조는 195. Wazuh 네트워크 이벤트에서 다뤘고, 이 글은 정찰·대입 관련 Wazuh Alert를 받았을 때 읽는 방법에 집중합니다.
스캔 징후 분석에서 Wazuh Alert는 주로 세 출처에서 옵니다.
| 출처 | Alert가 말해 주는 것 | 대표 규칙 그룹(예) |
|---|---|---|
| sshd 인증 로그 | 존재하지 않는 계정 시도, 인증 실패 반복, 성공 | sshd, authentication_failed, authentication_success |
| 호스트 방화벽 로그 | 같은 출발지의 차단 반복 | firewall 계열 |
| Suricata EVE 연동 | IDS Alert를 Wazuh 규칙으로 재판정 | ids, suricata |
규칙 그룹 이름과 규칙 ID는 Wazuh 버전과 규칙 파일에 따라 다르므로, 대시보드나 규칙 파일에서 실제 값을 확인합니다.
2. 동작 원리
원본 로그 (예: /var/log/secure 의 sshd 메시지)
↓ 에이전트 수집 → 매니저 전송
[디코더] 프로그램명·출발지 IP·계정 등 필드 추출 (decoder.name, data.srcip ...)
↓
[단일 규칙] "sshd: 인증 실패" 같은 개별 판정 (낮은 레벨)
↓ 같은 조건이 시간 창 안에 반복
[빈도 규칙] frequency·timeframe 조건 충족 → "여러 번 인증 실패" 등 (높은 레벨)
↓
Alert 저장 (매니저의 alerts.json 등) → 대시보드 표시
↓ (설정 시) 능동 대응: 출발지 차단 스크립트 실행빈도 규칙이 핵심입니다. 인증 실패 한 건은 낮은 레벨로 기록되고, 같은 출발지에서 정해진 시간 안에 여러 번 반복되면 상위 규칙이 더 높은 레벨의 Alert를 만듭니다. 따라서 대시보드에서 높은 레벨 Alert 한 건 뒤에는 낮은 레벨 Alert 여러 건이 있습니다.
3. 주요 특징
Alert JSON에서 먼저 볼 필드입니다(버전에 따라 일부 다름).
| 필드 | 의미 | 분석 용도 |
|---|---|---|
rule.id / rule.description | 일치한 규칙 | 단일 규칙인지 빈도 규칙인지 확인 |
rule.level | 0~15 심각도 | 우선순위(높을수록 심각) |
rule.groups | 규칙 분류 | 같은 유형 묶어서 검색 |
rule.firedtimes | 해당 규칙 발생 횟수 | 반복 규모 참고 |
agent.name / agent.ip | 로그를 보낸 호스트 | 대상 서버 식별 |
data.srcip / data.srcuser | 디코더가 뽑은 출발지·계정 | 출발지 집계, 계정 분포 |
full_log | 원본 로그 한 줄 | 해석 검증 |
location | 수집 로그 경로 | 출처 확인 |
- sshd 관련 기본 규칙에는 존재하지 않는 계정 시도, 인증 실패, 반복 실패(빈도 규칙), 인증 성공 등이 있습니다. 예를 들어 5710·5712·5716·5720·5715 계열 ID가 알려져 있지만, ID와 의미는 설치된 버전의 규칙 파일로 확인합니다.
full_log를 반드시 봅니다. 디코더가 필드를 잘못 뽑거나 비슷한 메시지를 같은 규칙으로 묶는 경우가 있어, 판단은 원본 문장으로 검증합니다.
4. 예시
Wazuh Alert 형식 예시입니다(값은 환경마다 다름, 일부 필드 생략, 규칙 ID는 예시).
{"timestamp":"2026-09-30T03:10:16.000+0900",
"rule":{"level":10,"description":"sshd: brute force trying to get access to the system.","id":"5712","firedtimes":1,
"groups":["syslog","sshd","authentication_failures"]},
"agent":{"id":"003","name":"web01","ip":"192.168.20.10"},
"data":{"srcip":"203.0.113.70","srcuser":"test"},
"full_log":"Sep 30 03:10:15 web01 sshd[4115]: Invalid user test from 203.0.113.70 port 51230",
"location":"/var/log/secure"}실습 예시 — 본인 소유 실습 Wazuh 매니저에서 출발지별 레벨·규칙 분포와 성공 로그인 여부를 확인하는 방어 측 명령입니다(경로는 기본 설치 기준).
# 출발지 203.0.113.70 관련 Alert의 규칙별 건수
sudo jq -r 'select(.data.srcip=="203.0.113.70") | "\(.rule.level) \(.rule.id) \(.rule.description)"' \
/var/ossec/logs/alerts/alerts.json | sort | uniq -c | sort -rn
# 같은 출발지의 인증 성공 그룹 Alert
sudo jq -r 'select(.data.srcip=="203.0.113.70" and any(.rule.groups[]; .=="authentication_success"))
| "\(.timestamp) \(.agent.name) \(.data.dstuser // .data.srcuser)"' /var/ossec/logs/alerts/alerts.json분석 방법 — 첫 명령으로 단일 실패 규칙과 빈도 규칙의 건수를 나눠 보고, 둘째 명령으로 실패 뒤 성공이 있는지 확인합니다. 계정 필드 이름은 규칙·디코더에 따라 다를 수 있어 full_log로 검증합니다.
5. 보안 관점
- Wazuh는 암호화된 서비스의 성공·실패(SSH 로그인 결과)를 볼 수 있는 호스트 기반 자료이므로, 네트워크 IDS가 볼 수 없는 부분을 채웁니다.
- 능동 대응(출발지 차단)은 반복 대입을 빠르게 끊지만, 차단 시간이 끝나면 재개될 수 있고 공유 IP를 막을 수도 있습니다. 차단 기록도 Alert로 남으므로 함께 확인합니다.
- 에이전트가 설치되지 않은 서버, 수집 경로에서 빠진 로그는 Alert가 없습니다. Alert 없음 = 공격 없음이 아닙니다.
6. SOC 관점
관제자가 확인할 질문
- 이 Alert는 단일 규칙인가, 빈도 규칙인가? 뒤에 있는 낮은 레벨 Alert는 몇 건인가?
full_log원문과 디코더 필드(data.srcip, 계정)가 일치하는가?- 같은 출발지의 인증 성공 Alert가 있는가? 다른 에이전트(서버)에도 같은 출발지가 보이는가?
- 능동 대응이 동작했는가? 차단 시간과 해제 이후 재발 여부는?
Wazuh Alert (높은 레벨)
↓ full_log로 원문 검증
↓ 같은 srcip의 낮은 레벨 Alert·다른 agent 검색
↓ 인증 성공 그룹 검색
성공 없음 → 차단·기록 / 성공 있음 → 계정 탈취 의심, 에스컬레이션오탐 주의: 모니터링 계정의 잘못된 비밀번호, 배포 도구의 키 오류는 같은 빈도 규칙을 반복 발생시킵니다. 출발지가 내부 고정 서버라면 설정 오류부터 확인합니다. sshd 로그 해석은 232. SSH Brute Force, 호스트 기반 탐지 구조는 279. Host-based IDS를 참고합니다.
7. 핵심 정리
- Wazuh는 호스트·장비 로그를 디코더로 해석하고 규칙으로 판정해 Alert를 만듭니다.
- 빈도 규칙 Alert 한 건 뒤에는 낮은 레벨의 개별 Alert 여러 건이 있습니다.
- rule.id·level·groups, agent, data.srcip, full_log, location이 먼저 볼 필드입니다.
- 규칙 ID와 그룹 이름은 버전별로 확인하고, 판단은 full_log 원문으로 검증합니다.
- 가장 중요한 확인은 같은 출발지의 인증 성공 Alert 존재 여부입니다.
