📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 120편
이전 글: 119. TCP 헤더와 Flag 분석 — 포트·시퀀스·Flag·옵션 필드 읽는 법 · 다음 글: 121. TCP 3-Way Handshake 분석
1. 개념
UDP Datagram의 구조와 크기 한계는 30. UDP Datagram, UDP의 성격과 대표 서비스는 39. UDP란 무엇인가에서 다뤘습니다. 이 글은 Wireshark에서 UDP 헤더를 필드 단위로 읽고 검증하는 방법에 집중합니다. TCP 헤더 편(119. TCP 헤더와 Flag 분석 — 포트·시퀀스·Flag·옵션 필드 읽는 법)과 비교하면 필드는 적지만, 연결 정보가 없어 헤더 밖의 계산 필드가 분석에 더 중요합니다.
| 헤더 항목 | 크기 | Wireshark 필드 | 분석 시 의미 |
|---|---|---|---|
| Source Port | 2바이트 | udp.srcport | 응답을 받을 포트 |
| Destination Port | 2바이트 | udp.dstport | 받을 서비스 |
| 둘 중 하나 | — | udp.port | 방향 무관 포트 필터 |
| Length | 2바이트 | udp.length | 헤더 8 + 페이로드 |
| Checksum | 2바이트 | udp.checksum, udp.checksum.status | 오류 검출값과 검증 상태 |
Wireshark가 추가로 계산하는 필드도 함께 봅니다.
| 계산 필드 | 의미 |
|---|---|
udp.stream | 같은 주소·포트 쌍을 묶은 흐름 번호 (TCP의 tcp.stream과 같은 역할) |
udp.time_relative, udp.time_delta | 흐름 시작 이후 시간, 같은 흐름의 이전 패킷과 간격 (UDP 설정의 타임스탬프 계산 옵션 필요) |
2. 동작 원리
Wireshark가 UDP 패킷을 해석하는 순서입니다.
IP 헤더 ip.proto = 17 (IPv6는 udp 헤더로 체인 연결)
↓
UDP 헤더 8바이트 해석: srcport, dstport, length, checksum
↓ 교차 검증
udp.length vs IP가 알려 준 페이로드 길이 (ip.len − IP 헤더 길이)
↓ 불일치하면 Expert Info 경고
udp.stream 번호 부여 (주소·포트 쌍 기준)
↓ 상위 해석기 결정
① 포트 번호 기반 (대체로 낮은 포트 먼저) → ② 휴리스틱 해석기
(UDP 설정 "Try heuristic sub-dissectors first"를 켜면 순서가 반대)
↓
DNS / DHCP / NTP / QUIC / … 또는 Data- UDP에는 연결이 없으므로
udp.stream은 주소·포트 쌍이 같으면 같은 흐름으로 묶은 Wireshark의 계산입니다. 실제 "세션"이 존재한다는 뜻은 아닙니다. - 상위 프로토콜이 포트·휴리스틱으로 추정되므로 비표준 포트의 DNS는
Data로 보일 수 있습니다. 이때Analyze → Decode As로 지정해 확인합니다.
3. 주요 특징
Length 교차 검증
| 비교 | 정상 관계 | 어긋날 때 |
|---|---|---|
udp.length와 ip.len (IPv4, 옵션 없음) | udp.length = ip.len − 20 | 조작된 패킷, 캡처 잘림 |
udp.length와 ipv6.plen (확장 헤더 없음) | 두 값이 같음 | 위와 같음 |
udp.length와 페이로드 | 페이로드 = udp.length − 8 | 상위 해석 실패 |
| IP 단편의 두 번째 조각 이후 | UDP 헤더 없음 (포트 필드 없음) | 재조립 전 조각만 보고 판단하지 않기 |
Checksum 상태 (udp.checksum.status)
| 표시 | 의미 | 주의점 |
|---|---|---|
| Unverified | 검증하지 않음 | Wireshark 기본 설정은 UDP 체크섬 검증 꺼짐 |
| Good / Bad | 검증 결과 | Bad는 송신 호스트 캡처의 체크섬 오프로드인 경우가 많음 (115. IP 헤더 분석 — TTL·Flags·Fragment·Checksum 필드 읽는 법) |
| Checksum 0x0000 | IPv4에서 "체크섬 미사용" | IPv6에서는 원칙적으로 필수 (터널 등 예외 규정 있음) |
4. 예시
실습 예시 — 본인 소유 VM에서 DNS 질의를 발생시켜 UDP 헤더를 확인합니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.
sudo tcpdump -i ens33 -nn -w /tmp/udp.pcapng udp &
dig @192.168.10.1 example.com # Rocky: bind-utils, Ubuntu: dnsutils(bind9-dnsutils) 패키지
dig @192.168.10.1 example.org AAAA
sudo pkill -INT tcpdump
# 헤더 필드와 IP 길이
tshark -r /tmp/udp.pcapng -T fields -E header=y \
-e frame.number -e udp.stream -e ip.src -e udp.srcport -e ip.dst -e udp.dstport \
-e ip.len -e udp.length -e udp.checksum.status -e frame.protocols
# Length 불일치 검사 (IPv4, 옵션 없는 헤더 기준)
tshark -r /tmp/udp.pcapng -Y 'udp && ip' -T fields -e frame.number -e ip.hdr_len -e ip.len -e udp.length \
| awk '$3 - $2 != $4 {print "mismatch:", $0}'헤더 필드 추출 결과의 형식 예시입니다.
frame.number udp.stream ip.src udp.srcport ip.dst udp.dstport ip.len udp.length ...
1 0 192.168.10.20 41234 192.168.10.1 53 84 64 ... eth:ethertype:ip:udp:dns
2 0 192.168.10.1 53 192.168.10.20 41234 100 80 ... eth:ethertype:ip:udp:dns| 확인 포인트 | 읽는 법 |
|---|---|
같은 udp.stream 0 | 질의·응답이 같은 포트 쌍으로 묶임 |
udp.srcport 41234 | 클라이언트 임시 포트. 응답의 목적지 포트와 일치해야 함 |
ip.len 84, udp.length 64 | 84 − IP 헤더 20 = 64 → 정상 |
📷 [실습 화면 삽입 위치] DNS 질의 패킷의 Details에서 User Datagram Protocol을 펼쳐 Length·Checksum·
[Stream index]·[Timestamps]항목이 보이는 화면
📷 [실습 화면 삽입 위치] 비표준 포트 UDP가 Data로 표시될 때 Decode As 창에서 해석기를 지정하는 화면
5. 보안 관점
| 관찰 | 가능한 해석 | 확인할 것 |
|---|---|---|
| 요청 없이 도착한 응답(출발지 53·123·161 등) 대량 | 위조된 출발지로 인한 반사·증폭 공격의 피해 측 흔적 | 같은 udp.stream에 우리 쪽 요청이 있는가 |
작은 요청에 비해 응답 udp.length가 매우 큼 | 증폭에 악용 가능한 서비스 노출 | 외부에서 해당 포트 응답 허용 여부 |
| 서비스 포트(53 등)가 출발지인데 해석이 Data | 포트를 위장한 다른 프로토콜 | 페이로드 바이트 (106. Packet Bytes 구조) |
| 한 출발지가 여러 UDP 포트로 짧게 전송 | UDP 포트 스캔 | ICMP Port Unreachable 응답 (117. ICMP 패킷 분석 — Type·Code와 오류 메시지 속 원본 헤더 읽기) |
| Length 불일치, 체크섬 Bad 반복(SPAN 캡처) | 조작된 패킷, 장비 이상 | 캡처 지점, 반복 출발지 |
6. SOC 관점
| 흔적 위치 | 확인할 수 있는 것 |
|---|---|
| 패킷 캡처 | 포트 쌍, udp.length, 요청·응답 대응, 상위 프로토콜 |
| 방화벽 로그 | UDP 세션(타임아웃 기반) 허용·차단, 응답 트래픽 수 |
| IDS/IPS | 증폭·스캔·비정상 길이 관련 이벤트 |
| NetFlow | 흐름별 바이트 비율 (요청 대비 응답 크기) |
관제자가 확인할 질문
- 이 UDP 흐름은 요청과 응답이 짝을 이루는가, 한 방향뿐인가?
- 목적지 포트와 실제 해석된 프로토콜이 일치하는가?
- 요청 대비 응답 크기 비율이 서비스 특성상 설명되는가?
오탐 주의: Syslog·NetFlow 수집, 스트리밍처럼 원래 한 방향으로만 흐르는 UDP 서비스가 많습니다. 또 체크섬 Bad는 오프로드, Length 이상은 캡처 길이 제한(snaplen)이 원인인 경우가 흔하므로 frame.cap_len과 캡처 지점을 먼저 확인합니다. UDP 기반 서비스별 분석은 135. DNS Packet 분석, 136. DHCP Packet 분석에서 이어집니다.
7. 핵심 정리
- UDP 헤더는
udp.srcport·udp.dstport·udp.length·udp.checksum네 필드이며, 필터에는udp.port를 함께 씁니다. udp.length는 헤더 8바이트를 포함한 길이이고, IP 페이로드 길이와 일치하는지 교차 검증합니다.- UDP 체크섬은 기본적으로 검증되지 않으며(Unverified), Bad 표시는 오프로드 영향부터 확인합니다.
udp.stream은 주소·포트 쌍으로 묶은 계산 값이고, 상위 프로토콜은 포트·휴리스틱 추정이므로 Decode As로 검증합니다.- 요청 없는 응답, 과도한 응답 크기, 포트와 다른 해석 결과는 반사·증폭·위장 통신의 단서가 됩니다.
