📚 네트워크 · 패킷 분석 › 05. 네트워크 스캔 징후 분석 — 206편
이전 글: 205. Host Discovery · 다음 글: 207. TCP Connect Scan
1. 개념
Ping Scan(Ping Sweep) 은 IP 대역의 여러 주소에 ICMP Echo Request를 보내고, Echo Reply가 오는 주소를 살아 있는 호스트로 판단하는 탐색 방식입니다. Host Discovery 방식 중 가장 단순하고 오래된 형태입니다(205. Host Discovery).
ping 자체의 동작은 35. Ping의 동작 원리, 패킷 필드는 118. Ping Packet 분석에서 다뤘습니다. 이 글은 한 번의 ping이 아니라 대역 전체로 퍼지는 ping의 흔적만 다룹니다.
| 구분 | 일반 ping | Ping Scan |
|---|---|---|
| 목적지 수 | 1개 | 대역 전체(수십~수천) |
| 목적지당 요청 수 | 보통 여러 번(연속 확인) | 1~2번 |
| 목적 | 특정 호스트 연결 확인 | 살아 있는 호스트 목록 작성 |
| 로그 모양 | 한 쌍의 반복 | 같은 출발지, 목적지 IP만 바뀌는 수평 패턴 |
2. 동작 원리
스캔 출발지 203.0.113.45
├─ ICMP Echo Request(Type 8) → 192.168.10.1 ─→ Echo Reply(Type 0) → 살아 있음
├─ ICMP Echo Request(Type 8) → 192.168.10.2 ─→ (무응답) → 없음 또는 차단
├─ ICMP Echo Request(Type 8) → 192.168.10.3 ─→ Echo Reply(Type 0) → 살아 있음
└─ ... 192.168.10.254
↓
경계 방화벽: ICMP 허용이면 대상까지 전달, 차단이면 "ICMP Type 8 DROP" 로그 대량
↓
결과: 응답한 IP만 다음 단계(포트 스캔) 대상- 목적지 IP가 연속으로 바뀌고, 요청 간격이 매우 짧고 일정합니다.
- 경로 중간 라우터가 ICMP Destination Unreachable(Type 3, Code 1 Host Unreachable) 을 돌려보내기도 합니다. 이 응답이 많으면 존재하지 않는 주소를 대량으로 요청했다는 뜻입니다.
3. 주요 특징
패킷 길이로 보는 출처 단서
ICMP Echo의 데이터 길이는 요청을 만든 프로그램에 따라 기본값이 다릅니다. IP 전체 길이는 IP 헤더 20바이트 + ICMP 헤더 8바이트 + 데이터 길이입니다.
| 출처(기본값) | ICMP 데이터 길이 | IP 전체 길이 | 비고 |
|---|---|---|---|
| Linux ping | 56바이트 | 84바이트 | 타임스탬프 + 채움 문자 |
| Windows ping | 32바이트 | 60바이트 | 알파벳 반복 문자열 |
| 데이터 없는 Echo | 0바이트 | 28바이트 | 일반 OS ping에서는 드묾, 스캔 도구 특징으로 IDS 규칙에 쓰여 옴 |
데이터 길이는 옵션으로 바꿀 수 있으므로 보조 단서로만 씁니다. 판단의 중심은 여전히 "한 출발지 → 많은 목적지"라는 수평 패턴입니다.
- ICMP만으로는 누락이 많습니다. 많은 호스트(특히 Windows 기본 방화벽 설정)가 Echo에 응답하지 않으므로, 공격자는 Ping Scan 뒤에 TCP 기반 탐색을 추가하기도 합니다. 방어 측에서는 ICMP 스윕 뒤에 같은 출발지의 TCP 탐색이 이어지는지 봅니다.
- Echo 외의 ICMP 유형(Timestamp Request Type 13, Address Mask Request Type 17)이 섞이면 일반 ping이 아니라 탐색 목적일 가능성이 높습니다. 이 유형들은 정상 업무 트래픽에서 거의 보이지 않습니다(218. ICMP Scan).
4. 예시
실습 예시 — 본인 소유 실습망에서 Ping Scan 흔적을 확인하는 방어 측 명령입니다(Rocky/Ubuntu 공통, 값은 환경마다 다름).
# Echo Request만 캡처
sudo tcpdump -nn -i ens33 'icmp[icmptype] == icmp-echo'
# 저장된 캡처에서 출발지별 Echo Request 목적지 수와 IP 길이 분포
tshark -r /tmp/icmp.pcapng -Y 'icmp.type == 8' -T fields -e ip.src -e ip.dst \
| sort -u | awk '{c[$1]++} END {for (s in c) print c[s], s}' | sort -rn
tshark -r /tmp/icmp.pcapng -Y 'icmp.type == 8' -T fields -e ip.len | sort | uniq -c방화벽(iptables LOG) 로그 형식 예시(값은 환경마다 다름, 일부 필드 생략):
kernel: DROP IN=ens33 SRC=203.0.113.45 DST=192.168.10.1 LEN=28 PROTO=ICMP TYPE=8 CODE=0 ID=5121 SEQ=0
kernel: DROP IN=ens33 SRC=203.0.113.45 DST=192.168.10.2 LEN=28 PROTO=ICMP TYPE=8 CODE=0 ID=40211 SEQ=0
kernel: DROP IN=ens33 SRC=203.0.113.45 DST=192.168.10.3 LEN=28 PROTO=ICMP TYPE=8 CODE=0 ID=17702 SEQ=0| 관찰 | 해석 |
|---|---|
| DST만 1씩 증가 | 대역 순차 탐색(수평 패턴) |
| LEN=28 | 데이터 없는 Echo → 일반 OS ping 기본값과 다름 |
| SEQ=0, ID가 매번 다름 | 대상마다 새 요청 1회, 일반 ping의 연속 SEQ 증가와 다름 |
5. 보안 관점
- Ping Scan은 정찰의 첫 단계로, 결과가 곧 포트 스캔 대상 목록이 됩니다. 외부 대상 Echo Reply를 줄이면 노출 정보가 줄어듭니다.
- 다만 ICMP 전체 차단은 경로 MTU 탐색(Type 3, Code 4)이나 장애 진단을 방해할 수 있으므로, Echo 등 필요한 유형만 선택해 제어합니다.
- 내부 단말의 Ping Scan은 감염 단말·웜의 확산 전 탐색일 수 있으므로 외부 스윕보다 높은 우선순위로 확인합니다.
6. SOC 관점
| 흔적 위치 | 확인 내용 |
|---|---|
| 방화벽 | 같은 출발지의 ICMP Type 8 허용·차단 이벤트, 목적지 수 |
| IDS | ICMP 스윕·데이터 없는 Echo 관련 Alert |
| 패킷 캡처 | IP 길이, ID·SEQ 패턴, 라우터의 Host Unreachable 응답 |
| 모니터링 시스템 | 같은 대역에 대한 정상 ping 점검 주기 |
관제자가 확인할 질문
- 출발지가 모니터링 서버(NMS)·자산관리 서버인가? 평소 점검 주기·대상과 일치하는가?
- Echo Reply를 받은 호스트에 대해 TCP 포트 스캔이 이어졌는가?
- 내부 출발지라면 어떤 프로세스가 ICMP를 대량으로 발생시켰는가?
오탐 주의: NMS의 생존 감시, 로드밸런서 헬스체크, IP 관리(IPAM) 도구, 일부 백업·배포 솔루션은 정기적으로 대역 전체에 ping을 보냅니다. 이들은 일정한 주기와 고정된 출발지를 가지므로, 기준선과 비교하면 구분할 수 있습니다.
7. 핵심 정리
- Ping Scan은 대역 전체에 ICMP Echo Request를 보내 Echo Reply가 오는 호스트를 찾는 탐색입니다.
- 핵심 흔적은 같은 출발지에서 목적지 IP만 바뀌는 수평 패턴과 대상당 1~2회의 요청입니다.
- 데이터 없는 Echo(IP 길이 28바이트)는 OS 기본 ping과 다른 보조 단서입니다.
- Timestamp·Address Mask 같은 드문 ICMP 유형이 섞이면 탐색 목적일 가능성이 높습니다.
- NMS·IPAM의 정기 ping은 주기와 출발지가 고정되어 있으므로 기준선과 비교해 구분합니다.
