📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 104편
이전 글: 103. 패킷 캡처 원리 — NIC·Promiscuous 모드·미러링 · 다음 글: 105. Packet Details 구조
참고(01. TCP/IP 구조 이해): 23. OSI 7계층과 TCP/IP 4계층 — 계층으로 읽는 패킷 — Packet Details가 계층 순서로 펼쳐지는 이유
1. 왜 알아야 하는가
Wireshark 화면은 기본값 그대로 두면 분석에 불리한 정보를 보여 줄 때가 있습니다.
- IP 주소 대신 도메인 이름이 보이도록 설정하면, 그 이름은 분석하는 PC가 지금 조회한 결과일 수 있습니다. 사건 당시의 이름이 아닐 수 있습니다.
- 기본 시간 열은 "캡처 시작 후 경과 초"라서 다른 로그와 시각을 맞추기 어렵습니다.
- 색상 규칙은 편의 기능일 뿐인데, 검은 줄(Bad TCP)을 보고 곧바로 "공격"이라고 판단하는 실수가 생깁니다.
"실제로 어떤 패킷이 오갔는가?"에 정확히 답하려면, 화면이 무엇을 원본으로, 무엇을 해석으로 보여 주는지 구분할 수 있어야 합니다.
2. 핵심 개념
그림 1. 목록 → 상세 → 바이트 순서로 좁혀 가며 분석합니다 (실제 화면이 아닌 개념도)
2-1. 세 개의 영역
| 영역 | 보여 주는 것 | 성격 | 분석에서의 역할 |
|---|---|---|---|
| Packet List | 패킷 1개 = 1줄 요약 (번호, 시간, 주소, 프로토콜, 길이, Info) | 요약·해석 | 흐름과 순서 파악, 대상 선택 |
| Packet Details | 선택한 패킷의 계층별 필드 트리 (Frame → Ethernet → IP → TCP → ...) | 해석 | 필드 단위 확인, 필터·열 생성의 출발점 |
| Packet Bytes | 원본 바이트 (16진수 + ASCII) | 원본 | 해석이 맞는지 검증, 해석기가 모르는 데이터 확인 |
세 영역은 연동됩니다. Details에서 필드를 클릭하면 Bytes에서 해당 바이트가 강조되고, 반대로 Bytes를 클릭하면 해당 필드가 선택됩니다. 이 연동이 "이 값이 헤더의 몇 번째 바이트에 있는가"를 확인하는 가장 빠른 방법입니다.
2-2. 대괄호 필드는 Wireshark가 만든 값
Details에서 [ ]로 감싼 항목(예: [Stream index: 3], [SEQ/ACK analysis], [Time since previous frame])은 패킷에 실제로 들어 있는 값이 아니라 Wireshark가 계산·추론한 값입니다. Bytes 영역에 대응하는 바이트가 없습니다. 보고서에 쓸 때는 "원본 필드"와 "분석 도구의 계산값"을 구분해 적어야 합니다.
2-3. 시간 표시 형식
View → Time Display Format에서 바꿉니다. (메뉴 항목 이름은 Wireshark 버전에 따라 조금씩 다를 수 있습니다.)
| 형식 | 용도 |
|---|---|
| Date and Time of Day | 다른 로그(웹 로그, 방화벽 로그)와 시각 대조 |
| UTC Date and Time of Day | 시간대가 다른 장비·SIEM과 대조 |
| Seconds Since Beginning of Capture (기본값) | 캡처 내 상대 순서 파악 |
| Seconds Since Previous Displayed Packet | 필터 결과에서 요청 간격(자동화·반복 여부) 확인 |
pcap에 저장된 시각은 캡처한 호스트의 시계 기준입니다. 시간 동기화가 안 된 장비의 pcap은 다른 로그와 어긋날 수 있습니다. (17. NTP와 로그 시간 동기화)
3. 동작 원리
Wireshark가 파일을 열어 화면에 보여 주기까지의 흐름입니다.
[pcap/pcapng 파일: 원본 바이트 + 캡처 시각]
↓
[해석기(dissector) 체인]
frame → eth.type 0x0800 → ip.proto 6 → tcp.port 80 → http
↓ (포트 기반 추정 포함)
[필드 트리 생성 + 계산 필드 추가([ ] 항목, tcp.analysis.*)]
↓
[Display Filter 적용] → [Coloring Rules 적용] → [Name Resolution(설정 시)]
↓
Packet List / Packet Details / Packet Bytes여기서 중요한 점은 상위 계층 해석이 포트 번호 등으로 추정되는 경우가 있다는 것입니다. 8081처럼 기본 포트 목록에 없는 포트의 HTTP가 HTTP로 보이지 않거나, 반대로 443 포트의 비TLS 트래픽이 이상하게 해석될 수 있습니다. 이때는 Analyze → Decode As...로 해석기를 지정해 확인합니다. (포트와 서비스가 항상 일치하지 않는 이유는 02. 서비스와 포트 매핑 참고)
4. 실제 명령어 / 실습
실습 환경: 본인 소유 Linux VM (Rocky Linux 또는 Ubuntu). 인터페이스는 ens33을 예시로 사용합니다. GUI가 없는 VM이라면 pcap을 만들어 본인 PC의 Wireshark에서 엽니다.
4-1. 실습용 pcap 만들기
sudo tcpdump -i ens33 -nn -w /tmp/layout.pcap -c 300 'not port 22'
# 다른 터미널에서
curl -s -o /dev/null http://example.com
ping -c 3 192.168.10.1공개 샘플이 필요하면 Wireshark SampleCaptures에서 HTTP나 DNS 샘플을 받아 사용할 수 있습니다.
4-2. 이름 해석 끄기
View → Name Resolution에서 다음 항목을 확인합니다.
- Resolve Network Addresses: 해제 (IP → 호스트명 변환 끄기)
- Resolve Transport Addresses: 필요 시 해제 (포트 → 서비스명, 예: 443 → https)
- Resolve Physical Addresses: 선택 (MAC 앞 3바이트 → 제조사명. 로컬 DB 조회라 외부 질의는 없음)
영구 설정은 Edit → Preferences → Name Resolution에서 합니다. CLI에서는 tcpdump -nn, tshark -n으로 끕니다. 네트워크 주소 해석을 켜 두면 분석 PC가 DNS 역방향 질의를 보낼 수 있어 분석 행위가 외부로 드러날 수도 있습니다.
4-3. 시간 형식과 분석용 열 추가
View → Time Display Format → Date and Time of Day선택- Details에서 필드를 오른쪽 클릭 →
Apply as Column으로 열 추가
분석에 자주 쓰는 열 예시는 다음과 같습니다.
| 열로 추가할 필드 | 답하는 질문 |
|---|---|
tcp.stream | 이 패킷은 어느 연결(세션)에 속하는가? |
tcp.srcport / tcp.dstport | 어느 쪽이 클라이언트(임시 포트)인가? |
ip.ttl | 같은 IP인데 TTL이 다르게 들어오지 않는가? |
http.host / dns.qry.name | 어떤 이름으로 접근했는가? |
frame.time_delta_displayed | 필터 결과 패킷 간 간격이 기계적으로 일정한가? |
열 구성은 Edit → Configuration Profiles에서 프로파일로 저장해 두면 분석 목적별(웹, DNS, 스캔)로 전환할 수 있습니다.
📷 [실습 화면 삽입] Details에서
ip.ttl필드를 선택했을 때 Bytes 영역에서 해당 1바이트가 강조되는 화면
4-4. 색상 규칙 확인
View → Coloring Rules에서 기본 규칙과 각 규칙의 필터식을 볼 수 있습니다. 예를 들어 "Bad TCP" 규칙은 tcp.analysis.flags와 관련된 조건으로 정의되어 있습니다(버전에 따라 세부 조건은 다를 수 있음). View → Colorize Packet List로 색상 표시 자체를 끄고 켤 수 있습니다.
📷 [실습 화면 삽입] Coloring Rules 창에서 Bad TCP 규칙의 필터식을 확인하는 화면
5. 결과 확인
형식 예시(값은 환경마다 다름) — Packet Details의 계층 구조:
Frame 12: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface ens33
Ethernet II, Src: 00:0c:29:aa:bb:cc, Dst: 00:50:56:dd:ee:ff
Internet Protocol Version 4, Src: 192.168.10.20, Dst: 203.0.113.10
Time to Live: 64
Protocol: TCP (6)
Transmission Control Protocol, Src Port: 52344, Dst Port: 80, Seq: 0, Len: 0
[Stream index: 3]
Flags: 0x002 (SYN)같은 내용을 CLI로 확인할 수도 있습니다.
tshark -r /tmp/layout.pcap -n -V -c 1 | head -40 # Details에 해당하는 상세 출력
tshark -r /tmp/layout.pcap -n -x -c 1 # Bytes(16진수 덤프) 포함- 네트워크 주소 이름 해석을 끄고 IP로 표시되는 것을 확인했다
- 시간 형식을 Date and Time of Day(또는 UTC)로 바꿨다
- Details의 필드를 클릭해 Bytes 위치를 확인했다
-
[ ]계산 필드와 원본 필드를 구분할 수 있다 - 분석용 열(
tcp.stream,ip.ttl등)을 추가하고 프로파일로 저장했다
6. 패킷 / 로그 분석
화면 요소를 해석할 때의 판단 기준입니다.
| 화면에서 본 것 | 정상일 수 있는 경우 | 의심해야 하는 경우 |
|---|---|---|
| 검은 줄(Bad TCP) 다수 | 캡처 누락(SPAN 드롭), 캡처 시작 전부터 이어진 세션, 일시적 혼잡 | 특정 호스트에서만 RST·재전송이 집중, 비정상 플래그 조합 |
| 체크섬 오류 표시 | 송신 측 호스트 캡처 + 체크섬 오프로드(1편) | SPAN/TAP 캡처의 수신 패킷에서 반복 |
프로토콜 열이 TCP만 표시 | 해석기가 모르는 포트, 암호화 페이로드 | 잘 알려진 포트인데 기대한 프로토콜로 해석되지 않음 (21. 정상 포트로 위장한 통신) |
| 호스트 이름이 표시됨 | 이름 해석이 켜져 있음 | 분석 근거로 이름을 그대로 인용하려 함 → IP로 재확인 |
| 요청 간격이 매우 일정 | 모니터링 에이전트의 주기적 헬스체크 | 알 수 없는 외부 IP로 일정 간격 접속(비콘 형태) |
일정 간격 여부는 필터와 시간 열을 함께 써서 확인합니다.
Display Filter: ip.dst == 203.0.113.10 && tcp.flags.syn == 1 && tcp.flags.ack == 0
Time Format : Seconds Since Previous Displayed Packet
→ 간격 값이 거의 동일하게 반복되는지 확인7. 보안관제 관점
- 분석 보고서에는 IP·포트·UTC 시각·프레임 번호를 적는 것이 기본입니다. 프레임 번호가 있으면 다른 분석가가 같은 pcap에서 같은 패킷을 바로 찾을 수 있습니다.
- 흔적이 남는 곳: 분석 PC에서 이름 해석을 켜 두면 DNS 서버 로그에 분석 대상 IP에 대한 역방향 질의가 남을 수 있습니다.
- 한계: 해석기는 포트·패턴으로 프로토콜을 추정하므로 틀릴 수 있습니다. 확신이 없으면 Bytes 영역의 원본으로 검증합니다.
- 오탐 주의: 색상 규칙과 Expert Information은 "주의해서 볼 곳"을 알려 줄 뿐, 공격 판정이 아닙니다.
- 필드별 상세 해석(Ethernet, IP, TCP 헤더)은 이 시리즈 7편부터 계층 순서대로 다룹니다.
8. 핵심 정리
- Packet List는 요약, Details는 해석, Bytes만이 원본입니다. 세 영역을 연동해 해석을 검증합니다.
[ ]로 표시된 필드는 Wireshark의 계산값이며 패킷 안에 존재하지 않습니다.- 분석 전 네트워크 주소 이름 해석을 끄고, 시간 형식을 절대 시각(또는 UTC)으로 바꿉니다.
Apply as Column과 Configuration Profile로 분석 목적별 화면을 구성합니다.- 색상 규칙·체크섬 오류는 캡처 환경 영향일 수 있으므로 곧바로 공격으로 판단하지 않습니다.
다음 글: 05. Statistics로 전체 흐름 파악 — Conversations·Endpoints·Protocol Hierarchy
