196. 보안장비 Alert

Об этом предложении

📚 네트워크 · 패킷 분석 › 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가 없을 때는 관찰 범위 밖인지 전달 누락인지를 구분해야 합니다.