📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 236편
이전 글: 235. IDS에서 Scan Alert 확인 · 다음 글: 237. Snort Scan 탐지
1. 개념
IPS는 탐지와 동시에 트래픽을 막을 수 있으므로, 스캔 이벤트가 "탐지됨"이 아니라 "차단됨" 으로 기록됩니다. 차단 판정의 내부 처리(인라인 구조, 판정 전달)는 189. IPS 동작 구조, IPS Alert 일반은 284. IPS Alert에서 다뤘습니다. 이 글은 스캔 차단 이벤트를 보고 "무엇이 막혔고, 무엇이 막히지 않았는가"를 판단하는 방법에 집중합니다.
관제에서 흔한 실수는 "IPS가 차단했으니 종결"입니다. 차단 이벤트는 차단 시점 이후의 일부 트래픽이 막혔다는 뜻일 뿐, 그 이전에 스캔이 얻어 간 정보까지 없던 일로 만들지는 않습니다.
| 차단 단위 | 막히는 범위 | 스캔에 대한 효과 |
|---|---|---|
| 패킷 단위(규칙 일치 패킷만 drop) | 일치한 그 패킷 | 다른 포트 시도는 계속 통과할 수 있음 |
| 흐름 단위(해당 연결 이후 패킷 drop) | 그 연결 전체 | 스캔은 연결마다 새 흐름이라 효과 제한 |
| 출발지 단위(일정 시간 출발지 차단) | 그 IP의 모든 트래픽 | 스캔 중단 효과 큼, 오차단 영향도 큼 |
어느 단위로 막는지는 제품·규칙·설정에 따라 다르므로, 관제자는 자기 환경의 차단 방식을 먼저 알아야 합니다.
2. 동작 원리
임계치 기반 스캔 차단의 시간 흐름입니다.
t0 출발지 X의 연결 시도 시작 ──→ (임계치 미만) 통과
t1 ... 포트 수십 개 시도 ────────→ 통과 ★ 이 구간의 응답은 이미 공격자에게 전달
t2 임계치 초과 → 차단 규칙 동작 → 이벤트 "blocked"
t3 이후 시도 ───────────────────→ 차단 범위에 따라 drop / 일부 통과
↓
관제 확인: t0~t2 구간에 통과한 포트와 응답, 차단 범위, t3 이후 우회 시도임계치 이전 구간은 반드시 통과합니다. 임계치 규칙은 "N번째"에서 동작하므로 앞선 N-1개 시도는 막을 수 없습니다. 따라서 차단 이벤트를 받으면 같은 출발지의 차단 이전 흐름 기록을 봐야 합니다.
3. 주요 특징
- 이벤트 표시: Suricata를 IPS 모드로 운영하면 drop 동작 규칙과 일치한 Alert의
alert.action이blocked로 기록됩니다. 설정에 따라 별도의drop이벤트도 남길 수 있습니다. 다른 제품은 "Drop", "Reset", "Block" 등으로 표기합니다. - reject와 drop: 거절 응답(RST·ICMP Unreachable)을 보내는 reject 계열은 스캐너에게 "뭔가 있다"는 신호를 줄 수 있고, 조용히 버리는 drop은 스캐너에 필터링 상태로 보입니다.
- 출발지 위조: SYN 스캔은 출발지를 위조할 수 있으므로, 출발지 단위 차단은 제3자의 IP를 막는 결과가 될 수 있습니다.
| 이벤트 상태 | 의미 | 관제 해석 |
|---|---|---|
| allowed (탐지만) | 규칙 일치, 트래픽 통과 | IDS와 같은 판단 필요 |
| blocked (차단) | 일치 패킷(또는 흐름) 차단 | 차단 전·후 통과 트래픽 확인 |
| 차단 목록 등록 | 출발지 일정 시간 차단 | 차단 기간·해제 시점 기록 |
| 차단 이벤트 대량·짧은 주기 | 스캔 지속 또는 오차단 | 출발지 성격 확인 |
4. 예시
IPS 모드 Suricata의 차단 Alert 형식 예시입니다(값은 환경마다 다름, 일부 필드 생략).
{"timestamp":"2026-09-30T02:06:41.100+0900","event_type":"alert","src_ip":"203.0.113.61","src_port":44210,
"dest_ip":"192.168.20.10","dest_port":5900,"proto":"TCP",
"alert":{"action":"blocked","signature_id":1001511,"signature":"LOCAL drop excessive SYN from external","severity":2}}실습 예시 — 본인 소유 실습 환경에서 첫 차단 시각과 그 이전에 통과한 흐름을 확인하는 방어 측 명령입니다.
# 첫 차단 시각
sudo jq -r 'select(.event_type=="alert" and .src_ip=="203.0.113.61" and .alert.action=="blocked") | .timestamp' \
/var/log/suricata/eve.json | sort | head -1
# 차단 이전 통과 흐름 중 서버가 응답한 포트 (첫 차단 시각을 기준값으로 지정)
sudo jq -r --arg t "2026-09-30T02:06:41" 'select(.event_type=="flow" and .src_ip=="203.0.113.61"
and .flow.start < $t and .flow.pkts_toclient>0) | "\(.dest_ip):\(.dest_port) \(.flow.state)"' \
/var/log/suricata/eve.json | sort | uniq -c타임스탬프 문자열 비교는 같은 형식·같은 시간대일 때만 올바르므로, 시간대 표기가 섞인 환경에서는 변환 후 비교합니다.
분석 방법 — 차단 이전에 22·443이 응답했다면, 공격자는 이미 두 서비스의 존재를 알고 있습니다. 차단 이후 같은 출발지(또는 같은 대역의 다른 IP)가 22·443에 적은 횟수로 접속을 시도하는지 확인합니다. 임계치를 넘지 않는 후속 접속은 차단되지 않을 수 있습니다.
5. 보안 관점
- 스캔 차단은 정찰 비용을 높이는 것이지 정찰을 완전히 막는 것이 아닙니다. 느린 스캔과 분산 출발지는 임계치를 피합니다.
- 자동 차단은 정상 서비스를 끊을 수 있으므로, 중요 파트너·모니터링 출발지는 예외 목록으로 관리하고 예외 목록 자체를 정기 검토합니다.
- 차단 이벤트가 사라졌다고 스캔이 끝났다는 뜻은 아닙니다. 차단 목록 만료 후 재개되는지 확인합니다.
6. SOC 관점
관제자가 확인할 질문
- 이 환경의 차단 단위는 패킷·흐름·출발지 중 무엇인가?
- 첫 차단 이전에 통과해 응답을 받은 포트는?
- 차단 이후 같은 출발지나 인접 대역에서 우회 시도(속도를 낮춘 접속, 다른 IP)가 있는가?
- 차단된 출발지가 정상 사용자·파트너일 가능성은(오차단)?
IPS 차단 이벤트
↓ 차단 단위·기간 확인
↓ 첫 차단 이전 통과 흐름 조회 → 노출 포트 목록
↓ 차단 이후 우회·후속 접속 검색
노출 없음·후속 없음 → 기록 후 종결
노출 있음 → 노출 서비스 점검 요청, 후속 감시
오차단 의심 → 예외 검토·차단 해제 요청오탐 주의: 대규모 이벤트(판매 오픈, 배포) 직후 정상 사용자의 재접속이 몰리면 임계치 차단이 오동작할 수 있습니다. 차단 이벤트 급증 시 출발지가 다양하고 대상이 한 서비스에 집중되어 있다면 오차단을 먼저 의심합니다.
7. 핵심 정리
- IPS 스캔 차단 이벤트는 차단 시점 이후 일부 트래픽이 막혔다는 뜻이며, 스캔이 얻은 정보를 되돌리지 않습니다.
- 차단 단위(패킷·흐름·출발지)에 따라 스캔에 대한 효과가 크게 다릅니다.
- 임계치 이전 구간은 반드시 통과하므로 첫 차단 이전 흐름에서 노출 포트를 확인합니다.
- 출발지 위조와 공유 IP 때문에 출발지 단위 차단은 오차단 위험이 있습니다.
- 차단 이후의 우회·후속 접속을 확인한 뒤 종결합니다.
