193. Snort

About this offer

📚 네트워크 · 패킷 분석 › 04. 네트워크 장비 실습 — 193편 이전 글: 192. IDS Rule · 다음 글: 194. Suricata 1. 개념 Snort 는 1998년에 공개된 오픈소스 네트워크 IDS/IPS 엔진으로, 현재는 Cisco(Talos)가 개발을 이끌고 있습니다. 규칙 기반 탐지의 사실상 표준 문법을 만든 도구여서, 다른 엔진(Suricata 등)도 Snort 규칙 문법을 대부분 호환합니다. 현재 운영 환경에서는 Snort 2(2.9.x) 와 Snort 3 두 세대가 함께 쓰입니다. Snort 3는 내부 구조를 새로 설계한 버전이라 설정 파일 형식과 운영 방식이 크게 다릅니다. Snort의 탐지 개념과 규칙 작성은 06 영역 287. Snort란 무엇인가 · 288. Snort Rule 기초 에서 다루며, 이 글은 설치·구성·실행 구조 를 다룹니다. 항목 Snort 2 (2.9.x) Snort 3 처리 구조 프로세스당 단일 패킷 처리 스레드 여러 패킷 스레드 지원( -z ) 주 설정 파일 snort.conf (자체 문법) snort.lua (Lua 문법) 프로토콜 처리 전처리기(preprocessor) inspector 패킷 수집 DAQ 2.x LibDAQ 3.x (별도 프로젝트) 설정 변환 — snort2lua 도구로 Snort 2 설정 변환 규칙 문법 Snort 2 문법 대부분 호환 + 확장(sticky buffer 등) 2. 동작 원리 Snort 3의 구성 요소 흐름입니다. [NIC] → LibDAQ 모듈 (pcap / afpacket / nfq 등) ↓ 패킷 스레드 1..N (-z 옵션으로 개수 지정) ↓ Codec: 링크·네트워크·전송 계층 디코딩 ↓ Inspector: stream(재조립), http_inspect, dns 등 프로토콜 분석 ↓ Detection: 규칙 매칭 (ips 모듈에 적재된 규칙) ↓ Logger: alert_fast, alert_full, alert_json 등 → 로그 디렉터리(-l) Snort 2는 같은 역할을 "전처리기 → 탐지 엔진 → 출력 플러그인" 순서로 수행합니다. Snort 2 시절에는 unified2 바이너리 출력을 Barnyard2 같은 별도 도구로 읽어 DB·SIEM에 넣는 구성이 많았고, Snort 3에서는 alert_json 같은 텍스트 기반 출력을 수집 도구로 바로 읽는 구성이 늘었습니다. 3. 주요 특징 설치 방식에 따라 파일 위치가 달라지므로, 센서마다 실제 경로를 먼저 확인해야 합니다. 설치 방식 설정 파일 위치(일반적인 경우) 로그 위치 Ubuntu apt install snort (Snort 2 계열 패키지) /etc/snort/snort.conf /var/log/snort/ Snort 3 소스 빌드(기본 prefix /usr/local ) /usr/local/etc/snort/snort.lua , snort_defaults.lua -l 로 지정한 디렉터리 Rocky 기본 저장소에 패키지가 없는 경우가 많아 소스 빌드가 일반적 빌드·실행 옵션에 따름 배포판 패키지가 제공하는 Snort 버전은 배포판 릴리스마다 다르므로 snort -V 로 반드시 확인합니다. 자주 쓰는 실행 옵션입니다(Snort 3 기준). 옵션 의미 -c 파일 설정 파일 지정 (입력 없이 실행하면 설정 검사 후 종료) -R 파일 추가 규칙 파일 적재 -i 인터페이스 / -r 파일 실시간 인터페이스 / pcap 파일 입력 -A 모드 Alert 출력 방식 (예: alert_fast, alert_json) -l 디렉터리 로그 출력 디렉터리 -Q 인라인(IPS) 모드, DAQ가 인라인을 지원해야 함 4. 예시 실습 예시 — 센서 VM에서 Snort 버전을 확인하고 설정을 검사한 뒤 실행하는 흐름입니다. 경로는 설치 방식별 예시(값은 환경마다 다름)입니다. # 버전 확인 (Snort 2인지 3인지 먼저 구분) snort -V # Snort 3: 설정 검사 (입력 소스 없이 -c 만 주면 검사 후 종료) snort -c /usr/local/etc/snort/snort.lua # Snort 3: 로컬 규칙을 추가로 적재해 인터페이스 감시, Alert는 한 줄 형식으로 파일 기록 sudo mkdir -p /var/log/snort sudo snort -c /usr/local/etc/snort/snort.lua -R /usr/local/etc/rules/local.rules \ -i ens33 -A alert_fast -l /var/log/snort -s 65535 -k none # Snort 2 (Ubuntu 패키지): 설정 검사 모드 sudo snort -T -c /etc/snort/snort.conf -k none 은 체크섬 검사를 끄는 옵션입니다. 가상 NIC 오프로딩 때문에 체크섬이 틀린 패킷으로 보이면 엔진이 해당 패킷을 무시할 수 있어 실습 환경에서 자주 사용합니다. # 형식 예시 (값·세부 형식은 버전마다 다름) — alert_fast 한 줄 09/30-10:15:32.123456 [**] [1:1000001:1] "LOCAL ICMP echo request to HOME_NET" [**] [Priority: 0] {ICMP} 192.168.10.50 -> 192.168.10.21 [1:1000001:1] 은 gid:sid:rev 입니다. Snort 3 소스 빌드는 systemd 서비스 파일을 따로 만들어야 부팅 시 자동 실행됩니다. 📷 [실습 화면 삽입 위치] snort -V 로 확인한 버전 정보와, 설정 검사 후 "Snort successfully validated the configuration" 류의 완료 메시지가 출력된 화면 5. 보안 관점 Snort 2와 3은 설정 형식이 달라 설정 파일을 그대로 옮길 수 없습니다. 업그레이드 시 snort2lua 변환 결과를 검토하지 않으면 일부 탐지 기능이 빠질 수 있습니다. Snort 2는 처리 스레드가 하나라 고속 회선에서는 여러 프로세스로 나눠 운영해야 하며, 부족하면 드롭이 생깁니다. 센서 프로세스는 root로 시작하더라도 가능하면 전용 계정으로 권한을 낮춰( -u , -g ) 실행합니다. 패킷 파서 취약점이 있을 때 피해를 줄이기 위해서입니다. 규칙 갱신(PulledPork 계열)과 엔진 업데이트를 분리해서 관리합니다( 190. Signature Detection ). 6. SOC 관점 관제자가 확인할 질문 이 Alert를 만든 센서는 Snort 2인가, 3인가? 버전에 따라 출력 형식과 필드 이름이 다릅니다. 센서 로그 디렉터리의 Alert 파일이 계속 갱신되고 있는가? 프로세스가 멈춰도 마지막 파일은 남아 있어 정상처럼 보일 수 있습니다. Snort Alert의 gid 가 1이 아니라면 규칙이 아니라 inspector(전처리기)가 만든 이벤트일 수 있습니다. Snort Alert 수신 ↓ gid 확인 → 1: 텍스트 규칙 / 그 외: inspector·디코더 이벤트 ↓ sid·rev로 규칙 원문 확인 ↓ 같은 5-tuple의 방화벽·흐름 로그와 대조 오탐 주의 : 실습 환경에서 체크섬 오프로딩 때문에 생기는 디코더 이벤트는 공격 징후가 아닙니다. 스캔 탐지 설정은 05 영역 237. Snort Scan 탐지 에서 다룹니다. 7. 핵심 정리 Snort는 규칙 문법의 표준을 만든 오픈소스 IDS/IPS 엔진이며, 현재 Snort 2와 Snort 3가 함께 쓰입니다. Snort 3는 멀티 스레드, Lua 기반 snort.lua , inspector, LibDAQ 3 구조로 Snort 2와 운영 방식이 다릅니다. 설정·로그 경로는 설치 방식(배포판 패키지, 소스 빌드)에 따라 다르므로 snort -V 와 실행 옵션으로 확인합니다. -c 로 설정 검사, -R 로 규칙 추가, -A · -l 로 Alert 출력 방식과 위치를 정합니다. Alert의 gid:sid:rev 로 규칙 이벤트와 inspector 이벤트를 구분합니다.