[SNORT] SNORT 스키마 구조와 룰 구성 및 옵션 정보

1️⃣ SNORT 개요

🔹1. SNORT 동작 방식

1. 패킷 수집
   • 실시간으로 트래픽을 수집
2. 전처리 과정
   • 수집된 패킷은 Preprocessor로 전달되어 분석 전 필요한 전처리를 수행
3. 병렬 패턴 매칭 
   • SNORT의 룰에 따라 패킷 내용을 검사
   • 성능 향상을 위해 Aho-Corasick 알고리즘 기반의 병렬 문자열 검색 사용
   • 매칭 대상이 되는 룰이 많을수록 속도가 저하되므로, 전처리에서 일부 필터링 기능 수행
4. 룰 패턴 매칭
   • SNORT 룰 파일에 정의된 조건과 패킷을 비교하여 공격 여부를 탐지
   • 탐지되면 경고(Alert) 또는 로그(Log)로 기록

---

🔹2. SNORT 관계 구조

sensor (sid)
   │
   └───┐
                    ▼
     event (sid, cid) ───▶ signature (sig_id)
         │
         ├──▶ iphdr (sid, cid)
         ├──▶ tcphdr / udphdr / icmphdr (sid, cid)
         └──▶ data (sid, cid)

테이블	주요 필드	설명
sensor	(동기화 필드) ``sid``	Snort가 설치된 장비(센서)를 나타냄 각 센서에는 고유한 sid(sensor ID) 존재
	``hostname``, ``interface``, ``filter`` 등
event	(동기화 필드) ``sid``, ``cid``	Snort가 탐지한 하나의 이벤트(alert)를 의미 ``sid``와 ``cid``로 고유하게 식별됨 여러 테이블과 연결되는 중심이 되는 테이블
	``signature`` (ref > signaure.sig_id), ``timstamp``
signature	(동기화 필드) ``sig_id``	해당 이벤트가 어떤 시그니처(탐지 룰)에 의해 발생했는지를 나타냄 이벤트는 특정 시그니처를 참조함
	``sig_name`` 등
iphdr	(동기화 필드) ``sid``, ``cid``	이벤트에 포함된 IP 패킷의 헤더 정보 출발지/목적지 IP 주소 등을 포함
	``ip_src``, ``ip_dst``, ``ip_ver`` 등
tcphdr / udphdr / icmphdr	(동기화 필드) ``sid``, ``cid``	사용된 프로토콜에 따라 하나의 헤더 테이블에 연결됨 포트 번호, 플래그, 타입 등의 정보가 들어감
	``_sport``, ``_dport``, ``_flags`` 등
data	(동기화 필드) ``sid``, ``cid``	이벤트와 관련된 실제 페이로드(데이터)를 저장 이전 형태의 원본 데이터를 포함할 수 있음
	``data_payload``

 

---

🔹3. 주요 테이블 / 필드 내역

event

• 각 탐지된 이벤트의 기본 정보를 저장
• 필드 예시:
  • ``sid`` : Snort에서 사용하는 고유 식별자 (Signature ID)
  • ``cid ``: 연결(Connection) ID
  • ``signature`` : 탐지된 시그니처와 연결됨
  • ``timestamp`` : 이벤트 발생 시간

signature

• 탐지 룰의 시그니처 정보를 저장
• 필드 예시:
  • ``sig_id`` : 시그니처 고유 ID
  • ``sig_name`` : 시그니처 이름 (룰 이름)
  • ``sig_priority`` : 심각도(Priority)
  • ``sig_class_id ``: 분류 ID (sig_class 참조)

sig_class

• 시그니처 분류 정보 저장 (예: 공격 유형)
• 필드 예시:
  • ``sig_class_id`` : 클래스 ID
  • ``sig_class_name ``: 클래스 이름 (예: "Attempted Admin")

iphdr

• IP 헤더 정보 저장
• 필드 예시:
  • ``ip_src``, ``ip_dst ``: 출발지/목적지 IP 주소
  • ``ip_proto`` : 사용된 프로토콜 (TCP/UDP/ICMP 등)

tcphdr / udphdr / icmphdr

• 각각 TCP, UDP, ICMP 헤더 정보를 저장
• 예시 필드:
  • TCP: ``tcp_sport``, ``tcp_dport``, ``tcp_flags``
  • UDP: ``udp_sport``, ``udp_dport``
  • ICMP: ``icmp_type``, ``icmp_code``

data

• 패킷의 ``raw payload`` 데이터를 저장

sensor

• 이벤트가 탐지된 센서 장비에 대한 정보 저장
• 필드 예시:
  • ``sid`` : 센서 ID
  • ``hostname``, ``interface``

---

🔹4. SNORT 스키마

snort 전체 스키마 구조

---

2️⃣ SNORT 룰

🔹1. 구성 요소

