📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 238편
이전 글: 237. Snort Scan 탐지 · 다음 글: 239. Wazuh Alert 분석
1. 개념
Suricata는 Snort의 sfPortscan 같은 별도의 포트 스캔 전용 모듈을 기본 기능으로 내세우지 않습니다. 대신 스캔은 두 가지 자료로 확인합니다. 하나는 스캔 계열 규칙의 Alert, 다른 하나는 모든 흐름을 기록하는 flow 이벤트입니다. Suricata 구조와 규칙 문법은 289. Suricata란 무엇인가, 290. Suricata Rule 기초에서 다뤘습니다. 이 글은 두 자료를 함께 써서 스캔을 판단하는 방법에 집중합니다.
| 자료 | 알려 주는 것 | 한계 |
|---|---|---|
| 스캔 계열 규칙 Alert | "이상하다"는 신호, 도구 특징 | 규모·결과는 모름 |
| flow 이벤트 | 모든 연결의 패킷·바이트·상태 | 스스로 Alert를 만들지 않음 |
| (선택) SIEM 집계 | 출발지별 고유 포트·호스트 수 | 수집·집계 설정 필요 |
공개 룰셋(예: ET Open)에는 메시지가 ET SCAN으로 시작하는 스캔 범주 규칙이 있으며, 특정 스캐너의 User-Agent, 특이한 TCP 옵션·플래그, 특정 서비스 포트로의 반복 접근 등을 봅니다. 규칙 목록과 내용은 룰셋 버전마다 달라지므로, Alert를 받으면 해당 sid의 규칙 본문을 직접 확인합니다.
2. 동작 원리
Suricata 환경의 스캔 판단은 Alert로 시작해 flow로 확인하는 구조입니다.
스캔 계열 Alert (event_type: alert)
↓ src_ip·시간 범위 추출
flow 이벤트 조회 (event_type: flow, 같은 src_ip)
↓
[집계] 고유 dest_port 수 / 고유 dest_ip 수 / flow.state 분포 / bytes_toclient
↓
[분류] 수직·수평·블록 / 성립 연결 유무
↓
[후속] 같은 src_ip의 http·ssh·tls 등 프로토콜 이벤트, 다른 Alert
↓
판정규칙 Alert는 흐름 단위로 flow_id를 가지므로, 같은 flow_id의 flow 이벤트와 프로토콜 이벤트(http, tls 등)를 묶어 볼 수 있습니다. 단 스캔은 수많은 짧은 흐름으로 이루어지므로, 스캔 규모는 flow_id 하나가 아니라 src_ip 기준 집계로 봅니다.
3. 주요 특징
flow 이벤트에서 스캔 판단에 쓰는 필드입니다(버전·설정에 따라 다를 수 있음).
| 필드 | 스캔에서의 의미 |
|---|---|
flow.pkts_toserver / flow.pkts_toclient | 요청만 있고 응답이 없으면 필터링, 적은 응답은 RST 가능성 |
flow.bytes_toclient | 0 또는 매우 작으면 데이터 교환 없음 |
flow.state | new·established·closed 등 연결 진행 정도 |
flow.reason | 흐름 종료 이유(타임아웃 등) |
tcp.tcp_flags 및 syn·rst 등 | 흐름에서 관찰된 TCP 플래그 |
- 억제 설정:
threshold.config의suppress는 특정 sid를 특정 IP에 대해 기록하지 않게 합니다. 점검 서버의 스캔 Alert를 줄일 때 쓰되, sid와 IP를 모두 좁혀 적용합니다. sid 전체를 억제하면 다른 출발지의 정찰까지 사라집니다. - flow 로그 양: flow 이벤트는 양이 많아 일부 환경에서는 끄거나 짧게 보관합니다. 이 경우 스캔 규모 확인은 방화벽 로그로 대체합니다.
4. 예시
억제 설정 형식 예시입니다(값은 환경마다 다름).
# 형식 예시 — 승인된 점검 서버 192.168.10.5가 만드는 sid 1001501 Alert만 억제
suppress gen_id 1, sig_id 1001501, track by_src, ip 192.168.10.5실습 예시 — 본인 소유 실습 환경에서 스캔 Alert 출발지의 범위와 흐름 상태를 집계하는 방어 측 명령입니다.
# 1) 스캔 범주(classtype 설명 기준) Alert 출발지 상위
sudo jq -r 'select(.event_type=="alert" and .alert.category=="Attempted Information Leak") | .src_ip' \
/var/log/suricata/eve.json | sort | uniq -c | sort -rn | head
# 2) 해당 출발지의 고유 목적지 포트 수와 흐름 상태 분포
sudo jq -r 'select(.event_type=="flow" and .src_ip=="203.0.113.62") | .dest_port' \
/var/log/suricata/eve.json | sort -u | wc -l
sudo jq -r 'select(.event_type=="flow" and .src_ip=="203.0.113.62") | .flow.state' \
/var/log/suricata/eve.json | sort | uniq -c결과 형식 예시(값은 환경마다 다름):
1021 ← 고유 목적지 포트 수
1014 closed
7 established ← 데이터 교환까지 간 흐름분석 방법 — 1,000개가 넘는 포트를 두드렸지만 established까지 간 흐름은 7개입니다. 이 7개 흐름의 목적지 포트와 프로토콜 이벤트(http·ssh 등)를 확인하면 공격자가 실제로 상호작용한 서비스를 알 수 있습니다. 같은 범주 이름에는 스캔 외 정보 노출 규칙도 포함될 수 있으므로 signature로 한 번 더 거릅니다.
5. 보안 관점
- Suricata 스캔 탐지는 규칙에 의존하므로, 룰셋 업데이트 주기와 활성화 범주가 탐지 범위를 결정합니다. 스캔 범주 규칙이 꺼져 있으면 임계치 로컬 규칙과 flow 집계가 유일한 수단입니다.
- flow 이벤트는 Alert가 없는 정찰(느린 스캔, 도구 특징이 없는 스캔)을 사후에 찾을 수 있는 자료입니다. 보관 정책을 사건 조사 기간에 맞춥니다.
- 억제는 편리하지만 탐지 공백을 만드는 설정입니다. 억제 목록은 사유·만료일과 함께 관리합니다.
6. SOC 관점
관제자가 확인할 질문
- Alert를 만든 규칙의 본문은 무엇을 보는가(User-Agent, 플래그, 횟수)?
- flow 기준 고유 포트·호스트 수와 established 흐름은?
- 같은 src_ip의 프로토콜 이벤트(http 요청, ssh 배너, tls SNI)는 무엇을 보여 주는가?
- 이 출발지·sid 조합이 억제 목록에 걸려 있어 일부 Alert가 빠지지 않았는가?
ET SCAN / 로컬 스캔 Alert
↓ 규칙 본문 확인 (탐지 근거)
↓ flow 집계 (범위·상태)
↓ established 흐름 → 프로토콜 이벤트 확인
↓ 같은 출발지 다른 Alert 검색
판정·기록 (억제 필요 시 sid+IP 단위로)오탐 주의: 스캔 계열 규칙 중 일부는 특정 포트로의 반복 접근만으로 동작해, 정상 클라이언트의 재접속에도 일치할 수 있습니다. 규칙 본문과 실제 흐름 상태를 대조해 판단합니다. 흐름·Alert·패킷을 함께 보는 방법은 297. IDS Alert와 Packet 연계를 참고합니다.
7. 핵심 정리
- Suricata 환경의 스캔 확인은 스캔 계열 규칙 Alert와 flow 이벤트 집계를 함께 씁니다.
- Alert는 신호, flow는 규모와 결과(고유 포트 수, established 흐름)를 알려 줍니다.
- 스캔 규모는 flow_id 하나가 아니라 src_ip 기준 집계로 판단합니다.
- established 흐름의 프로토콜 이벤트가 공격자가 실제로 상호작용한 서비스를 보여 줍니다.
- 억제는 sid와 IP를 좁혀 적용하고 사유·만료일을 관리합니다.
