191. Anomaly Detection

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

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 191편 이전 글: 190. Signature Detection · 다음 글: 192. IDS Rule 1. 개념 Anomaly Detection(이상 탐지) 은 평소 상태(기준선, Baseline)를 정의하고, 그와 크게 다른 트래픽을 찾아내는 방식입니다. 알려진 패턴이 없어도 "평소와 다르다"는 이유로 탐지할 수 있다는 점에서 190. Signature Detection 을 보완합니다. 탐지 원리와 오탐 특성은 06 영역 281. Anomaly Detection 에서 다룹니다. 장비 관점에서 이상 탐지의 핵심 질문은 "기준선을 만들 데이터를 어느 장비에서, 어떤 형식으로 모으는가" 입니다. 데이터 원천 제공 장비 담긴 정보 NetFlow v5/v9, IPFIX 라우터, L3 스위치, 방화벽, Linux 수출기 흐름별 주소·포트·프로토콜·패킷 수·바이트 수·시각 sFlow 스위치(샘플링 방식) 일정 비율로 표본 추출한 패킷 헤더와 카운터 IDS 흐름 기록 Suricata flow · netflow 이벤트, Zeek conn.log 흐름 요약 + 애플리케이션 프로토콜 정보 장비 카운터 SNMP 인터페이스 카운터 인터페이스별 트래픽 총량 2. 동작 원리 흐름(Flow) 데이터 기반 이상 탐지의 일반적인 구조입니다. [라우터 / 스위치 / 방화벽] 흐름 기록 생성 (Exporter) ↓ UDP로 전송 (NetFlow 관례 2055 / IPFIX 4739 / sFlow 6343) [Flow Collector] 수신·저장 ↓ 시간대·호스트·포트별 집계 [분석 엔진 / SIEM] 기준선 계산 (예: 요일·시간대별 평균과 편차) ↓ 현재 값과 비교 [이상 이벤트] "평소 대비 N배", "처음 보는 목적지", "새벽 시간대 대량 전송" 흐름 기록은 패킷 내용을 담지 않고 누가·누구와·얼마나·언제 통신했는지만 요약합니다. 그래서 저장 부담이 작고 암호화 트래픽에도 적용할 수 있지만, 무엇을 주고받았는지는 알 수 없습니다. 방화벽·IPS에 내장된 임계치 기반 보호 기능 (초당 SYN 수, 출발지당 세션 수 제한 등)도 넓은 의미의 이상 탐지입니다. 기준선을 자동 학습하지 않고 관리자가 정한 숫자를 기준으로 삼는다는 점이 다릅니다. 3. 주요 특징 같은 "anomaly"라는 단어가 다른 뜻으로 쓰이는 경우가 있어 구분이 필요합니다. 용어 의미 예 행위 기반 이상 탐지 기준선 대비 트래픽 양·패턴의 이상 평소 1GB이던 야간 외부 전송이 30GB 프로토콜 이상(Protocol Anomaly) 규격에 맞지 않는 패킷·메시지 잘못된 헤더 길이, HTTP 파싱 오류 Suricata anomaly 이벤트 엔진의 디코더·스트림·앱 계층이 기록한 프로토콜 이상 EVE event_type: anomaly Suricata의 anomaly 이벤트는 프로토콜 이상 을 기록한 것이지, 기준선 대비 행위 이상을 계산한 결과가 아닙니다. 흐름 데이터 수집 방식별 특징입니다. 방식 장점 한계 NetFlow/IPFIX 모든 흐름 기록(장비 설정에 따라 샘플링 가능), 표준 형식 장비 부하, 흐름 종료·타임아웃 후에 기록됨 sFlow 스위치 부하가 적음, 대용량 망에 적합 샘플링이라 소량 통신은 누락될 수 있음 IDS 흐름 이벤트 애플리케이션 프로토콜 정보 포함 센서가 보는 구간만 기록 4. 예시 실습 예시 — Suricata 센서의 EVE flow 이벤트를 집계해 기준선 비교의 기초 데이터를 만드는 방법입니다. flow 이벤트는 흐름이 끝나거나 타임아웃될 때 기록되며, 필드는 버전에 따라 조금 다를 수 있습니다. 값은 예시(값은 환경마다 다름)입니다. # 출발지별로 서로 다른 목적지 포트 수 집계 (많은 포트에 접근한 호스트 확인) sudo jq -r 'select(.event_type=="flow") | "\(.src_ip) \(.dest_port)"' /var/log/suricata/eve.json \ | sort -u | awk '{print $1}' | sort | uniq -c | sort -rn | head # 출발지별 외부로 보낸 바이트 합계 (flow.bytes_toserver) sudo jq -r 'select(.event_type=="flow") | "\(.src_ip) \(.flow.bytes_toserver)"' /var/log/suricata/eve.json \ | awk '{s[$1]+=$2} END {for (h in s) print s[h], h}' | sort -rn | head # 형식 예시 (값은 환경마다 다름) — EVE flow 이벤트 일부 {"timestamp":"2026-09-30T02:14:07.512345+0900","event_type":"flow","src_ip":"192.168.10.50", "src_port":51514,"dest_ip":"203.0.113.80","dest_port":443,"proto":"TCP","app_proto":"tls", "flow":{"pkts_toserver":5230,"pkts_toclient":2011,"bytes_toserver":7340120, "bytes_toclient":120334,"state":"closed","reason":"timeout"}} 같은 집계를 여러 날 반복해 시간대별 평균을 저장해 두면, 그 값이 곧 간단한 기준선이 됩니다. 실제 운영 환경에서는 SIEM이나 전용 NDR 제품이 이 계산을 자동화합니다. 📷 [실습 화면 삽입 위치] jq·awk 집계 결과에서 출발지별 목적지 포트 수와 전송 바이트 순위가 출력된 화면 5. 보안 관점 이상 탐지는 새로운 공격, 내부 확산, 대량 유출 처럼 시그니처가 없는 상황에서 단서를 줍니다. 기준선을 만드는 기간에 이미 침해가 있었다면, 비정상이 "정상"으로 학습될 수 있습니다. 공격자가 평소 업무 시간·평소 목적지·적은 양으로 천천히 움직이면 기준선 안에 숨을 수 있습니다. 흐름 수출 설정이 빠진 인터페이스나 샘플링 비율이 큰 구간은 이상 탐지의 사각지대입니다. 6. SOC 관점 관제자가 확인할 질문 이 이상 이벤트의 근거 데이터는 어느 장비의 어떤 흐름 기록인가? 샘플링된 데이터인가? 평소와 다른 원인이 업무 변화(백업, 배포, 신규 서비스)로 설명되는가? 같은 호스트에 시그니처 Alert, 방화벽 차단, 엔드포인트 이벤트가 함께 있는가? 이상 이벤트 (예: 새벽 외부 전송량 급증) ↓ 흐름 기록으로 목적지·포트·지속 시간 확인 ↓ 변경 관리·작업 일정과 대조 설명됨 → 기준선 예외 등록 검토 설명 안 됨 → IDS·프록시·호스트 로그로 내용 확인 → 에스컬레이션 오탐 주의 : 이상 탐지는 "다르다"만 알려 줄 뿐 "악성이다"를 말하지 않습니다. 정기 백업, 월말 정산, 패치 배포처럼 주기적인 대량 트래픽을 먼저 확인합니다. 비정상 트래픽 판단 기준은 06 영역 294. 비정상 Network Traffic 탐지 에서 다룹니다. 7. 핵심 정리 이상 탐지는 기준선을 정하고 그와 다른 트래픽을 찾는 방식으로, 시그니처 탐지를 보완합니다. 장비 관점의 핵심은 기준선 데이터 수집이며, NetFlow·IPFIX·sFlow, IDS 흐름 이벤트, SNMP 카운터가 대표적입니다. 흐름 기록은 내용 없이 주소·포트·양·시각을 요약해 암호화 트래픽에도 적용할 수 있습니다. Suricata anomaly 이벤트는 프로토콜 이상 기록이며, 행위 기반 이상 탐지와 구분해야 합니다. 이상 이벤트는 업무 변화 여부와 다른 로그를 함께 확인해 판단합니다.