출처: writing snort rules with examples and cheat sheet (https://cyvatar.ai/write-configure-snort-rules/)

 

헤더 (Header)

• 패킷의 기본 속성에 대한 조건 등 트래픽 발생 주체 및 방향 등을 정의한다.

요소	설명
``action``	동작 종류 (``alert``, ``log``, ``pass``, ``drop``, ``reject``, ``sdrop``)
``protocol``	``tcp``, ``udp``, ``icmp``, ``ip`` 등
``src_ip``	출발지 IP
``src_port``	출발지 포트
``->``, ``<-``, ``<>``	트래픽 방향
``dst_ip``	목적지 IP
``dst_port``	목적지 포트

 

옵션 (Options)

• 패킷 내용을 더 자세히 분석하고, 경고 메시지나 룰 정보 등을 설정하는 등 트래픽 세부 특징을 정의한다. 

옵션	설명
``msg``	탐지 시출력할 메시지
``content``	페이로드에서 검색할 문자열
``sid``	룰 고유 번호 (Signature ID)
``rev``	룰 버전 (Revision)
``classtype``	공격 유형
``priority``	심각도 (1=높음, 2=중간, 3=낮음)
``flow``	트래픽 방향 조건 (``to_server``, ``from_client``, ``established`` 등)
``depth/offset``	content 검사 범위 지정
``metadata``	룰 관련 메타 정보

---

🔹 2. Payload 검사 룰

• 패킷의 실제 데이터 부분을 분석해서 공격을 탐지한다.

주요 룰 옵션

옵션	검사 범위	비고
content	페이로드 전체	순수 문자열 검사만 지원
uricontent	URI
pcre	페이로드 전체	정규표현식 지원

---

🔹 3. Non-Payload 검사 룰

• Non-Payload 룰은 전송된 실제 데이터가 아닌 **헤더와 트래픽 상태**를 기준으로 분석한다

주요 룰 옵션

옵션	설명
flow	트래픽 방향 선택 (SYN 플래그 기준)
flags	TCP flag bit 검사
dsize	페이로드 사이즈 검사

---

3️⃣ Payload 검사 룰 옵션

🔹1. content/uricontent 옵션

• 문자열 기반의 페이로드 탐지 옵션
• snort 룰에서 패킷 데이터 내 특정 문자열 존재 여부를 검사
• ``content``: 페이로드 전체 영역에서 문자열을 탐지
• ``uricontent``: HTTP 요청 URI 경로에서 문자열 탐지

주요 수정자 (Modifier)

• ``nocase`` 대소문자 구분 해제
• 절대 위치
  • ``offset`` 검사 시작 위치
  • ``depth`` 검사 범위
• 상대 위치
  • ``distance`` 검사 시작 위치 (이전 검사가 끝난 지점부터)
  • ``within`` 검사 범위

예시

• 페이로드 처음 3바이트 안에 ``"GET"`` 문자열이 있는지 검사
• ``"GET"`` 문자열 끝나고 2바이트 후부터 7바이트 안에 ``"rawdata"``가 있는지 검사

alert tcp any any -> any 80 (
    msg:"Test rule for GET and rawdata detection";
    content:"GET"; offset:0; depth:3;
    content:"rawdata"; distance:2; within:7;
    sid:1000010; rev:1;
)


[ 페이로드 예시 ]  
0000: 47 45 54 20 78 78 72 61 77 64 61 74 61
           ↑ "GET"
                    ↑ (space)  
                      ↑ "x x r a w d a t a"
                          ↑ rawdata는 "GET" 이후 +2 위치부터 +7 안에 있음 → ✅ 매칭

---

 

🔹2. pcre 옵션

• Perl-Compatible Regular Expressions
• 정규표현식을 이용해 보다 복잡하고 유연한 문자열 패턴을 탐지

pcre 수정자

• ``/i`` 대소문자 구분 안함
• ``/s`` 줄바꿈 문자 검사
• ``/m`` 앵커 문자의 줄 구분 해제
• ``/R`` 'distance:0`과 동일 (snort only)

 

---

4️⃣ Non-Payload 검사 룰 옵션

🔹1. flow 옵션

• 패킷이 TCP 연결 내에서 어느 방향으로, 어떤 상태로 흐르고 있는지를 지정하는 옵션
• TCP SYN 플래그를 기준으로 방향을 구분
• Client ↔ Server 구분이 명확한 네트워크에서만 사용 가능하다는 단점이 있음 

주요 키워드

• ``to_server``: 클라이언트 → 서버 방향으로 트래픽
• ``from_client``:  클라이언트에서 시작된 트래픽
• ``to_client``: 서버 → 클라이언트 방향의 트래픽
• ``from_server``: 서버에서 시작된 트래픽
• ``established``: TCP 핸드쉐이크가 완료된 세션에서만 매칭 (SYN-ACK 후)
• ``stateless``: 상태 추적 없이 검사 (UDP처럼 세션 없음)
• ``not_established``: 세션이 아직 설정되지 않은 상태에서만 탐지 (ex. SYN 패킷 탐지 등)

예시

• TCP SYN 플래그를 수신한 서버로 향하는 트래픽만 검사

alert tcp any any -> any any (
	flow:to_server; 
    content:”aaa”
)

---

🔹2. flags 옵션

• TCP 헤더의 플래그 비트를 검사하는 옵션
• SYN, ACK, FIN, RST 등 TCP 통신 과정에서 설정되는 플래그 조합을 기반으로 탐지할 수 있음

주요 TCP 플래그 목록 

• ``S`` SYN (세션 시작 요청)
• ``A`` ACK (응답 확인)
• ``F`` FIN (세션 종료 요청)
• ``R`` RST (세션 강제 종료)
• ``P`` PSH (즉시 전송 요청)
• ``U`` URG (긴급 데이터 있음)
• ``E`` ECN-Echo (Congestion Notification 응답)
• ``C`` CWR (Congestion Window Reduced)

예시

• 좋은 예시 - SYN 플래그 + 특정 페이로드 탐지
  • ``flags: S;`` → SYN 플래그 설정된 패킷만 대상으로
  • ``"aaa"``라는 문자열이 있는 비정상 SYN 요청 탐지

alert tcp any any -> any 80 (
    flags: S; 
    content: "aaa"; 
    msg: "SYN packet with suspicious payload"; 
    sid:1000001; 
    rev:1; 
    classtype:attempted-recon;
)

• 나쁜 예시 – content 먼저 검사 (비효율적)
  • 순서상 문제로 모든 TCP 패킷의 content를 먼저 검사 → 비효율
  • 성능 저하 우려

alert tcp any any -> any 80 (
    content: "aaa"; 
    flags: S; 
    msg: "Inefficient order: content before flags"; 
    sid:1000002; 
    rev:1; 
    classtype:bad-unknown;
)

• 더 나쁜 예시 – 의미 없는 조합
  • ``flags: PA;``는 정상적인 데이터 전송용 패킷
  • ``"aaa"``가 들어있을 가능성은 낮음 → 탐지 의도 부정확

alert tcp any any -> any 80 (
    content: "aaa"; 
    flags: PA; 
    msg: "Invalid flag-content logic"; 
    sid:1000003; 
    rev:1; 
    classtype:bad-unknown;
)

---

🔹3. dsize 옵션

• 패킷의 Payload(데이터) 크기를 검사하는 옵션
• 이상하게 크기가 작거나 큰 패킷을 탐지하거나, 무의미한 패킷, 스캐닝 시도 등을 잡아내는 데 유용

사용 방법

1. 고정 크기 검사
2. 이상 검사
3. 이하 검사

# 고정 크기 검사
dsize: 0;		// 페이로드 크기가 정확히 0바트일때 매칭
				// 흔히 Null 스캔이나, 의미 없는 패킷 등 탐지에서 사용됨

# 이상 검사
dsize: >300;	// 페이로드 크기가 300바이트보다 클 때 매칭
				// 보통은 비정상적으로 큰 요청, 우회 공격 시도 등을 탐지할 때 사용

# 이하 검사
dsize: <10;		// 페이로드 크기가 10바이트 미만일 때 매칭
				// 스캔이나 취약한 짧은 명령어 요청 패킷 탐지

---

5️⃣ Thresholds 검사 룰 옵션

• 동일한 이벤트가 특정 시간 내에 반복될 경우, 알림 발생을 제어하는 설정

사용 가능한 타입

• ``type`` 입계값 동작 방식을 지정
  • ``limit`` 일정 횟수만 허용하고 나머지는 무시
  • ``threshold`` 일정 횟수마다 한 번씩 경고 발생
  • ``both`` 일정 횟수 도달 시 1번 경고 후 나머지 무시 
• ``track`` 임계값을 어떤 기준으로 추적할지 지정
  • ``by_src`` 출발지 IP 기준
  • ``by_dst`` 목적지 IP 기준
• ``count`` 지정한 ``seconds`` 내에 이벤트가 몇 번 발생해야 경고를 낼지
• ``seconds`` 이벤트 발생을 측정하는 시간 범위 (단위: 초)

예시

• 동일한 목적지 IP에 대해 3초 동안 ping이 2회 발생하면 → 1번 경고 발생
• 이후 추가적인 ping이 계속 와도 → 3초 안에 다시 2회 있어야 또 alert

alert icmp any any-> any any (
	msg:“threshold-test"; 
    itype:8; 
    threshold:type threshold, 
    track by_dst, 
    count 2, 
    seconds 3; 
    sid:1000005; 
    rev:1;
)

---

🔗 레퍼런스

1. The Snort Project, 「SNORT Users Manual」, SNORT 공식 홈페이지(링크)