📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 298편
이전 글: 297. IDS Alert와 Packet 연계 · 다음 글: 299. IDS Incident 분석
1. 개념
IOC(Indicator of Compromise, 침해 지표) 는 공격이나 침해를 식별하는 데 쓸 수 있는 관찰 가능한 값입니다. IP 주소, 도메인, URL, 파일 해시, User-Agent, TLS 지문 등이 대표적입니다. 스캔 사건의 IOC 정리는 05 영역 246. IOC 추출, 패킷에서 직접 뽑는 방법은 03 영역 149. Packet에서 IOC 추출에서 다뤘습니다.
이 글은 IDS Alert와 그 흐름의 메타데이터에서 IOC를 뽑는 방법, 그리고 뽑은 값을 IOC로 인정하기 전에 무엇을 확인해야 하는지를 다룹니다. Alert의 sid 자체는 IOC가 아니라 탐지 규칙입니다. IOC는 그 Alert에 담긴 관찰 값입니다.
| IOC 종류 | Suricata EVE에서의 위치(예) | 비고 |
|---|---|---|
| IP·포트 | src_ip, dest_ip, dest_port | 방향 해석 먼저(295. IDS Alert의 Source/Destination 분석) |
| 도메인 | http.hostname, tls.sni, dns 이벤트의 질의 이름 | dns 이벤트 구조는 버전별로 다름 |
| URL·경로 | http.url | 파라미터에 개인정보가 섞일 수 있음 |
| User-Agent | http.http_user_agent | 쉽게 바뀌어 단독 가치 낮음 |
| 파일 해시 | fileinfo.sha256 등 | 파일 해시 계산 설정 시에만 기록 |
| TLS 지문 | tls.fingerprint(인증서), tls.ja3.hash | JA3는 설정·버전에 따라 기록 여부 다름 |
2. 동작 원리
Alert에서 IOC가 되기까지의 과정입니다.
Alert (sid, 5-tuple, flow_id)
↓ flow_id 로 같은 흐름의 http / dns / tls / fileinfo 이벤트 수집
[후보 값 추출] IP, 도메인, URL, 해시, UA, 지문
↓
[검증]
├─ 우리 자산·정상 서비스인가? → 제외 (내부 IP, 자사 도메인, 업데이트 서버)
├─ 공유 인프라인가? → 낮은 신뢰도 표시 (CDN, 클라우드, 대형 서비스)
├─ 공격 방향의 어느 쪽 값인가? → 공격자 인프라 / 피해 자산 구분
└─ 판단 근거가 정탐 Alert인가? → 오탐 Alert의 값은 IOC가 아님
↓
[맥락 기록] 최초·최종 관찰 시각, 출처 Alert, 신뢰도, 관련 사건
↓
[활용] 과거 로그 재검색, 차단 목록, 탐지 규칙·데이터셋, 공유3. 주요 특징
IOC는 종류마다 공격자가 바꾸기 쉬운 정도가 다릅니다. David Bianco의 Pyramid of Pain은 이를 설명하는 대표 모델입니다.
| IOC 종류 | 공격자가 바꾸는 비용 | 수명 | 활용 |
|---|---|---|---|
| 파일 해시 | 매우 낮음(한 바이트만 바꿔도 변경) | 짧음 | 같은 파일 재등장 확인 |
| IP 주소 | 낮음 | 짧음(재할당 잦음) | 단기 차단, 과거 검색 |
| 도메인 | 낮음~중간 | 중간 | DNS·프록시 탐지 |
| 네트워크·호스트 흔적(URL 패턴, UA, 지문) | 중간 | 중간~김 | 규칙화 |
| 도구·행위(TTP) | 높음 | 김 | 행위 기반 탐지 |
- 해시·IP는 뽑기 쉽지만 금방 무의미해집니다. 사건 대응 초기의 빠른 검색·차단에는 유용하되, 장기 탐지에는 행위 수준의 특징을 함께 남깁니다.
- IOC는 맥락과 함께 있어야 쓸모가 있습니다. "언제, 어떤 Alert에서, 어느 방향으로 관찰되었는가"가 없는 IP 목록은 오탐원이 되기 쉽습니다.
4. 예시
실습 예시 — 특정 sid Alert의 flow_id로 같은 흐름의 IOC 후보를 뽑습니다(Suricata EVE, Rocky/Ubuntu 공통, 값은 환경마다 다름).
# 1) 대상 Alert의 flow_id 목록 (한 줄에 숫자 하나)
sudo jq -c 'select(.event_type=="alert" and .alert.signature_id==1002101) | .flow_id' /var/log/suricata/eve.json | sort -u > flows.json
# 2) 같은 흐름의 http·tls·fileinfo 이벤트에서 후보 값 추출
sudo jq -r --slurpfile ids flows.json \
'select(.flow_id as $f | any($ids[]; . == $f)) |
[.event_type, .dest_ip, (.http.hostname // .tls.sni // ""), (.http.url // ""), (.fileinfo.sha256 // "")] | @tsv' \
/var/log/suricata/eve.json | sort -u정리한 IOC 기록의 형식 예시입니다(값은 예시, 공유용 문서에서는 클릭되지 않도록 무력화 표기).
# 형식 예시 — IOC 기록
type=domain value=update-check[.]example first=2026-09-30T02:11Z last=2026-09-30T04:40Z src_alert=sid:1002101 dir=내부→외부 confidence=중
type=ip value=198.51.100[.]140 first=2026-09-30T02:11Z last=2026-09-30T04:40Z note=클라우드 대역, 공유 가능성
type=url value=hxxp://update-check[.]example/api/v2/poll confidence=중
type=sha256 value=(64자리 해시) src=fileinfo note=다운로드된 파일분석 방법 — 도메인과 URL 경로 패턴은 IP보다 오래 유효할 가능성이 있고, IP는 클라우드 대역이라 차단 시 영향 범위를 먼저 확인해야 합니다. hxxp, [.] 표기는 문서나 메신저에서 실수로 접속되는 것을 막는 관례입니다.
5. 보안 관점
- 검증하지 않은 IOC를 차단 목록에 넣으면 정상 서비스 장애가 생깁니다. CDN·클라우드 IP 차단이 대표적입니다.
- 추출한 IOC로 과거 로그를 재검색하면, Alert가 없던 시점의 최초 접촉이나 다른 감염 호스트를 찾을 수 있습니다.
- IOC 공유 시 내부 IP, 사용자 정보, URL 파라미터의 개인정보는 제거합니다. 공유 범위는 TLP 같은 표기 규칙으로 정합니다.
6. SOC 관점
관제자가 IOC를 추출할 때 질문
- 이 값은 정탐으로 판단된 Alert에서 나왔는가?
- 공격자 인프라의 값인가, 피해 자산의 값인가?
- 자사 자산·정상 서비스·공유 인프라를 제외했는가?
- 최초·최종 관찰 시각, 출처, 신뢰도를 함께 기록했는가?
정탐 Alert
↓ flow_id 로 메타데이터 수집 → 후보 값
↓ 검증 (자산 제외, 공유 인프라 표시, 방향 구분)
↓ 맥락 기록 (시각·출처·신뢰도)
├─ 과거 로그 재검색 → 추가 피해 호스트·최초 시점
├─ 차단 요청 (영향 범위 확인 후)
└─ 사건 보고서 IOC 목록오탐 주의: 악성 페이지가 불러온 정상 라이브러리 도메인, 공격 전후 피해 호스트의 정상 업데이트 통신이 IOC 목록에 섞이기 쉽습니다. 사건과 직접 관련된 값만 남깁니다.
7. 핵심 정리
- IOC는 공격·침해를 식별하는 관찰 값이며, Alert의 sid는 IOC가 아니라 탐지 규칙입니다.
- Suricata에서는 flow_id로 같은 흐름의 http·dns·tls·fileinfo 이벤트를 모아 IOC 후보를 뽑습니다.
- 자사 자산·정상 서비스를 제외하고, 공유 인프라와 공격 방향을 구분해 검증합니다.
- 해시·IP는 수명이 짧고, 도메인·URL 패턴·행위 특징은 상대적으로 오래 유효합니다.
- IOC는 최초·최종 관찰 시각, 출처 Alert, 신뢰도와 함께 기록하고 무력화 표기로 공유합니다.
