📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 289편
이전 글: 288. Snort Rule 기초 · 다음 글: 290. Suricata Rule 기초
1. 개념
Suricata는 OISF(Open Information Security Foundation)가 개발하는 오픈소스 IDS/IPS·네트워크 보안 모니터링 엔진입니다. Snort 규칙 문법과 대부분 호환되면서, 멀티 스레드 처리와 응용 계층 메타데이터 기록을 강점으로 합니다. 설치, suricata.yaml 주요 항목, 로그 파일과 EVE 이벤트 유형은 04 영역 194. Suricata에서 다뤘습니다.
이 글은 Suricata가 어떻게 탐지하고, 그 결과가 분석에 어떤 이점을 주는가를 다룹니다.
| 탐지·분석 기능 | 의미 | 관제에서의 이점 |
|---|---|---|
| 프로토콜 자동 식별 | 포트가 아닌 트래픽 내용으로 HTTP·TLS·DNS 등 판별 | 비표준 포트 서비스도 검사 |
| 응용 계층 버퍼 | URI, Host, User-Agent, SNI, DNS 질의 등 필드 단위 검사 | 오탐 감소, 정확한 조건 |
| 프로토콜 메타데이터 기록 | Alert가 없어도 http·dns·tls·flow 이벤트 기록 | Alert 전후 맥락 확인 |
| 파일 식별·해시 | 전송 파일의 이름·유형·해시 기록(설정 시) | 파일 IOC 확인 |
| IP 평판·데이터셋 | 목록 기반 일치(iprep, dataset) | 대량 IOC 적용 |
2. 동작 원리
Suricata의 탐지 흐름을 응용 계층 중심으로 보면 다음과 같습니다.
패킷 수집 → 디코딩 → 흐름 추적 → TCP 스트림 재조립
↓
[응용 계층 식별] 첫 데이터로 프로토콜 판별 → app_proto = http / tls / dns / ...
↓
[응용 계층 파서] 필드 분리 (http.uri, http.host, tls.sni, dns.query ...)
↓ ↓
[탐지 엔진] 규칙 매칭 [로그 모듈] 메타데이터 이벤트 기록
↓ ↓
alert 이벤트 http / dns / tls / fileinfo / flow 이벤트
└───────── 같은 flow_id 로 연결 ─────────┘규칙 조치가 여러 개 일치할 때는 조치 우선순위가 적용됩니다. Suricata의 기본 순서는 pass → drop → reject → alert입니다. 즉 pass 규칙이 일치한 트래픽은 다른 drop·alert 규칙이 있어도 이후 검사를 받지 않습니다. 이 순서는 설정(action-order)으로 바꿀 수 있으나 기본값 사용이 권장됩니다.
3. 주요 특징
Snort와 비교했을 때 분석 과정에서 체감되는 차이입니다(두 엔진 모두 버전마다 기능이 추가되므로 일반적인 경향으로 봅니다).
| 항목 | Suricata | Snort |
|---|---|---|
| 기본 출력 | EVE JSON (Alert + 메타데이터) | alert_fast·alert_json 등 Alert 중심 |
| Alert 외 기록 | http·dns·tls·flow 등 풍부 | Snort 3에서 확장 중, 외부 도구와 조합하는 경우 많음 |
| 이벤트 연결 | flow_id, community_id(설정 시) | 5-tuple·시각 기준 연계가 일반적 |
| 규칙 문법 | Snort 호환 + 점 표기 sticky buffer(http.uri) | Snort 3 sticky buffer(http_uri) |
| 스캔 전용 모듈 | 없음(임계치 규칙으로 탐지) | sfPortscan / port_scan inspector |
Suricata의 anomaly 이벤트는 디코더·스트림·응용 계층 파서가 발견한 프로토콜 이상 기록입니다. 규칙 Alert와 달리 sid가 없을 수 있으며, 회피 시도나 비표준 장비의 흔적이 될 수 있습니다.
4. 예시
Alert 하나를 같은 흐름의 메타데이터로 해석하는 형식 예시입니다(값은 환경마다 다름, EVE 일부 필드).
# 형식 예시 — alert (비표준 포트의 HTTP)
{"timestamp":"2026-09-30T13:05:11.201544+0900","flow_id":77120,"event_type":"alert","src_ip":"192.168.10.62",
"dest_ip":"198.51.100.33","dest_port":8081,"app_proto":"http",
"alert":{"action":"allowed","signature_id":1001301,"signature":"LOCAL internal host HTTP to external non-standard port","severity":3}}
# 형식 예시 — 같은 flow_id의 http 이벤트
{"flow_id":77120,"event_type":"http","http":{"hostname":"198.51.100.33","url":"/update/check",
"http_user_agent":"curl/8.5.0","http_method":"GET","status":200,"length":1532}}분석 방법 — 목적지 포트가 8081이지만 app_proto가 http로 식별되었습니다. 같은 flow_id의 http 이벤트를 보면 IP 주소로 직접 접속했고(도메인 없음), User-Agent가 명령줄 도구이며, 200 응답을 받았습니다. Alert 한 줄만으로는 알 수 없는 "누가, 어떤 도구로, 성공했는가" 가 메타데이터로 보완됩니다.
실습 예시 — 특정 Alert의 flow_id로 같은 흐름의 이벤트를 모두 조회합니다(Rocky/Ubuntu 공통).
sudo jq -c 'select(.flow_id==77120) | {event_type, app_proto, http, alert: .alert.signature}' /var/log/suricata/eve.json5. 보안 관점
- 프로토콜 자동 식별 덕분에 포트를 바꾼 서비스도 검사할 수 있습니다. 반대로 식별되지 않는 사용자 정의 프로토콜은 페이로드 규칙으로만 검사됩니다.
- 메타데이터 로그는 Alert가 없는 사건의 사후 조사에 핵심 자료가 됩니다. 보관 기간과 저장 용량을 함께 설계합니다.
pass규칙이 기본 우선순위에서 가장 먼저 적용되므로, 넓은 pass 규칙은 drop 규칙까지 무력화합니다.
6. SOC 관점
관제자가 Suricata Alert를 볼 때 확인할 질문
app_proto는 무엇이며, 목적지 포트와 일치하는가? 불일치 자체가 단서인가?- 같은
flow_id의 http·dns·tls·fileinfo·flow 이벤트는 무엇을 보여 주는가? - 관련
anomaly이벤트가 있는가? 회피 시도나 파싱 실패의 흔적인가? - 이 트래픽에 일치하는 pass 규칙이나 억제 설정은 없는가?
Suricata Alert
↓ flow_id 로 메타데이터 조회
↓ app_proto·포트 일치 여부, 응답 코드·크기, 도메인·SNI
↓ anomaly 이벤트 확인
↓ community_id 또는 5-tuple·시각으로 방화벽 로그 연계오탐 주의: 업데이트 확인, 라이선스 서버 통신처럼 비표준 포트를 쓰는 정상 소프트웨어가 많습니다. User-Agent와 목적지 소유자를 확인합니다. Suricata의 스캔 탐지 설정은 05 영역 238. Suricata Scan 탐지에서 다뤘고, 규칙 문법은 290. Suricata Rule 기초에서 이어집니다.
7. 핵심 정리
- Suricata는 멀티 스레드 오픈소스 IDS/IPS 엔진으로, Snort 규칙과 대부분 호환되며 응용 계층 메타데이터 기록이 강점입니다.
- 포트와 무관한 프로토콜 식별과 응용 계층 필드 단위 검사로 정확한 탐지가 가능합니다.
- 기본 조치 우선순위는 pass → drop → reject → alert이며, 넓은 pass 규칙은 다른 규칙을 무력화합니다.
- Alert는 같은
flow_id의 http·dns·tls·flow 이벤트와 함께 볼 때 의미가 완성됩니다. anomaly이벤트는 규칙 Alert와 별개인 프로토콜 이상 기록으로, 회피 시도 확인에 활용합니다.
