Snort 규칙과 검사 흐름 이해하기

01개념과 구성 요소

• 입력DAQ가 인터페이스 또는 PCAP에서 패킷을 받으며 passive와 inline 경로를 구분한다.
• 해석Decoder·flow/stream·service inspector가 패킷을 규칙이 검사할 상태와 버퍼로 바꾼다.
• 규칙·출력헤더와 옵션이 조건을 정의하고 SID·revision이 규칙을 식별하며 logger/action이 결과를 처리한다.

02Snort 3에서 HTTP 경로 규칙을 평가하는 순서

1. 패킷 수신DAQ가 패킷을 받고 주소·포트·프로토콜과 HOME_NET 관점의 방향을 확인한다.
2. 연결 상태 구성Flow·stream 처리가 연결 방향과 established 상태, 재조립된 바이트를 만든다.
3. HTTP Inspector 연결Wizard·Binder와 설정이 해당 flow의 서비스 해석을 연결한다. 80번 포트라는 사실만으로 정상 HTTP가 보장되지는 않는다.
4. 검사 버퍼 선택http_uri 같은 sticky buffer에서 정규화된 URI를 검사한다. URI 버퍼에는 요청 메서드 전체가 들어 있지 않다.
5. 규칙 조건 평가flow·content·빈도 등 조건이 맞는지 확인하고 SID·rev와 사건 문맥을 결과에 연결한다.
6. 결과 처리선택한 logger로 경보를 남긴다. 실제 차단은 지원 DAQ·inline 경로·정책이 모두 맞아야 한다.

03DAQ가 패킷을 받고 Inspector가 의미를 만든다

• DAQ 입력Snort 3의 입력은 DAQ(Data Acquisition) 모듈이 담당한다. 실시간 인터페이스와 저장된 PCAP은 서로 다른 입력이며 passive 캡처와 inline 처리도 구분된다.
• 해석 파이프라인Decoder가 헤더를 읽고 flow·stream·service inspector가 연결과 응용 계층을 해석한 뒤 규칙 엔진과 logger/action으로 이어진다.
• 표시·저장·탐지Sniffer·Packet Logger·IDS는 표시·저장·탐지라는 목적이 다른 동작이다. 패킷을 화면에 표시한 것, PCAP으로 저장한 것, 특정 규칙이 일치하여 경보를 낸 것을 같은 결과로 취급하지 않는다.
• 실행 구성실행 중인 바이너리·DAQ·설정·룰·logger가 실제로 연결되어야 의도한 경로가 완성된다.

04SPAN·TAP과 보호 네트워크 변수

• SPAN·TAPPassive 센서는 SPAN/TAP 또는 가상 스위치 미러링 등으로 복사본을 받는다. 일반 스위치의 아무 포트에 연결했다고 다른 두 호스트의 unicast를 모두 볼 수 있는 것은 아니다.
• 손실·중복양방향 미러링을 설정했더라도 복사 대상 합계 대역폭이 출력 포트나 센서 처리량을 넘으면 손실이 생긴다. 복수 위치에서 같은 패킷을 복사하면 중복도 생길 수 있다.
• 네트워크 변수HOME_NET은 보호할 범위이고 EXTERNAL_NET은 규칙이 외부로 취급할 범위이다. EXTERNAL_NET을 !HOME_NET으로 정의하면 내부 호스트 사이의 사건은 해당 외부→내부 규칙에 맞지 않을 수 있다.
• 방향·NATNAT 앞과 뒤에서 주소가 달라지는 것도 헤더 조건에 직접 영향을 준다. ->는 규칙 왼쪽에서 오른쪽으로의 논리 방향이며 장비 인터페이스의 in/out과 자동으로 같지 않다.

수업 원본 자료

SPAN으로 센서에 복사 트래픽 보내기

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. source interface f1/2 both는 해당 포트의 양방향 트래픽을 복사 대상으로 삼는 설정입니다. 센서가 모든 포트의 모든 트래픽을 자동으로 보는 것은 아닙니다.
2. destination interface f1/1은 복사본을 보내는 관찰 포트입니다. 이 연결의 센서는 원래 사용자 데이터 경로를 통과시키는 inline 장비로 그려져 있지 않습니다.
3. 관찰 포트 과부하나 캡처 누락이 생기면 원본 트래픽과 센서가 분석한 트래픽이 달라질 수 있습니다. 규칙을 조정하기 전에 센서에 필요한 패킷이 도착하는지 확인합니다.
4. 이 토폴로지는 복사 기반 관찰 위치를 설명합니다. 다른 구성에서 가능한 IPS 차단 기능과 구분하며, 경보가 생겼다는 이유만으로 이 그림의 원래 세션이 차단되었다고 판단하지 않습니다.

