📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 195편
이전 글: 194. Suricata · 다음 글: 196. 보안장비 Alert
Wazuh는 오픈소스 보안 플랫폼으로, 호스트에 설치하는 agent와 중앙 서버로 로그 수집·분석, 파일 무결성 감시, 취약점 탐지 등을 제공합니다. 호스트 기반(HIDS) 성격이 강하지만, 방화벽·스위치의 syslog와 Suricata 같은 네트워크 센서 로그를 받아 규칙으로 분석하면 네트워크 이벤트도 한 화면에서 볼 수 있습니다.
이 글은 Wazuh가 네트워크 이벤트를 받는 구조와 설정에 집중합니다. HIDS 개념은 06 영역 279. Host-based IDS에서 다룹니다.
| 구성 요소 | 역할 | 기본 포트(기본 설정 기준) |
|---|---|---|
| Wazuh server (manager) | agent·syslog 수신, 디코딩, 규칙 분석, Alert 생성 | 1514/TCP(agent 이벤트), 1515/TCP(agent 등록), 55000/TCP(API) |
| Wazuh indexer | Alert·이벤트 저장·검색 | 9200/TCP |
| Wazuh dashboard | 웹 조회 화면 | 443/TCP |
| Wazuh agent | 호스트 로그·파일 수집 후 manager로 전송 | — |
| syslog 수신(선택) | 네트워크 장비 로그 직접 수신 | 514/UDP 또는 TCP(설정 시) |
네트워크 이벤트가 Wazuh로 들어오는 두 경로입니다.
경로 A: 네트워크 장비 → syslog → Wazuh manager
[방화벽 / 스위치] ──syslog 514──→ [manager: remoted]
경로 B: 센서 파일 → agent → Wazuh manager
[Suricata 센서] eve.json ──[agent가 읽음]──1514/TCP──→ [manager: remoted]
↓
[analysisd] 디코더(필드 추출) → 규칙 매칭(레벨 부여)
↓ 레벨이 기준 이상이면
/var/ossec/logs/alerts/alerts.json → indexer → dashboard
디코더는 로그에서 출발지 IP, 목적지 포트 같은 필드를 뽑아내고, 규칙은 그 필드와 문구를 보고 Alert 여부와 레벨(0~15) 을 정합니다. JSON 형식 로그(Suricata EVE)는 JSON 디코더가 필드를 그대로 추출하므로 data.src_ip, data.alert.signature 같은 이름으로 조회할 수 있습니다. Wazuh 기본 룰셋에는 Suricata EVE용 규칙이 포함되어 있습니다(규칙 ID는 버전의 룰셋 파일에서 확인).
Wazuh 규칙 레벨은 0~15이며, 공식 문서의 분류를 요약하면 다음과 같습니다.
| 레벨 | 의미(요약) |
|---|---|
| 0 | 무시(Alert 생성 안 함) |
| 2~5 | 낮은 우선순위 알림, 정상·인가된 이벤트, 시스템·사용자 오류 |
| 6~9 | 관련도 낮은 공격, 처음 보는 이벤트, 비정상 출처 오류 |
| 10~11 | 다수 반복 오류, 무결성 검사 경고 |
| 12~15 | 높은 중요도 이벤트 ~ 심각한 공격 |
manager는 기본적으로 레벨 3 이상만 Alert로 기록합니다(ossec.conf의 log_alert_level). 레벨은 숫자가 클수록 심각하며, Suricata severity(1이 가장 높음)와 방향이 반대라는 점에 주의합니다(196. 보안장비 Alert).
관제에서 자주 보는 alerts.json 필드입니다.
| 필드 | 의미 |
|---|---|
rule.id, rule.level, rule.description | 일치한 규칙, 레벨, 설명 |
rule.groups | 규칙 분류(예: suricata, firewall) |
agent.name | 로그를 보낸 agent (syslog 직접 수신은 manager로 표시) |
location | 로그 출처(파일 경로 또는 syslog 송신 IP) |
data.* | 디코더가 추출한 필드 (예: data.src_ip, data.alert.signature_id) |
full_log | 원본 로그 (JSON 디코딩 로그는 없을 수 있음) |
실습 예시 — Wazuh manager가 설치된 VM에서 네트워크 장비 syslog를 받고, Suricata 센서의 agent가 eve.json을 보내도록 설정하는 흐름입니다. IP 대역은 예시(값은 환경마다 다름)입니다.
<!-- manager: /var/ossec/etc/ossec.conf — 관리망 장비의 syslog 수신 -->
<remote>
<connection>syslog</connection>
<port>514</port>
<protocol>udp</protocol>
<allowed-ips>10.10.99.0/24</allowed-ips>
</remote>
<!-- Suricata 센서의 agent: /var/ossec/etc/ossec.conf -->
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
# 설정 반영 (manager / agent 각각)
sudo systemctl restart wazuh-manager
sudo systemctl restart wazuh-agent
# manager 방화벽에서 syslog 포트 허용
sudo firewall-cmd --permanent --add-port=514/udp && sudo firewall-cmd --reload # Rocky
sudo ufw allow from 10.10.99.0/24 to any port 514 proto udp # Ubuntu
# 로그 한 줄이 어떤 디코더·규칙에 걸리는지 시험
sudo /var/ossec/bin/wazuh-logtest
# 수신된 Suricata 관련 Alert 확인
sudo jq -c 'select(.rule.groups[]? == "suricata") | [.rule.id, .rule.level, .data.src_ip, .data.alert.signature]' \
/var/ossec/logs/alerts/alerts.json | tail -5
📷 [실습 화면 삽입 위치]
wazuh-logtest에 방화벽 로그 한 줄을 입력했을 때 decoder 이름과 rule id·level이 출력되는 화면, 그리고 dashboard에서 rule.groups가 suricata인 이벤트 목록
allowed-ips로 송신 장비를 제한해야 합니다. 누구나 514번으로 로그를 보낼 수 있으면 가짜 로그 주입이 가능합니다./var/ossec/etc/rules/local_rules.xml 같은 사용자 규칙 파일에 작성합니다(사용자 규칙 ID는 100000 이상 권장). 기본 파일은 업그레이드 때 덮어써집니다.관제자가 확인할 질문
location과 agent.name으로 syslog 직접 수신인지 agent 파일 수집인지 구분했는가?data 아래에서 따로 확인했는가?allowed-ips 변경 중 무엇이 원인인가?Wazuh Alert (rule.level ≥ 기준)
↓ location / agent.name → 원천 장비 확인
↓ data.* 필드 → 원본 장비의 Alert 정보(sid, severity) 확인
↓ 원본 로그(eve.json, 방화벽 로그)에서 같은 시각·5-tuple 재확인
오탐 주의: 레벨 3 미만이나 레벨 0으로 설정된 이벤트는 Alert에 나타나지 않습니다. "Wazuh에 없다"가 "원본 로그에 없다"를 뜻하지 않으므로, 필요하면 원본 로그나 archives(logall 설정 시)를 직접 확인합니다.
<remote> 설정, allowed-ips 제한)로, Suricata는 agent의 <localfile> JSON 수집으로 연결합니다.rule.id, rule.level, location, data.* 필드로 Alert의 원천과 원본 정보를 확인합니다.wazuh-logtest로 디코더·규칙 동작을 시험하고, 사용자 규칙은 별도 파일에 작성합니다.