📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 235편
이전 글: 234. Firewall에서 Scan 흔적 찾기 · 다음 글: 236. IPS에서 Scan 차단 이벤트 확인
1. 개념
IDS의 Scan Alert는 "정찰로 보이는 트래픽 패턴이 규칙이나 스캔 탐지 모듈의 기준을 넘었다"는 알림입니다. 탐지 로직(무엇을 세고 임계치를 어떻게 잡는가)은 291. Port Scan 탐지에서 다뤘으므로, 이 글은 관제자가 스캔 Alert 한 건을 받았을 때 무엇을 확인하는가를 다룹니다.
스캔 Alert는 크게 세 종류로 들어옵니다.
| 종류 | 근거 | 예 |
|---|---|---|
| 임계치형 | 일정 시간 안 연결 시도 수 초과 | 로컬 규칙 "possible SYN scan" |
| 시그니처형 | 스캔 도구 특유의 패킷·요청 모양 | 공개 룰셋의 SCAN 범주 규칙(도구 User-Agent, 특이 플래그 조합) |
| 모듈형 | 스캔 전용 모듈의 판정 | Snort의 portscan 계열 이벤트 |
공개 룰셋에서 정찰 규칙은 보통 classtype:attempted-recon 같은 분류와 낮은~중간 우선순위를 가집니다. 즉 IDS 스스로도 스캔을 "시도" 단계로 봅니다.
2. 동작 원리
스캔 Alert 한 건의 트리아지 흐름입니다.
Scan Alert 수신
↓
[1] 필드 확인: 시각, 출발지/목적지, 포트, 규칙(sid·메시지), action
↓
[2] 방향 판단: 외부→내부 / 내부→내부 / 내부→외부
↓
[3] 실제 범위: 같은 출발지의 flow·방화벽 기록으로 고유 포트·호스트 수 산출
↓
[4] 결과: 연결이 성립(SYN/ACK 응답·데이터 교환)된 포트는?
↓
[5] 후속: 이후 같은 출발지의 다른 Alert·서비스 로그 검색
↓
판정: 배경 소음(기록) / 점검 트래픽(억제 검토) / 공격 준비(사건 전환)Alert 건수 ≠ 스캔 규모라는 점이 가장 중요합니다. 임계치 규칙은 조건을 넘을 때 기간당 한 번만 Alert를 남기도록 설정되는 경우가 많아, Alert 1건 뒤에 수천 개 포트 시도가 있을 수 있습니다. 반대로 시그니처형 규칙은 패킷마다 Alert가 나서 건수가 과장될 수 있습니다.
3. 주요 특징
Suricata EVE JSON 기준으로 스캔 Alert에서 먼저 볼 필드입니다(필드는 버전·설정에 따라 추가·변경될 수 있음).
| 필드 | 의미 | 스캔 판단에서의 용도 |
|---|---|---|
src_ip / dest_ip | 패킷의 출발지·목적지 | 방향·자산 확인 |
dest_port | Alert 패킷의 목적지 포트 | 한 포트만 보이므로 범위는 flow로 확인 |
alert.signature / alert.signature_id | 규칙 메시지와 sid | 임계치형·시그니처형 구분 |
alert.category | classtype의 설명 | 정찰 범주 여부 |
alert.action | allowed / blocked | IDS는 보통 allowed(탐지만) |
flow_id | 흐름 식별자 | 같은 흐름의 flow·기타 이벤트 연결 |
- dest_port 하나만 보고 판단하지 않습니다. 스캔 Alert의 포트는 임계치를 넘긴 "마지막 패킷"의 포트일 뿐입니다.
- 방향이 내부 → 내부인 스캔 Alert는 외부 스캔보다 훨씬 드물고, 감염 단말의 확산 준비일 수 있어 우선순위를 높입니다.
4. 예시
Suricata 스캔 Alert의 형식 예시입니다(값은 환경마다 다름, 일부 필드 생략).
{"timestamp":"2026-09-30T02:05:07.412+0900","flow_id":1293847561,"event_type":"alert",
"src_ip":"203.0.113.60","src_port":40112,"dest_ip":"192.168.20.10","dest_port":8080,"proto":"TCP",
"alert":{"action":"allowed","signature_id":1001501,"signature":"LOCAL possible TCP SYN scan from external",
"category":"Attempted Information Leak","severity":2}}실습 예시 — 본인 소유 실습 환경에서 Alert 출발지의 실제 범위와 성립 연결을 확인하는 방어 측 명령입니다.
# 1) 같은 출발지의 스캔 계열 Alert 요약
sudo jq -r 'select(.event_type=="alert" and .src_ip=="203.0.113.60") | .alert.signature' \
/var/log/suricata/eve.json | sort | uniq -c
# 2) 같은 출발지 flow 중 서버가 응답한(패킷을 돌려준) 목적지 포트
sudo jq -r 'select(.event_type=="flow" and .src_ip=="203.0.113.60" and .flow.pkts_toclient>0)
| "\(.dest_ip):\(.dest_port)"' /var/log/suricata/eve.json | sort | uniq -c | sort -rn | head닫힌 포트도 RST로 응답하므로 pkts_toclient>0만으로 열림을 단정할 수는 없습니다. 응답이 있던 포트 중 데이터가 오가거나 세션이 established였던 포트를 추려 열린 포트로 봅니다.
| 확인 결과 | 판정 | 조치 |
|---|---|---|
| 외부, 성립 연결 없음, 후속 없음 | 배경 소음 | 기록, 반복 출발지 목록 |
| 외부, 8080 성립, 이후 웹 공격 Alert | 공격 준비 | 사건 전환, 8080 노출 검토 |
| 내부 단말 → 내부 대역 | 내부 정찰 의심 | 단말 조사 요청, 에스컬레이션 |
| 승인된 점검 서버 | 점검 트래픽 | 점검 일정 확인, 억제 검토 |
5. 보안 관점
- 스캔 Alert는 대부분 차단 조치 없이 기록되지만, 공격 준비의 가장 이른 신호입니다. 이후 사건에서 "최초 접촉 시점"을 알려 주는 근거가 되므로 보관 기간을 충분히 둡니다.
- 시그니처형 스캔 규칙은 도구의 기본 설정에만 반응하는 경우가 많아, 설정을 바꾼 스캔은 임계치형·흐름 집계로만 잡힙니다.
- 스캔 Alert를 일괄 억제(suppress)하면 내부 정찰까지 가려질 수 있습니다. 억제는 출발지·방향을 좁혀서 적용합니다.
6. SOC 관점
관제자가 확인할 질문
- Alert의 규칙은 임계치형인가, 시그니처형인가? 건수와 실제 규모는 일치하는가?
- flow·방화벽 기록 기준으로 실제 대상 포트·호스트 수와 성립 연결은?
- 같은 출발지에서 다른 범주의 Alert(웹 공격, 로그인 시도)가 뒤따랐는가?
- 출발지는 승인된 점검 서버·모니터링 시스템 목록에 있는가?
오탐 주의: 취약점 점검, 자산 관리 시스템의 서비스 탐색, 로드 밸런서 헬스체크, 일부 백업·모니터링 에이전트는 스캔 규칙과 일치합니다. 같은 출발지에서 매일 같은 시각에 반복된다면 예약 작업일 가능성을 먼저 확인합니다. Alert 일반 트리아지는 283. IDS Alert를 참고합니다.
7. 핵심 정리
- 스캔 Alert는 임계치형, 시그니처형, 모듈형으로 들어오며 정찰(시도) 단계로 분류됩니다.
- Alert 건수는 스캔 규모가 아니므로 flow·방화벽 기록으로 고유 포트·호스트 수를 확인합니다.
- Alert의 목적지 포트는 마지막 패킷의 포트일 뿐이며, 성립 연결 포트가 실제 노출 정보입니다.
- 내부→내부 스캔 Alert는 감염 단말의 확산 준비일 수 있어 우선순위를 높입니다.
- 판정은 배경 소음, 점검 트래픽, 공격 준비로 나누고 후속 Alert로 연결합니다.