Cisco 공식 문서: SPAN 관찰 방식 ↗

05Lua 설정·Wizard·Binder

• Lua 설정snort.lua는 Lua 설정으로 기본값과 inspector·ips·logger를 연결한다. 상대 경로는 서비스의 작업 디렉터리와 include 경로에 영향을 받는다.
• 테이블 덮어쓰기별도의 ips 테이블을 뒤에 다시 대입하면 앞서 설정한 내용이 덮어써질 수 있으므로 한 구조 안에서 필요한 항목을 병합한다.
• Wizard·BinderWizard는 서비스 식별을 돕고 Binder는 포트·프로토콜·네트워크·서비스 조건에 맞는 inspector를 연결한다. HTTP가 항상 80번에서만 동작한다고 가정하면 다른 포트의 HTTP를 잘못 처리할 수 있다.
• 프로토콜 조건반대로 80번이라는 이유만으로 모든 바이트가 정상 HTTP인 것도 아니다. 규칙의 HTTP 버퍼가 채워지려면 해당 flow가 HTTP로 해석되는 단계가 필요하다.

06규칙 헤더와 옵션을 한 줄씩 읽기

• 규칙 헤더헤더는 action, protocol, source address/port, direction, destination address/port로 구성된다. 괄호 안에는 msg, flow, content 같은 조건과 sid·rev 같은 관리 정보가 들어간다.
• SID·Revsid는 규칙 식별자, rev는 변경 버전이며 같은 SID를 다른 의미의 규칙에 중복 사용하면 분석과 갱신이 혼란스러워진다.
• HTTP 버퍼 예아래는 HTTP 요청의 정규화 URI에서 무해한 교육 경로를 찾는 Snort 3 예이다. to_server는 클라이언트→서버 방향, established는 연결 상태, http_uri는 이후 content의 검사 버퍼를 지정한다.
• URI의 범위요청 줄의 GET까지 URI 버퍼에 들어 있는 것은 아니므로 URI 버퍼에서 “GET /...” 전체를 찾는 규칙과 혼동하지 않는다.

alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (
  msg:"Training URI observed";
  flow:established,to_server;
  http_uri;
  content:"/training-marker";
  sid:1000001;
  rev:1;
)

무해한 경로를 찾는 Snort 3 문법 학습 예입니다. 운영에 적용된 규칙이라는 뜻은 아닙니다.

07Raw content와 정규화 버퍼의 차이

• Raw·정규화TCP raw payload는 요청 바이트의 배치에 민감하다. HTTP URI 버퍼는 응용 파서가 URI 부분을 제공하며 정규화된 버퍼와 원본 버퍼를 구분할 수 있다.
• 표현의 차이퍼센트 인코딩·경로 정리·TCP 분할 같은 조건에서 어느 표현을 검사하는지에 따라 결과가 달라진다. 정규화가 수행된 값과 원본 값을 함께 이해해야 규칙 일치 이유를 설명할 수 있다.
• Content·PCREcontent는 특정 문자열·바이트 패턴, pcre는 정규식 조건을 표현한다. offset/depth 등 위치 제한은 특정 버퍼 안에서 어떤 영역을 볼지 정하는 의미를 가진다.
• 문법 검사규칙의 쉼표·옵션 철자·필수 SID·중복 SID는 로드 전 문법과 식별자 검증 대상이다.

11SYN 빈도 규칙과 임계값

• 빈도 규칙다음 규칙은 SYN 플래그와 stateless 조건에 맞는 패킷을 출발지별로 세어 5초에 20회를 초과하는 활동을 탐지한다. detection_filter는 규칙 조건을 만족한 빈도를 기준으로 이벤트 생성을 제한한다.
• 포트 수와 차이이는 고유 목적지 포트 수를 자동으로 계산하는 기능과 다르므로 동일 포트로의 많은 정상 연결도 조건에 들어올 수 있다.
• 집계 기준NAT 뒤의 여러 사용자를 하나의 출발지로 세면 집계가 커지고, 여러 출발지로 분산된 행위는 출발지별 임계값에 안 닿을 수 있다. 임계값은 트래픽 기준선과 목적에 맞는 가설이며 보편적인 공격 경계가 아니다.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (
  msg:"TCP Excessive SYN Activity"; flags:S; flow:stateless;
  detection_filter:track by_src,count 20,seconds 5;
  sid:4001001; rev:1;
)

