📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 188편
이전 글: 187. Firewall Log · 다음 글: 189. IPS 동작 구조
1. 개념
156. IDS란 무엇인가에서는 IDS 센서를 어디에 두고 트래픽을 어떻게 받는지(SPAN·TAP) 를 다뤘습니다. 이 글은 센서 안으로 들어온 패킷이 엔진 내부에서 어떤 단계를 거쳐 Alert가 되는지를 다룹니다. 이 구조를 알면 "Alert가 왜 안 떴는가", "왜 이 시간대에 탐지가 비었는가"를 장비 측면에서 설명할 수 있습니다.
Snort·Suricata 같은 네트워크 IDS 엔진은 이름과 구현은 달라도 대체로 같은 단계로 구성됩니다.
| 단계 | 하는 일 | 문제가 생기면 |
|---|---|---|
| 패킷 수집(Capture) | NIC에서 패킷을 받아 엔진으로 전달 | 드롭 발생 → 탐지 누락 |
| 디코딩(Decode) | Ethernet·VLAN·IP·TCP/UDP 헤더 해석 | 비정상 헤더는 디코더 이벤트로 기록 |
| 흐름·스트림(Flow/Stream) | 연결 단위로 묶고 TCP 세그먼트를 순서대로 재조립 | 재조립 공백 → 페이로드 탐지 실패 |
| 애플리케이션 계층(App-layer) | HTTP·DNS·TLS 등 프로토콜 식별·파싱 | 파싱 실패 시 프로토콜 기반 규칙 미적용 |
| 탐지(Detect) | 규칙과 비교 | 규칙 미적재·성능 부족 |
| 출력(Output) | Alert·메타데이터를 파일·syslog로 기록 | 디스크 가득 참 → 기록 중단 |
탐지 방식(Signature·Anomaly)의 개념은 06 영역 280. Signature Detection·281. Anomaly Detection에서 다룹니다.
2. 동작 원리
[모니터링 NIC] ─ 복사 트래픽 수신
↓ 패킷 수집 (libpcap / AF_PACKET / PF_RING / DPDK 등, 엔진·빌드에 따라)
↓ 디코딩: VLAN 태그 제거, IP 단편 재조합, 헤더 검증
↓ 흐름 테이블 조회: 5-tuple → flow 생성·갱신
↓ TCP 스트림 재조립 → 애플리케이션 계층 프로토콜 식별 (포트와 무관하게 내용으로)
↓ 탐지 엔진: 사전 필터(다중 패턴 매칭) → 후보 규칙만 전체 조건 검사
↓ 출력: Alert, 프로토콜 로그, 통계주목할 점은 두 가지입니다.
첫째, 탐지는 패킷 하나가 아니라 흐름과 재조립된 스트림 위에서 이루어집니다. 공격 문자열이 두 TCP 세그먼트에 나뉘어 와도 재조립 후에는 한 덩어리로 검사됩니다. 반대로 센서가 한쪽 방향 패킷만 받거나 중간 패킷을 놓치면 재조립이 불완전해집니다.
둘째, 애플리케이션 계층 식별은 포트가 아닌 내용 기반입니다. 8080번이나 비표준 포트의 HTTP도 HTTP로 인식되어 HTTP 규칙이 적용됩니다(엔진 설정에 따라 다름).
3. 주요 특징
고성능 엔진은 위 단계를 여러 스레드로 나누어 처리합니다. Suricata를 예로 들면 runmode 설정에 따라 구조가 달라집니다.
| runmode | 구조 | 특징 |
|---|---|---|
| workers | 스레드 하나가 수집~출력을 모두 처리, 스레드 여러 개 병렬 | AF_PACKET 등에서 권장되는 경우가 많음 |
| autofp | 수집 스레드와 처리 스레드를 분리, 흐름 단위로 분배 | pcap 파일 처리 등에 사용 |
| single | 스레드 하나 | 테스트·디버깅용 |
엔진이 내부 상태를 알려 주는 통계 값은 탐지 품질을 판단하는 근거입니다.
| 통계 항목(Suricata 예) | 의미 | 관제 해석 |
|---|---|---|
capture.kernel_packets | 커널이 엔진에 넘긴 패킷 수 | 0이면 트래픽 미수신(SPAN 문제 등) |
capture.kernel_drops | 엔진이 처리 못 해 버린 패킷 수 | 증가하면 그 구간 탐지 누락 가능 |
tcp.reassembly_gap | 재조립 중 빠진 구간 수 | 한쪽 방향 수신·드롭 의심 |
detect.alert | 생성된 Alert 수 | 급증·급감 모두 확인 대상 |
항목 이름은 버전에 따라 바뀔 수 있으므로 사용하는 버전의 stats.log나 EVE stats 이벤트로 확인합니다.
4. 예시
실습 예시 — Suricata가 설치된 센서 VM에서 내부 구조를 확인하는 명령입니다(설치는 194. Suricata 참고). 인터페이스 이름은 예시(값은 환경마다 다름)입니다.
# 빌드 정보: 지원하는 패킷 수집 방식(AF_PACKET, PF_RING, DPDK 등)과 기능 확인
suricata --build-info | grep -iE "af_packet|pf_ring|dpdk|hyperscan"
# 지원 runmode 목록
suricata --list-runmodes
# 실행 중인 스레드 확인 (스레드 이름은 버전에 따라 다름. 예: W#01-ens33, FM#01)
ps -T -p "$(pidof suricata)"
# 수신량·드롭 추이 확인
sudo grep -E "capture.kernel_(packets|drops)" /var/log/suricata/stats.log | tail -4NIC의 오프로딩 기능(GRO·LRO)이 켜져 있으면 커널이 여러 패킷을 하나로 합쳐 엔진에 넘겨, 재조립과 탐지가 왜곡될 수 있습니다. Suricata 문서도 모니터링 인터페이스에서 이 기능을 끄도록 안내합니다(Rocky·Ubuntu 공통, ethtool 패키지 필요).
sudo ethtool -k ens33 | grep -E "generic-receive-offload|large-receive-offload"
sudo ethtool -K ens33 gro off lro off # 지원하지 않는 항목은 오류가 날 수 있음📷 [실습 화면 삽입 위치]
ps -T로 확인한 Suricata 스레드 목록과,stats.log에서capture.kernel_packets가 증가하고capture.kernel_drops가 0으로 유지되는 화면
5. 보안 관점
- 공격자는 엔진 구조의 빈틈을 노릴 수 있습니다. 단편화·세그먼트 중첩·비정상 순서로 엔진과 실제 목적지 호스트가 다르게 재조립하도록 만드는 회피(Evasion) 기법이 알려져 있으며, 엔진은 대상 OS별 재조립 정책 설정으로 이를 줄입니다.
- 트래픽이 처리 성능을 넘으면 드롭이 발생하고, 드롭된 패킷은 검사되지 않습니다. 대량 트래픽이 탐지 공백을 만드는 이유입니다.
- 애플리케이션 계층 파서는 복잡한 코드이므로 엔진 자체의 취약점도 보안 업데이트 대상입니다.
- 암호화 트래픽은 재조립까지 되어도 내용 검사가 불가능해, TLS 메타데이터 수준의 탐지만 가능합니다.
6. SOC 관점
관제자가 확인할 질문
- 사건 시각 센서의
kernel_drops가 증가했는가? 증가했다면 "Alert 없음"을 "공격 없음"으로 해석할 수 없습니다. - 센서가 양방향 트래픽을 모두 받고 있는가? 한쪽만 받으면 재조립 공백과 애플리케이션 계층 파싱 실패가 늘어납니다.
- 디코더·스트림 관련 이벤트(엔진이 비정상 패킷 구조를 기록한 이벤트)가 같은 흐름에서 함께 발생했는가?
Alert 기대했는데 없음
↓ 센서 수신량(kernel_packets) 확인 → 0이면 SPAN·NIC 문제
↓ 드롭(kernel_drops)·재조립 공백 확인 → 증가 시 성능·수집 문제
↓ 규칙 적재 여부 확인 (192편)
↓ 그래도 없으면 탐지 규칙 부재 → 규칙 보완 검토오탐 주의: 한쪽 방향 수신이나 오프로딩 문제로 발생하는 스트림 이상 이벤트는 공격이 아니라 센서 구성 문제인 경우가 많습니다. Alert 자체의 분석은 06 영역 283. IDS Alert에서 다룹니다.
7. 핵심 정리
- IDS 엔진은 수집 → 디코딩 → 흐름·스트림 재조립 → 애플리케이션 계층 파싱 → 탐지 → 출력 단계로 동작합니다.
- 탐지는 재조립된 스트림 위에서 이루어지며, 프로토콜 식별은 포트가 아닌 내용 기반입니다.
- Suricata는 runmode(workers, autofp, single)에 따라 스레드 구조가 달라집니다.
capture.kernel_drops, 재조립 공백 같은 엔진 통계는 탐지 공백을 판단하는 근거입니다.- 모니터링 NIC의 GRO·LRO 오프로딩은 탐지를 왜곡할 수 있어 끄는 것이 권장됩니다.
