📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 196편
이전 글: 195. Wazuh 네트워크 이벤트 · 다음 글: 197. 네트워크 보안 아키텍처
1. 개념
보안장비 Alert는 방화벽, IDS/IPS, WAF, 서버 보안 agent 같은 장비가 "주의가 필요한 이벤트"라고 판단해 생성한 기록입니다. 관제자는 대부분 SIEM 화면에서 Alert를 보지만, 그 Alert는 장비에서 생성 → 전송 → 수집 → 정규화 → 표시라는 여러 단계를 거친 결과입니다.
이 글은 Alert가 이동하는 장비·전달 경로 관점을 다룹니다. Alert 내용의 해석과 정탐·오탐 판단은 06 영역 283. IDS Alert, 284. IPS Alert, 295. IDS Alert의 Source/Destination 분석에서 다룹니다.
| 장비 | Alert 예 | 대표 전달 방식 |
|---|---|---|
| 방화벽 | 정책 차단, DoS 임계치 초과, 관리자 정책 변경 | syslog |
| IDS/IPS (Suricata 등) | 규칙 일치 Alert, 차단 이벤트 | 파일(eve.json) → 수집 agent, syslog |
| WAF | 웹 공격 패턴 차단 | syslog, API |
| HIDS/서버 agent (Wazuh 등) | 로그 규칙 일치, 파일 변경 | agent 전용 프로토콜 |
| 네트워크 장비 | 포트 보안 위반, 인증 실패 | syslog, SNMP Trap |
2. 동작 원리
[장비] 탐지 조건 일치 → Alert 생성 (장비 고유 형식·심각도)
↓ 전달: 파일 기록 / syslog 송신 / API 제공 / SNMP Trap
[수집기] Filebeat, Wazuh agent, rsyslog, Logstash 등
↓ 파싱·정규화: 필드 이름과 심각도 척도를 공통 형식으로 변환
[SIEM / 인덱서] 저장, 상관 분석, 중복 묶음
↓
[관제 화면] 우선순위별 Alert 목록 → 관제자 분석각 단계에서 Alert가 바뀌거나 사라질 수 있습니다. 장비는 생성했지만 UDP syslog가 유실될 수 있고, 파서가 형식 변경을 처리하지 못하면 필드가 비거나 이벤트가 버려질 수 있습니다. SIEM 규칙이 같은 Alert를 묶으면 관제 화면에는 한 건으로 보입니다.
3. 주요 특징
장비마다 심각도 척도가 달라 숫자만 보고 비교하면 안 됩니다.
| 출처 | 척도 | 가장 심각한 값 |
|---|---|---|
| Syslog severity (RFC 5424) | 0(Emergency) ~ 7(Debug) | 0 |
Suricata alert.severity | 규칙 분류의 우선순위 값 (일반적으로 1~3, 규칙에 따라 더 큰 값 가능) | 1 |
| Snort Priority | 분류 우선순위 (일반적으로 1~4) | 1 |
Wazuh rule.level | 0 ~ 15 | 15 |
필드 이름도 장비마다 다릅니다. 그래서 SIEM은 공통 이름으로 정규화합니다. 아래는 Elastic Common Schema(ECS)를 예로 든 대응입니다.
| 의미 | Suricata EVE | Linux 방화벽 커널 로그 | 정규화 예(ECS) |
|---|---|---|---|
| 출발지 IP | src_ip | SRC= | source.ip |
| 목적지 IP | dest_ip | DST= | destination.ip |
| 목적지 포트 | dest_port | DPT= | destination.port |
| 탐지 규칙 | alert.signature_id | 로그 접두어(--log-prefix) | rule.id 등 |
4. 예시
실습 예시 — 같은 시각, 같은 출발지에서 발생한 세 장비의 Alert가 원래 어떤 모양이고, 비교를 위해 어떻게 공통 필드로 정리하는지 보여 주는 형식 예시(값은 환경마다 다름)입니다.
# 형식 예시 — (1) Suricata eve.json (일부 필드)
{"timestamp":"2026-09-30T10:15:32.104512+0900","event_type":"alert","src_ip":"192.168.10.50","dest_ip":"10.10.30.10",
"dest_port":22,"proto":"TCP","alert":{"action":"allowed","signature_id":1000002,"signature":"LOCAL SSH connection attempts","severity":2}}
# 형식 예시 — (2) Linux 방화벽 커널 로그 (187편 형식)
Sep 30 10:15:33 lab-fw01 kernel: FW-SSH-DROP IN=ens37 OUT=ens38 SRC=192.168.10.50 DST=10.10.30.10 PROTO=TCP SPT=51522 DPT=22 SYN
# 형식 예시 — (3) Wazuh alerts.json (일부 필드)
{"timestamp":"2026-09-30T10:15:34.201+0900","rule":{"id":"100010","level":10,"description":"LOCAL: repeated SSH blocks"},
"location":"10.10.99.1","data":{"srcip":"192.168.10.50","dstport":"22"}}세 로그를 공통 필드로 정리하면 한 표로 비교할 수 있습니다.
# Suricata Alert를 "시각 출발지 목적지 포트 출처 규칙" 형식으로 변환
sudo jq -r 'select(.event_type=="alert") | [.timestamp, .src_ip, .dest_ip, .dest_port, "suricata", .alert.signature_id] | @tsv' \
/var/log/suricata/eve.json | tail -3실제 운영에서는 이 변환을 Logstash·Wazuh 디코더·SIEM 파서가 담당합니다. 실습에서는 장비별로 이런 변환 스크립트를 만들어 보면 필드 대응 관계를 익히는 데 도움이 됩니다.
📷 [실습 화면 삽입 위치] SIEM(또는 Kibana·Wazuh dashboard)에서 같은 출발지 IP로 검색했을 때 Suricata·방화벽·Wazuh 이벤트가 시간순으로 함께 표시되는 화면
5. 보안 관점
- Alert 전달 경로도 공격 표면입니다. 공격자가 장비 로그 설정을 끄거나, syslog 수집 경로를 방해하거나, 가짜 로그를 주입할 수 있습니다. 송신 장비 제한과 전송 암호화를 검토합니다.
- 장비 시각이 서로 다르면 정규화 후에도 순서가 뒤바뀝니다. 모든 장비와 수집기는 같은 NTP 기준을 사용해야 합니다.
- Alert가 너무 많으면 관제자가 중요한 Alert를 놓칩니다(Alert 피로). 장비 단계의 튜닝과 SIEM 단계의 묶음이 함께 필요합니다.
- 정규화 과정에서 원본 필드가 버려질 수 있으므로, 원본 로그 보관 정책을 따로 둡니다.
6. SOC 관점
관제자가 확인할 질문
- 이 Alert의 심각도는 어느 척도의 값인가? 장비 원래 값인가, SIEM이 재계산한 값인가?
- 같은 사건을 다른 장비도 보았는가? 보았어야 하는데 없다면, 그 장비의 전달 경로(파일 수집·syslog)에 문제가 없는가?
- SIEM에서 묶인 Alert라면, 원래 몇 건이었고 첫 발생과 마지막 발생 시각은 언제인가?
SIEM Alert 확인
↓ 원천 장비·원본 심각도 확인 (척도 방향 주의)
↓ 같은 5-tuple·시각의 다른 장비 이벤트 검색
있음 → 장비별 판정(허용/차단/탐지) 비교 → 타임라인 구성
없음 → 관찰 범위 밖인지, 전달 누락인지 구분오탐 주의: 한 사건이 여러 장비에서 Alert를 만들면 "여러 건의 공격"처럼 보입니다. 5-tuple과 시각으로 묶어 하나의 사건으로 판단합니다. 장비 간 연계 방법은 06 영역 296. Alert와 Firewall Log 연계·297. IDS Alert와 Packet 연계에서 다룹니다.
7. 핵심 정리
- 보안장비 Alert는 생성 → 전달 → 수집 → 정규화 → 표시 단계를 거치며, 각 단계에서 변형·유실될 수 있습니다.
- 전달 방식은 파일 수집, syslog, API, SNMP Trap 등 장비마다 다릅니다.
- 심각도 척도는 장비마다 다르며, syslog·Suricata·Snort는 작은 값이, Wazuh는 큰 값이 더 심각합니다.
- SIEM은 장비별 필드를 공통 이름으로 정규화해 비교·상관 분석을 가능하게 합니다.
- Alert가 없을 때는 관찰 범위 밖인지 전달 누락인지를 구분해야 합니다.
