📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 297편
이전 글: 296. Alert와 Firewall Log 연계 · 다음 글: 298. Alert에서 IOC 추출
1. 개념
IDS Alert와 Packet 연계는 Alert를 만든 실제 패킷(또는 스트림) 을 찾아, 규칙의 조건이 정말로 공격 맥락에서 일치했는지 눈으로 확인하는 것입니다. Alert는 "규칙이 일치했다"는 요약일 뿐이고, 패킷은 무엇이 오갔는가에 대한 원본 증거입니다. Wireshark 사용법과 스트림 추적은 03 영역 134. Follow TCP Stream, 148. pcap 증거 보존과 해시 검증에서 다뤘습니다.
패킷을 확보하는 방법은 환경에 따라 다릅니다.
| 방법 | 내용 | 한계 |
|---|---|---|
| Alert에 포함 | Suricata EVE Alert의 payload·packet(설정 시, base64) | 일치한 패킷 하나 수준, 앞뒤 맥락 부족 |
| 엔진의 pcap 기록 | Suricata pcap-log, Snort 3 log_pcap 등 | 저장 용량 부담, 보관 기간 짧음 |
| 전체 패킷 수집(FPC) | 별도 수집 시스템이 구간 트래픽을 계속 저장 | 용량·비용, 개인정보 관리 |
| 사후 수집 | Alert 이후 tcpdump로 같은 조건 캡처 | 이미 지나간 트래픽은 없음 |
2. 동작 원리
Alert에서 패킷을 찾아 검증하는 흐름입니다.
IDS Alert: 시각 T, 5-tuple, sid
↓
[1] 패킷 원천 선택: Alert 내 payload / 엔진 pcap / 전체 패킷 수집
↓
[2] 시간 범위 자르기: T 전후 수 분 (editcap 등)
↓
[3] 5-tuple 필터: 출발지·목적지 IP와 포트
↓
[4] 스트림 재구성: 요청·응답을 순서대로 보기
↓
[5] 규칙 조건 대조: content가 어느 필드·위치에서 일치했는가, flow 방향이 맞는가
↓
[6] 판단: 공격 맥락의 일치(정탐) / 우연한 일치(오탐) / 응답으로 본 결과Suricata의 Alert 페이로드 기록은 suricata.yaml의 outputs › eve-log › types › alert 아래 payload, payload-printable, packet 항목으로 켭니다. 켜면 로그 크기가 커지고 민감 정보가 담길 수 있으므로 보관 정책을 함께 정합니다.
3. 주요 특징
- Alert에 담긴 페이로드는 일치한 패킷 하나인 경우가 많습니다. 여러 패킷에 걸친 요청이나 응답은 pcap으로 스트림 전체를 봐야 합니다.
- 정규화 차이를 기억해야 합니다. 규칙이 정규화 버퍼(예: 디코딩된 URI)에서 일치했다면, 원본 패킷에는 인코딩된 형태로 보여 content 문자열이 그대로 보이지 않을 수 있습니다.
- 증거 보존이 필요합니다. 사건으로 이어질 수 있는 pcap은 추출 즉시 해시값을 기록하고 원본을 수정하지 않습니다.
| 패킷에서 확인할 것 | 판단에 주는 정보 |
|---|---|
| 일치한 문자열의 위치 | 공격 파라미터 안인가, 정상 본문·파일 안인가 |
| 요청 전체 구조 | 정상 클라이언트의 요청인가, 도구가 만든 요청인가 |
| 서버 응답 | 오류·차단 페이지인가, 정상 처리 결과인가 |
| 연결 전후 | 같은 출발지의 선행·후속 요청 |
4. 예시
실습 예시 — 전체 패킷 수집 파일에서 Alert의 시각과 5-tuple로 해당 연결만 추출합니다(본인 소유 실습망의 pcap, 값은 환경마다 다름, editcap은 Rocky의 wireshark-cli, Ubuntu의 wireshark-common 패키지에 포함 — Ubuntu는 tshark 설치 시 함께 설치됨).
# 1) Alert 시각 전후 5분만 잘라내기
editcap -A "2026-09-30 16:10:00" -B "2026-09-30 16:15:00" sensor-full.pcap cut.pcap
# 2) 5-tuple로 해당 연결만 추출
tcpdump -nn -r cut.pcap -w alert-flow.pcap 'host 203.0.113.120 and host 192.168.20.10 and tcp port 52110'
# 3) 증거 해시 기록
sha256sum alert-flow.pcap | tee alert-flow.pcap.sha256Wireshark에서는 다음 표시 필터로 같은 연결을 찾습니다.
ip.addr == 203.0.113.120 && ip.addr == 192.168.20.10 && tcp.port == 52110Suricata Alert에 포함된 페이로드를 바로 확인하는 방법입니다(형식 예시, payload-printable 설정 시).
sudo jq -r 'select(.event_type=="alert" and .alert.signature_id==1002001) | .payload_printable' /var/log/suricata/eve.json | head -20📷 [실습 화면 삽입 위치] Wireshark에서 5-tuple 필터를 적용한 뒤 Follow TCP Stream으로 요청·응답을 연 화면(규칙의 content 문자열이 보이는 위치 표시)
5. 보안 관점
- 패킷은 오탐을 확정하는 가장 강한 근거입니다. 일치 위치가 공격 맥락이 아님을 보여 주면 튜닝 요청의 근거가 됩니다.
- 패킷에는 계정·쿠키·개인정보가 담길 수 있습니다. pcap 공유·보관은 접근 권한과 기간을 정해 관리합니다.
- TLS 트래픽은 패킷을 확보해도 내용을 볼 수 없습니다. 이때는 핸드셰이크 정보(SNI, 인증서)와 크기·타이밍만 근거로 씁니다.
6. SOC 관점
관제자가 Alert를 패킷으로 검증할 때 질문
- 이 Alert의 시각에 해당하는 패킷 원천이 있는가? 보관 기간 안인가?
- 규칙의 content는 패킷의 어느 위치에서 일치했는가? 방향은 규칙의 flow와 맞는가?
- 서버의 응답은 무엇이었는가? 요청이 처리되었다는 흔적이 있는가?
- 추출한 pcap의 해시와 추출 조건을 기록했는가?
Alert (시각·5-tuple·sid)
↓ pcap 원천 확인 → 시간 자르기 → 5-tuple 필터
↓ 스트림 재구성 → 규칙 조건 위치 대조
공격 맥락 → 정탐, 응답으로 결과 판단
우연 일치 → 오탐, 근거(pcap 위치) 첨부해 튜닝 요청
↓ pcap 해시·추출 조건 기록오탐 주의: Alert 페이로드에 공격 문자열이 보인다고 성공은 아닙니다. 응답까지 확인해야 합니다. 패킷에서 IOC를 뽑는 방법은 03 영역 149. Packet에서 IOC 추출과 298. Alert에서 IOC 추출에서 이어집니다.
7. 핵심 정리
- Alert는 규칙 일치의 요약이고, 패킷은 무엇이 오갔는지에 대한 원본 증거입니다.
- 패킷은 Alert 내 payload, 엔진 pcap 기록, 전체 패킷 수집, 사후 캡처로 확보합니다.
- 시각으로 범위를 자르고 5-tuple로 연결을 추출한 뒤 스트림으로 규칙 조건의 일치 위치를 확인합니다.
- 정규화 버퍼에서 일치한 규칙은 원본 패킷에서 인코딩된 형태로 보일 수 있습니다.
- 추출한 pcap은 해시와 추출 조건을 기록해 증거로 보존하고, 민감 정보 관리 기준을 따릅니다.
