📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 287편
이전 글: 286. False Negative · 다음 글: 288. Snort Rule 기초
1. 개념
Snort는 1998년 공개된 오픈소스 네트워크 IDS/IPS 엔진으로, 현재 Cisco Talos가 개발과 규칙 배포를 이끌고 있습니다. Snort가 만든 규칙 문법은 Suricata 등 다른 엔진에도 이어져 시그니처 규칙의 공용어 역할을 합니다.
Snort 2와 Snort 3의 구조 차이, 설치 경로, 실행 옵션은 04 영역 193. Snort에서 다뤘습니다. 이 글은 Snort가 무엇을 근거로 탐지하고, 관제자가 Snort Alert를 어떻게 읽는가에 집중합니다.
Snort의 탐지 결과는 두 종류의 출처에서 나옵니다.
| 출처 | 설명 | 예 |
|---|---|---|
| 텍스트 규칙 | 규칙 파일의 한 줄 규칙이 일치 | 로컬 규칙, Talos 규칙 |
| 전처리기(Snort 2) / inspector(Snort 3) | 프로토콜 해석 중 발견한 이상이나 내장 탐지 기능 | 비정상 HTTP, 포트 스캔 탐지, 디코더 이상 |
2. 동작 원리
Snort가 Alert를 만드는 흐름을 탐지 관점에서 보면 다음과 같습니다.
패킷 수집
↓
[디코더] 헤더 해석 ── 규격 이상 발견 시 디코더 이벤트 (gid 116 계열)
↓
[전처리기 / inspector]
├─ stream: TCP 재조립
├─ http_inspect: URI 디코딩·정규화, 헤더·본문 분리 ── HTTP 이상 이벤트
├─ port_scan(Snort 3) / sfPortscan(Snort 2) ── 스캔 이벤트 (gid 122)
└─ 기타 프로토콜 분석기 (dns, ssl, smb 등)
↓ 정규화된 버퍼 제공
[탐지 엔진] 텍스트 규칙 매칭 ── 규칙 이벤트 (gid 1)
↓
[출력] alert_fast / alert_full / alert_json / unified2(Snort 2) 등정규화(Normalization) 가 중요합니다. http_inspect는 %2e%2e%2f 같은 URL 인코딩을 해석한 URI를 규칙에 넘겨주므로, 규칙은 인코딩된 변형을 일일이 적지 않아도 됩니다. 원본 그대로 검사하고 싶다면 raw 계열 버퍼를 따로 지정합니다.
3. 주요 특징
Alert의 gid로 출처를 구분할 수 있습니다. 대표적인 값은 다음과 같습니다(버전에 따라 번호와 범위가 다를 수 있으므로 해당 버전의 gen-msg 정보나 문서를 확인합니다).
| gid | 출처 | 해석 |
|---|---|---|
| 1 | 텍스트 규칙 | 규칙 원문을 sid로 조회 |
| 3 | 공유 객체(SO) 규칙 | 바이너리로 배포된 Talos 규칙 |
| 116 | 디코더 | 패킷 헤더 규격 이상 |
| 119, 120 | HTTP inspector | HTTP 요청·응답 이상 |
| 122 | 포트 스캔 탐지 | 스캔 유형별 sid |
Talos 규칙은 정책(Policy) 단위로 묶여 배포됩니다. 대표적으로 connectivity(연결성 우선, 규칙 적음), balanced(균형), security(탐지 우선, 규칙 많음) 계열이 있고, 규칙의 metadata에 어느 정책에 포함되는지가 적혀 있습니다. 조직의 위험 허용도에 맞는 정책을 기준으로 하고 로컬 규칙으로 보완하는 것이 일반적입니다.
4. 예시
Snort 3 alert_json 출력의 형식 예시입니다(값은 환경마다 다름, 출력 필드는 설정의 fields 항목과 버전에 따라 다름).
# 형식 예시 — Snort 3 alert_json (한 줄 JSON, 일부 필드)
{ "timestamp" : "09/30-10:15:32.123456", "proto" : "TCP", "src_addr" : "203.0.113.25", "src_port" : 50412,
"dst_addr" : "192.168.20.10", "dst_port" : 80, "service" : "http",
"rule" : "1:1001101:1", "msg" : "LOCAL web admin path request", "priority" : 2, "class" : "Web Application Attack" }분석 방법 — rule 필드의 1:1001101:1은 gid:sid:rev입니다. gid가 1이므로 텍스트 규칙이고, sid 1001101은 로컬 범위이므로 조직 로컬 규칙 파일에서 원문을 찾습니다. service는 Snort 3가 식별한 응용 프로토콜로, 비표준 포트에서도 HTTP로 식별되었다면 그 자체가 확인 포인트가 됩니다. Snort 2의 alert_fast 한 줄 형식은 193. Snort의 예시를 참고합니다.
5. 보안 관점
- Snort의 탐지 품질은 규칙 정책 선택과 갱신에 크게 좌우됩니다. 정책을 너무 보수적으로 고르면 미탐이, 너무 공격적으로 고르면 오탐이 늘어납니다.
- inspector를 끄거나 설정이 누락되면 해당 프로토콜의 정규화가 이뤄지지 않아 HTTP 규칙이 인코딩 변형을 놓칠 수 있습니다.
- Snort 2에서 Snort 3로 전환할 때 규칙·설정 변환 결과를 검증하지 않으면 일부 탐지가 조용히 빠질 수 있습니다.
6. SOC 관점
관제자가 Snort Alert를 볼 때 확인할 질문
gid는 무엇인가? 규칙 이벤트(1)인가, 디코더·inspector 이벤트인가?- 규칙 이벤트라면 sid·rev로 규칙 원문을 찾았는가? 로컬 규칙인가, Talos 규칙인가?
- inspector 이벤트라면 프로토콜 이상의 원인이 공격인가, 비표준 구현 장비인가?
- 이 센서는 Snort 2인가 3인가? 출력 형식과 필드 이름이 다릅니다.
Snort Alert
↓ gid 확인
gid 1·3 → sid·rev로 규칙 원문·정책 확인 → 탐지 의도 파악
그 외 → 디코더·inspector 이벤트 → 프로토콜 이상 원인 확인
↓
5-tuple·시각으로 방화벽·흐름 로그 연계오탐 주의: 디코더·inspector 이벤트는 가상화 환경의 체크섬 오프로딩, 오래된 장비의 비표준 프로토콜 구현으로도 많이 발생합니다. 반복 출처가 특정 장비로 모이면 환경 요인을 먼저 확인합니다. Snort의 스캔 탐지 설정은 05 영역 237. Snort Scan 탐지에서 다뤘습니다.
7. 핵심 정리
- Snort는 규칙 문법의 표준을 만든 오픈소스 IDS/IPS 엔진이며, 현재 Cisco Talos가 개발과 규칙 배포를 이끕니다.
- 탐지 결과는 텍스트 규칙 이벤트와 디코더·전처리기(inspector) 이벤트로 나뉘며 gid로 구분합니다.
- http_inspect 같은 inspector가 정규화한 버퍼를 규칙에 제공해 인코딩 변형 탐지를 돕습니다.
- Talos 규칙은 connectivity·balanced·security 계열 정책으로 묶여 배포됩니다.
- Snort Alert는
gid:sid:rev로 출처와 규칙을 확인한 뒤 다른 로그와 연계해 판단합니다.
