📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 118편
이전 글: 117. ICMP 패킷 분석 — Type·Code와 오류 메시지 속 원본 헤더 읽기 · 다음 글: 119. TCP 헤더와 Flag 분석 — 포트·시퀀스·Flag·옵션 필드 읽는 법
1. 개념
ICMP의 Type·Code와 Echo 필드(icmp.ident, icmp.seq, icmp.resp_in 등)의 뜻은 117. ICMP 패킷 분석 — Type·Code와 오류 메시지 속 원본 헤더 읽기에서, ping 프로그램이 RTT와 손실률을 계산하는 원리는 35. Ping의 동작 원리에서 다뤘습니다. 이 글은 ping 실행 한 번이 만든 패킷 묶음 전체를 분석 단위로 삼습니다.
| 분석 단위 | 묶는 기준 | 답하는 질문 |
|---|---|---|
| 요청-응답 한 쌍 | 같은 Identifier + 같은 Sequence | 이 요청은 응답을 받았나? RTT는? |
| ping 세션 하나 | 같은 출발지·목적지 + 같은 Identifier | 몇 개를 보내고 몇 개를 잃었나? 간격은? |
| 여러 세션 | 출발지 기준 | 한 호스트가 어떤 대상들에 ping을 보냈나? |
2. 동작 원리
Wireshark는 Identifier와 Sequence로 요청과 응답을 짝짓고 결과를 계산 필드로 붙입니다.
Frame 10 Echo Request id=0x1a2b seq=1 → [Response frame: 11] (icmp.resp_in)
Frame 11 Echo Reply id=0x1a2b seq=1 → [Request frame: 10] (icmp.resp_to)
[Response time: 0.52 ms] (icmp.resptime)
Frame 12 Echo Request id=0x1a2b seq=2 → [No response seen] (icmp.no_resp)
Frame 13 Echo Request id=0x1a2b seq=3 → [Response frame: 14]
↓
세션 요약: 요청 3, 응답 2, 손실 1(seq=2), RTT = 응답 쌍의 icmp.resptime- Linux
ping은 실행할 때마다 다른 Identifier를 쓰는 경우가 많아 Identifier가 세션 구분 키가 됩니다. Windowsping은 Identifier가 고정값처럼 보이고 Sequence가 실행을 넘어 계속 증가하는 모습이 자주 관찰됩니다(버전에 따라 다를 수 있음). icmp.no_resp는 캡처 안에서 응답을 찾지 못했다는 뜻입니다. 응답이 다른 경로로 돌아와 센서가 못 봤을 가능성도 포함됩니다.- IPv6 ping은 ICMPv6 Type 128(요청)·129(응답)이며, 필드는
icmpv6.echo.identifier,icmpv6.echo.sequence_number입니다.
3. 주요 특징
데이터 부분으로 송신 도구 추정하기 (data.len, data.data)
| 송신 측 | 기본 데이터 크기 | 데이터 패턴 (일반적인 경우) |
|---|---|---|
| Linux (iputils) | 56바이트 | 앞부분 송신 시각(icmp.data_time), 이후 1씩 증가하는 바이트 (ASCII로 !"#$%&'()*+,-./01234567처럼 보임) |
| Windows | 32바이트 | abcdefghijklmnopqrstuvwabcdefghi |
| 네트워크 장비·모니터링 도구 | 제품마다 다름 | 0으로 채움, 고정 문자열 등 |
세션 단위로 계산하는 지표
| 지표 | 계산 방법 | 이상 신호 |
|---|---|---|
| 손실률 | icmp.no_resp 요청 수 ÷ 전체 요청 수 | 특정 시간대에만 손실 집중 |
| RTT 분포 | 응답 패킷의 icmp.resptime | 평소보다 큰 값, 큰 변동 |
| 전송 간격 | 요청 간 frame.time_delta_displayed | 1초보다 훨씬 짧은 간격 (flood 형태) |
| 중복 응답 | 같은 seq에 응답 2개 이상 | 중복 IP, 브로드캐스트 ping |
| 응답 TTL | 응답의 ip.ttl | 같은 대상인데 TTL이 달라짐 (응답 장비 변경) |
| 요청·응답 데이터 일치 | 요청과 응답의 data.data 비교 | 응답 데이터가 요청과 다름 (정상 Echo는 그대로 돌려줌) |
4. 예시
실습 예시 — 본인 소유 실습망에서 ping을 실행하고 세션을 분석합니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.
# 캡처 (Rocky/Ubuntu 공통)
sudo tcpdump -i ens33 -nn -w /tmp/ping.pcapng 'icmp or icmp6'
# 다른 터미널: 기본 ping 1회, 큰 데이터 + DF 설정 1회 (Linux)
ping -c 5 192.168.10.1
ping -c 2 -s 1472 -M do 192.168.10.1
# 1) 요청-응답 쌍: -2(2-pass)로 뒤쪽 응답 프레임까지 연결
tshark -r /tmp/ping.pcapng -2 -Y 'icmp.type == 8' -T fields -E header=y \
-e frame.number -e ip.src -e ip.dst -e icmp.ident -e icmp.seq -e ip.len -e icmp.resp_in -e icmp.no_resp
# 2) 응답 쪽 RTT와 TTL
tshark -r /tmp/ping.pcapng -2 -Y 'icmp.type == 0' -T fields \
-e icmp.ident -e icmp.seq -e icmp.resp_to -e icmp.resptime -e ip.ttl
# 3) 세션(출발지·목적지·Identifier)별 요청 수와 응답 없는 요청 수
tshark -r /tmp/ping.pcapng -2 -Y 'icmp.type == 8' -T fields \
-e ip.src -e ip.dst -e icmp.ident -e icmp.no_resp \
| awk '{k=$1" "$2" "$3; n[k]++; if ($4!="") l[k]++} END {for (k in n) print k, n[k], l[k]+0}'1)번 결과의 형식 예시입니다.
frame.number ip.src ip.dst icmp.ident icmp.seq ip.len icmp.resp_in icmp.no_resp
1 192.168.10.20 192.168.10.1 0x1a2b 1 84 2
3 192.168.10.20 192.168.10.1 0x1a2b 2 84 4
...
11 192.168.10.20 192.168.10.1 0x1a2c 1 1500 12| 확인 포인트 | 읽는 법 |
|---|---|
Identifier 0x1a2b → 0x1a2c | ping 실행이 두 번 → 세션 2개 |
ip.len 84 / 1500 | 데이터 56 + ICMP 8 + IP 20 = 84, 데이터 1472일 때 1500 (이더넷 MTU를 꽉 채움) |
icmp.resp_in 비어 있고 icmp.no_resp 존재 | 캡처 안에서 응답 없음 |
Linux ping은 Wireshark가 데이터 앞 8바이트를 송신 시각(icmp.data_time)으로 따로 해석하는 경우가 많아, 이때 data.len은 56이 아니라 48로 나옵니다. 크기 비교는 ip.len으로 하는 편이 헷갈리지 않습니다. icmp.seq 값이 1/256처럼 두 가지로 보이는 이유(빅·리틀 엔디언)는 117. ICMP 패킷 분석 — Type·Code와 오류 메시지 속 원본 헤더 읽기을 참고합니다.
📷 [실습 화면 삽입 위치] Echo Request의 Details에서 Identifier·Sequence와
[Response frame], Data 부분의 증가 바이트 패턴이 보이는 화면
📷 [실습 화면 삽입 위치] 필터
icmp.type == 0에icmp.resptime,ip.ttl열을 추가해 RTT를 비교한 Packet List
5. 보안 관점
| 관찰 | 정상일 수 있는 경우 | 추가 확인이 필요한 경우 |
|---|---|---|
| 한 출발지가 대역 전체에 짧은 간격으로 요청 | 자산 관리·모니터링 시스템 | 등록되지 않은 호스트의 Ping Sweep (05 영역에서 다룸) |
| 데이터가 기본 패턴과 다르고 매번 내용이 바뀜 | 일부 진단 도구 | 데이터에 명령·파일 조각을 싣는 ICMP 터널 형태 |
| 짧은 간격 대량 요청 | 부하 테스트 | ICMP Flood |
| 응답 데이터가 요청과 다름 | 드묾 | 응답을 가장한 데이터 전달 |
ICMP 터널링과 비정상 외부 통신의 판단은 147. 외부 비정상 통신 분석에서 다룹니다.
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 패킷 캡처 | 세션별 요청·응답 수, 데이터 크기·내용, 간격, 응답 TTL |
| 방화벽 로그 | ICMP 허용·차단, 외부로 나간 Echo Request |
| IDS/IPS | 큰 ICMP 데이터, 비정상 패턴, Ping Sweep 임계치 이벤트 |
| NetFlow | ICMP 흐름의 바이트·패킷 수 (데이터 내용은 없음) |
관제자가 확인할 질문
- 요청을 보낸 호스트는 ping을 보낼 업무상 이유가 있는 자산인가?
- 데이터 크기·패턴이 해당 OS의 기본값과 일치하는가? 다르다면 어떤 도구인가?
- 외부로 향한 ICMP의 총 데이터량이 일반적인 진단 수준을 넘는가?
오탐 주의: 모니터링 시스템과 로드밸런서 헬스체크는 짧은 주기로 많은 대상에 ping을 보냅니다. 또 센서가 한 방향만 보면 정상 ping도 icmp.no_resp로 표시됩니다. 출발지 자산 정보와 캡처 지점을 먼저 확인합니다.
7. 핵심 정리
- ping 분석의 단위는 요청-응답 쌍(Identifier + Sequence)과 세션(출발지·목적지 + Identifier)입니다.
icmp.resp_in·icmp.resp_to·icmp.resptime·icmp.no_resp는 계산 필드이므로 tshark에서는-2와 함께 추출합니다.- 세션별 손실률, RTT 분포, 전송 간격, 중복 응답, 응답 TTL을 계산해 네트워크 상태와 이상 여부를 판단합니다.
- 데이터 크기·패턴(Linux 56바이트 증가 바이트, Windows 32바이트 알파벳)으로 송신 도구를 추정할 수 있습니다.
- 기본값과 다른 데이터, 대량·장시간 ICMP는 터널링·Flood 가능성을 검토하되 모니터링 트래픽을 먼저 배제합니다.