수업 원문의 탐지 규칙입니다. SYN 빈도를 탐지하며 고유 포트 수나 Nmap 사용 여부를 확정하지 않습니다.

12배너·오류·특정 URI의 증거 강도

• 배너·프로토콜OpenSSH 배너·MySQL 오류 1130·특정 HTTP probe 경로·WebDAV PROPFIND·비정상 TCP flags는 각각 다른 관찰 단서다. SSH 배너는 정상 로그인 클라이언트도 받으므로 스캔 확정 근거가 아니다.
• MySQL 오류MySQL ERR 패킷의 FF와 1130의 little-endian 표현 6A 04도 접근 거부를 뜻할 수 있지만 어떤 도구가 연결했는지까지 말해주지 않는다.
• URI·PROPFIND특정 도구가 사용하는 특징적인 URI는 연관성이 더 강하지만 문자열을 다른 프로그램이 보낼 수도 있다. PROPFIND는 WebDAV의 정상 메서드이다.
• 증거 강도각 경보의 사실은 “이 패턴이 관찰됨”이며 전체 스캔 판단은 시간·출발지·대상 포트와 다른 이벤트를 연결해야 한다.

13Flowbit와 연결을 넘는 상관분석

• Flowbitsflowbits는 동일 flow 안에서 이전 규칙의 상태를 기억해 후속 조건에 이용하는 데 적합하다. Nmap 서비스 probe처럼 새 출발지 포트를 사용해 연결을 여러 번 만들면 이전 flow의 bit를 전체 조사 세션의 상태처럼 쓸 수 없다.
• 연결 간 상관분석각 연결에서 개별 특징을 탐지한 뒤 SIEM의 시간창과 주체 기준으로 연결하는 역할 분담이 필요하다.
• 응답 방향서버 응답을 검사하는 to_client 규칙은 요청 규칙과 방향이 반대다. 같은 src_ip 필드가 요청에서는 클라이언트, 응답에서는 서버를 뜻하므로 무조건 같은 필드명으로만 묶으면 잘못된 상관분석을 만들 수 있다.
• 역할 기반 필드initiator/responder와 센서 위치를 보존하는 이유다.

14Alert JSON 필드와 실제 차단

• JSON 필드Alert JSON의 예시 필드는 timestamp, pkt_num, proto, pkt_len, dir, src_ap, dst_ap, rule, action이다. rule의 1:SID:rev는 generator·signature·revision 구분에 쓰이고 pkt_num은 그 입력 처리 문맥의 패킷 번호다.
• 번호 문맥다른 실행이나 별도 PCAP의 번호와 직접 같다고 가정해서는 안 된다. 로그 형식은 선택한 logger와 fields 설정에 따라 달라진다.
• Passive Alertalert는 조건 일치 사실이며 passive 센서가 기록한 action만으로 트래픽 차단을 주장하지 않는다. 실제 차단은 패킷이 통과하는 inline 경로와 지원 DAQ, 정책 동작이 모두 맞아야 한다.
• Inline 동작alert·drop·block 같은 규칙 동작과 최종 전달 결과를 구분하여 해석한다.

15문법 검사·PCAP 재현·Live 관찰

• 문법과 PCAP-T는 설정과 규칙을 읽을 수 있는지 검사하지만 기대한 트래픽에서 올바르게 탐지하는지까지 증명하지 않는다. 같은 PCAP을 입력하면 네트워크 변동을 줄여 규칙 변경 전후를 비교할 수 있다.
• Live 관찰예상 SID·횟수와 정상 PCAP의 불필요한 경보를 함께 본다. 다음 live 단계는 실제 캡처 위치와 drop·CPU·로그 지연을 확인한다.
• 검증 범위이 단계가 나뉘어 있으면 미탐 원인이 규칙인지 입력 가시성인지 구분하기 쉽다. 한 PCAP의 탐지 성공은 해당 입력·규칙·버전의 결과이며 전체 트래픽 성능이나 모든 변형 탐지를 보증하지 않는다.

snort -V
snort --daq-list
snort -c <설정.lua> -T
snort -q -c <설정.lua> -r <교육.pcap> -R <교육.rules> -A alert_fast

기능 확인과 저장된 교육 PCAP 분석 예입니다. 실제 명령 인수는 설치 환경에 맞게 치환합니다.