Snort
스노트 · Snort 3
는 네트워크 트래픽을 재조립하고 응용 프로토콜을 해석해 규칙으로 탐지하는 엔진이다. 의 ·· 설정과 규칙 버퍼를 연결해야 일치 또는 불일치 원인을 설명할 수 있다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
로고: Cisco / Snort 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.
01무엇이고, 어떤 일을 하나
- 인터페이스나 PCAP에서 패킷을 받아 위협 조건을 평가한다.
- 정규화된 등 의미 있는 검사 버퍼를 규칙에 제공한다.
- 트래픽 사본을 감시하거나, 지원되는 인라인 경로에서 정책에 따라 통신을 차단한다.
02어떤 순서로 동작하나
- 패킷 수신
가 패킷을 엔진에 전달하고 디코딩 단계가 헤더 구조를 해석한다. 이후 규칙· 처리에서 주소·포트·프로토콜과 관점의 방향을 사용한다.
- 연결 상태 구성
· 처리가 연결 방향과 상태, 재조립된 바이트를 만든다.
- HTTP 연결
와 설정이 해당 의 서비스 해석을 연결한다. 80번 포트라는 사실만으로 정상 HTTP가 보장되지는 않는다.
- 검사 버퍼 선택
http_uri 같은 에서 정규화된 를 검사한다. 버퍼에는 요청 메서드 전체가 들어 있지 않다.
- 규칙 조건 평가
··빈도 등 조건이 맞는지 확인하고 ·와 사건 문맥을 결과에 연결한다.
- 결과 처리
선택한 로 경보를 남긴다. 실제 차단은 지원 · 경로·정책이 모두 맞아야 한다.
03먼저 알아둘 용어와 구성요소
- 인터페이스·파일·인라인 경로에서 패킷을 받는 데이터 수집 계층.
- 스트림·응용 프로토콜의 의미와 검사 버퍼를 만드는 구성 요소.
- 규칙을 식별하는 번호로 개정 번호 와 함께 관리한다.
- 이후 옵션이 검사할 논리적 데이터 영역을 선택하는 규칙 문맥.
- 규칙과 정책에서 보호할 네트워크를 나타내는 변수.
- 연결 방향과 상태 등 같은 통신에 관련된 문맥.
- 활성화한 규칙·개정·변수·예외 조건의 집합.
- ·헤더 등 HTTP 의미별로 분리한 검사 영역.
- 서비스 식별과 구성에 따라 를 적절한 에 연결하는 구성 요소.
- 바이트 순서·상태·재조립을 처리하는 문맥.
- 2에서 전처리 기능을 부르던 구성 개념으로 와 문법을 그대로 섞지 않는다.
- 로 식별한 규칙의 개정 번호.
- 의 모듈·변수·규칙 파일·출력 정책을 설정할 때 사용하는 스크립트 언어. .의 표 형태 설정은 검사 규칙의 문법과 역할이 다르다.
- 연결이 수립된 것으로 가 추적하는 상태. : 조건은 해당 연결의 트래픽에 규칙을 한정하며 사용자 로그인 성공을 뜻하지 않는다.
- 실제 패킷 전달 경로에 검사 엔진이 들어가 허용·차단을 집행할 수 있는 운용 방식. 이를 지원하는 와 배치·정책이 필요하며 복사 패킷을 보는 passive 방식과 다르다.
- 탐지 이벤트와 패킷 정보를 지정 형식·출력 경로로 기록하는 모듈. alert_fast·alert_json 등이 있으며 선택 자체가 차단 기능을 활성화하는 것은 아니다.
- Uniform Resource Identifier; 자원을 식별하는 문자열. HTTP 검사에서는 요청 대상의 경로·질의 등을 파싱하며 http_uri는 정규화한 값, http_raw_uri는 정규화 전 값을 제공한다.
- 선택한 검사 버퍼에서 지정한 바이트 패턴의 존재 또는 부재를 검사하는 규칙 옵션. ASCII 문자열·16진수 바이트를 표현할 수 있고 여러 는 거리·범위 등 다른 조건과 함께 평가된다.
- 검사 버퍼 시작을 기준으로 검색 시작 위치를 바이트 단위로 지정하는 옵션. 5라면 첫 다섯 바이트를 지난 위치부터 검색한다.
- 으로 정한 시작점부터 를 검색할 바이트 범위를 제한하는 옵션. 이 없으면 버퍼 시작이 기준이며 찾는 패턴 전체가 허용 범위에 들어가야 한다.
- 앞선 일치가 끝난 다음 위치를 기준으로 다음 검색 시작을 얼마나 이동할지 지정하는 옵션. 같은 버퍼에서의 상대 위치이며 2는 두 바이트를 건너뛴다.
- 앞선 와 연결된 상대 검색 범위의 길이를 제한하는 옵션. 로 시작점을 이동했다면 그 위치부터 지정 범위 안에 다음 패턴 전체가 들어가야 하며, 없으면 앞선 일치 직후부터 검사한다.
- 과 같은 뜻으로, 활성화한 탐지 규칙들과 적용 변수·개정·예외 조건을 함께 관리하는 집합. 단일 규칙 하나와 전체 을 구분하며 어떤 버전을 적용했는지가 탐지 결과에 영향을 준다.
SPAN 수신 위치와 TCP 플래그 규칙을 연결하기
센서 가시성을 확인한 뒤 저장된 패킷의 조건을 규칙 헤더·옵션으로 옮긴다.
실습 구성과 전제
- 와 설정을 사용하는 격리 센서, 스위치, 허가된 PCAP 작업 사본을 준비한다. 2의 .conf·실행 옵션을 그대로 섞지 않는다.
- 사진의 구성도와 프로브 캡처는 관측 배치와 규칙 조건을 비교하는 자료이며 하나의 경보 발생을 자동으로 증명하지 않는다.
복제할 방향과 센서 연결 포트를 확인한다
- source interface f1/2 both는 양방향 프레임을 복제한다는 뜻이며 destination interface f1/1은 복제본을 받는 포트다.
- 센서의 실제 캡처 NIC와 이 포트가 연결됐는지 확인한다. 설정이 맞아도 패킷이 들어오지 않으면 규칙을 평가할 수 없다.
원본 크기로 보기 ↗- 도해 오른쪽에 source f1/2 both와 destination f1/1이 표시된다.
- Snort VM 연결이 f1/1 쪽에 그려져 있다. 이는 복제 수신 구성으로, 인라인 차단 구성과 구분해야 한다.
확인 기준show monitor 출력과 센서 캡처 양쪽을 확인한다.
패킷 조건을 필요한 필드로 좁힌다
- 캡처에는 FIN·SYN·PSH·URG가 함께 있는 데이터 없는 프로브가 보인다. 이 조합과 Len=0을 규칙 조건으로 옮길 수 있다.
- 의 재전송·중복 ACK 문구는 분석 표시이며 flags 옵션의 값이 아니다. flags와 payload 길이는 각각 검사한다.
textalert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LAB unusual TCP flags"; flags:FSUP; dsize:0; sid:1000201; rev:1;)교육용 패킷 조건 예시. 규칙 일치는 이상 플래그 조합의 관찰이며 도구나 공격 성공을 확정하지 않는다.
원본 크기로 보기 ↗- 일부 행에 [FIN, SYN, PSH, URG]와 Len=0이 표시된다.
- 다른 행에는 <None> 플래그와 중복 ACK 표시가 있다. 서로 다른 조건을 하나의 룰로 무작정 합치지 않는다.
확인 기준정상 표본도 함께 넣어 경보 범위를 비교한다.
문법과 실제 일치를 별도 시험한다
- 설정 검증은 규칙을 읽을 수 있는지 확인하고, PCAP 재현은 실제 표본이 조건에 맞는지 확인한다. 검증이 성공해도 경보가 반드시 생기는 것은 아니다.
- alert_json의 rule·action·src_ap·dst_ap·pkt_num을 패킷과 연결한다. 아래 alert 규칙과 오프라인 재생은 탐지 시험이다. would_drop 같은 표시가 나오더라도 실제 인라인 통신 차단 증거와 구분한다.
shellsnort -c snort.lua -R local.rules -T snort -c snort.lua -R local.rules -r lab.pcap -A alert_json의 재현용 예시 명령이다. 사진에 나온 실행 결과를 전재한 것이 아니며, 설치에 맞는 .와 자신의 PCAP를 사용한다.
확인 기준기대 패킷 번호와 경보 를 연결하고 음성 표본의 결과도 남긴다.
실습에서 확인한 동작 원리
- 센서 배치가 규칙보다 먼저 충족해야 하는 조건이다.
- 규칙 문법·표본 일치·실제 차단은 각각 다른 증거를 요구한다.
04예제로 따라가기
- 버퍼 고정: 8바이트 ASCII 버퍼 ABC12XYZ를 가정한다. 위치는 0부터 시작하며 ABC는 0~2, XYZ는 5~7이다.
- 첫 검색: ABC에 =0·=3을 적용하면 첫 세 바이트에서 일치한다. 검색 커서는 ABC 끝 다음인 위치 3을 기준으로 한다.
- 다음 시작: 두 번째 XYZ에 =2를 적용하면 위치 3에서 두 바이트를 건너뛰어 위치 5부터 찾는다.
- 범위 판정: =3인 검색 범위에 XYZ 세 바이트가 정확히 들어오므로 조건이 맞는다. 이는 문서의 상대 범위 동작을 설명하는 무해한 표본이다.
- 실패 비교: ABC123XYZ에서는 XYZ 시작이 위치 6이어서 같은 3바이트 검색 범위에 전부 들어오지 않는다. 문자열 존재 여부만 비교한 결과와 달라진다.
05혼동하기 쉬운 점과 확인 기준
- 대상 버퍼: 패킷 원문·재조립 ·정규화 HTTP 버퍼 중 무엇을 검사했는지 먼저 확인한다. 디코딩된 값과 원시 바이트가 다를 수 있다.
- 문자 수 착시: 문자의 화면 길이를 바이트 으로 사용하지 않는다. 의 실제 바이트와 버퍼 시작점을 대조한다.
- 상태 조건: ·서비스 식별·방향·포트· 조건이 전에 맞는지 확인한다. 문자열만 PCAP에 존재해도 모든 조건은 아닐 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
Snort 3: content의 절대·상대 검색 범위
공식 ABC·EFG 예제를 기준으로 커서 위치를 직접 세고 와 을 함께 적용하는 범위를 계산한다.
- 이전 일치 마지막 바이트 다음의 커서
- 1과 3의 결합
- 위치 옵션이 없는 는 버퍼 처음부터 검색
Snort 3: alert_json과 logger 출력 예제
같은 탐지 이벤트의 rule·action·방향·패킷 필드가 어떤 출력 설정으로 기록되는지 비교한다.
- rule의 gid:: 구조
- pkt_gen과 dir로 보는 검사 문맥
- would_drop 같은 action과 실제 차단의 구분
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.