📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 291편
이전 글: 290. Suricata Rule 기초 · 다음 글: 292. Brute Force 탐지
1. 개념
Port Scan 탐지는 한 출발지가 짧은 시간에 여러 포트나 여러 호스트에 연결을 시도하는 정찰 행위를 찾아내는 것입니다. 스캔 유형별 패킷 특징과 흔적은 05 영역에서 자세히 다뤘습니다(216. TCP Port Scan 특징, 235. IDS에서 Scan Alert 확인). 이 글은 보안장비의 탐지 로직이 무엇을 세고, 어떤 기준으로 Alert를 내는가를 다룹니다.
스캔은 패킷 하나로는 판단할 수 없습니다. SYN 패킷 하나는 정상 연결의 시작과 같기 때문입니다. 그래서 스캔 탐지는 거의 항상 "일정 시간 안의 개수" 를 기준으로 합니다.
| 탐지 방식 | 세는 대상 | 예 |
|---|---|---|
| 임계치 규칙 | 규칙 일치 횟수(패킷·연결 수) | Suricata·Snort 규칙의 threshold·detection_filter |
| 스캔 전용 모듈 | 서로 다른 포트·호스트 수, 실패 응답 비율 | Snort sfPortscan(2) / port_scan inspector(3) |
| 흐름 집계(SIEM·NDR) | 출발지별 고유 목적지 포트·IP 수 | flow 이벤트·방화벽 로그 집계 |
2. 동작 원리
스캔 탐지 로직이 보는 신호와 판단 흐름입니다.
출발지 X의 트래픽 관찰 (시간 창: 예 60초)
↓
[개수] 새 연결 시도 수, 고유 목적지 포트 수, 고유 목적지 IP 수
↓
[결과] 연결 성립 비율 ↓, RST·ICMP Unreachable 응답 비율 ↑
↓
[패턴 분류]
├─ 한 호스트 × 많은 포트 → 수직(Vertical) 스캔
├─ 많은 호스트 × 한 포트 → 수평(Horizontal) 스캔 / 스윕
└─ 많은 호스트 × 많은 포트 → 블록 스캔
↓ 임계치 초과
Alert (출발지, 대상 범위, 개수, 시간 창)임계치 규칙의 한계를 알아야 합니다. Suricata·Snort 규칙의 threshold·detection_filter는 규칙 일치 횟수를 셀 뿐, "서로 다른 포트가 몇 개인가"를 세지는 않습니다. 따라서 한 서버에 연결을 많이 여는 정상 클라이언트도 같은 규칙에 걸릴 수 있습니다. 고유 포트 수 같은 기준은 스캔 전용 모듈이나 SIEM 집계가 더 적합합니다.
3. 주요 특징
임계치 설정은 오탐과 미탐 사이의 균형입니다.
| 설정 | 효과 | 부작용 |
|---|---|---|
| 짧은 시간 창·낮은 개수 | 빠른 스캔을 빨리 탐지 | 바쁜 서버·클라이언트 오탐 증가 |
| 긴 시간 창·높은 개수 | 오탐 감소 | 느린 스캔(Slow Scan) 미탐 |
| 외부 출발지만 대상 | Alert 양 감소 | 내부 정찰(감염 호스트) 미탐 |
| 실패 응답 비율 조건 추가 | 정상 대량 연결과 구분 | 방화벽이 응답 없이 폐기하면 판단 어려움 |
- 방향에 따라 의미가 다릅니다. 인터넷에서 오는 스캔은 일상적인 배경 소음이지만, 내부 호스트가 다른 내부 대역을 스캔한다면 침해 후 정찰일 수 있어 우선순위가 높습니다.
- 느린 스캔은 시간 창 밖으로 퍼지므로, 장시간 집계(수 시간~하루 단위 고유 포트 수)로 보완합니다(225. Slow Scan).
4. 예시
임계치 규칙으로 스캔 의심을 탐지하는 형식 예시입니다(Suricata 문법, 값은 환경마다 다름, 임계치는 환경에 맞게 조정 필요).
# 형식 예시 — 같은 출발지에서 10초 안에 SYN 패킷 30개 이상이면 기간당 1회 Alert
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL possible TCP SYN scan from external"; flow:stateless; flags:S; threshold:type both, track by_src, count 30, seconds 10; classtype:attempted-recon; sid:1001501; rev:1;)
# 형식 예시 — 내부 → 내부 방향은 더 낮은 임계치로 별도 규칙
alert tcp $HOME_NET any -> $HOME_NET any (msg:"LOCAL possible internal TCP SYN scan"; flow:stateless; flags:S; threshold:type both, track by_src, count 20, seconds 10; classtype:attempted-recon; priority:1; sid:1001502; rev:1;)분석 방법 — type both는 조건(10초에 30개)을 넘으면 그 기간에 한 번만 Alert를 남깁니다. 따라서 Alert 건수는 스캔 규모가 아닙니다. 실제 규모는 같은 출발지의 flow 이벤트나 방화벽 로그로 고유 포트·호스트 수를 세어 확인합니다.
# 실습 예시 — Alert 출발지의 고유 목적지 포트 수 (Suricata flow 이벤트, 본인 소유 실습망 기준)
sudo jq -r 'select(.event_type=="flow" and .src_ip=="203.0.113.60") | .dest_port' /var/log/suricata/eve.json | sort -u | wc -l5. 보안 관점
- 스캔 탐지의 가치는 스캔 자체보다 이후 단계와의 연결에 있습니다. 스캔한 출발지가 열린 포트에 곧바로 접속을 시도했다면 공격 준비가 진행 중일 수 있습니다.
- 공격자는 느린 속도, 무작위 순서, 여러 출발지 분산으로 임계치를 피하려 합니다. 단일 규칙보다 장기 집계와 결합해야 합니다.
- 스캔을 자동 차단할 때는 출발지 위조 가능성과 공유 IP를 고려합니다. SYN 스캔의 출발지는 위조될 수 있습니다.
6. SOC 관점
관제자가 스캔 Alert를 볼 때 확인할 질문
- 방향은 외부→내부인가, 내부→내부인가?
- 실제 대상 범위(고유 포트·호스트 수)와 열려 있던 포트(연결 성립, SYN/ACK 응답)는?
- 스캔 이후 같은 출발지가 열린 포트에 서비스 요청·로그인 시도를 했는가?
- 출발지가 승인된 점검 서버·모니터링 시스템인가?
스캔 Alert
↓ 방향·출발지 자산 확인 (점검 서버 목록 대조)
↓ 흐름·방화벽 로그로 대상 범위·성립 연결 확인
↓ 후속 활동 검색 (같은 출발지, 이후 시간대)
후속 없음 → 기록·감시
후속 있음 → 공격 단계 연계 분석 (Scan–공격 연관성)오탐 주의: 취약점 점검 도구, 네트워크 모니터링(포트 헬스체크), P2P·게임 클라이언트, 부하 분산 장비의 상태 확인은 스캔과 비슷한 패턴을 만듭니다. 이런 출발지는 억제 대상 목록으로 관리합니다. 스캔과 공격의 연결은 05 영역 245. Scan과 공격의 연관성 분석, 엔진별 설정은 237. Snort Scan 탐지, 238. Suricata Scan 탐지를 참고합니다.
7. 핵심 정리
- 포트 스캔 탐지는 일정 시간 안의 연결 시도 수, 고유 포트·호스트 수, 실패 응답 비율을 기준으로 합니다.
- 규칙의 threshold·detection_filter는 일치 횟수만 세므로 고유 포트 수 기준은 스캔 모듈이나 SIEM 집계로 보완합니다.
- 임계치는 빠른 스캔 탐지와 오탐 사이의 균형이며, 느린 스캔은 장기 집계로 보완합니다.
- 내부→내부 스캔은 침해 후 정찰일 수 있어 외부 스캔보다 우선순위가 높습니다.
- 스캔 Alert는 대상 범위, 열린 포트, 후속 활동을 확인해 공격 단계와 연결합니다.
