📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 134편
이전 글: 133. TCP Stream · 다음 글: 135. DNS Packet 분석
1. 개념
Follow TCP Stream은 133. TCP Stream의 스트림 하나를 골라 여러 세그먼트에 나뉜 페이로드를 순서대로 이어 붙여, 애플리케이션이 실제로 주고받은 내용처럼 보여 주는 기능입니다. 패킷 단위로는 보이지 않던 요청·응답 대화, 평문 명령, 전송된 파일의 앞부분을 한 화면에서 확인할 수 있습니다.
| 메뉴 | 대상 | 비고 |
|---|---|---|
| Analyze → Follow → TCP Stream | TCP 페이로드 원문 | 단축키 Ctrl+Alt+Shift+T |
| Follow → UDP Stream | UDP 페이로드 | udp.stream 기준 |
| Follow → TLS Stream | 복호화된 TLS 내용 | 키가 있을 때만 의미 있음 (138. HTTPS Traffic 이해) |
| Follow → HTTP Stream | HTTP 해석 결과 | 압축된 본문을 풀어서 표시 |
2. 동작 원리
선택한 패킷의 tcp.stream = N
↓
Display Filter 자동 적용: tcp.stream eq N
↓
방향별로 seq 순서에 맞춰 페이로드 정렬
├─ 재전송·중복 구간 → 한 번만 사용
└─ 캡처에 없는 구간 → "[n bytes missing in capture file]" 표시
↓
클라이언트→서버 / 서버→클라이언트를 색으로 구분해 출력- 창을 닫아도
tcp.stream eq N필터는 남습니다. Back 버튼은 이전 필터로 되돌리고, Filter Out This Stream은 이 스트림을 제외한 필터를 적용합니다. - 표시되는 것은 TCP 페이로드뿐입니다. IP·TCP 헤더 정보(TTL, 플래그, 시각)는 이 창에 없으므로 헤더 판단은 Packet List에서 합니다.
- 기본 색상은 먼저 연결을 시작한 쪽(클라이언트) 데이터가 붉은 계열, 반대쪽이 푸른 계열입니다(설정에서 변경 가능).
3. 주요 특징
창 구성 요소
| 요소 | 기능 | 분석 활용 |
|---|---|---|
| 방향 선택 | 전체 대화 / 한 방향만 | 업로드(요청)만 따로 보기 |
| Show data as | ASCII, Hex Dump, C Arrays, EBCDIC, UTF-8, Raw 등 (버전별 차이) | 바이너리는 Hex Dump, 추출은 Raw |
| Find | 문자열 검색 | 계정명, 명령어, 파일 시그니처 |
| Stream 번호 | 이전·다음 스트림으로 이동 | 같은 필터 안에서 연속 검토 |
| Save as | 현재 형식으로 저장 | Raw로 저장하면 원본 바이트 보존 |
무엇을 볼 수 있고 무엇은 못 보는가
| 트래픽 | Follow TCP Stream 결과 |
|---|---|
| HTTP (평문) | 요청줄·헤더·본문. gzip 본문은 깨져 보임 → HTTP Stream 사용 |
| FTP 제어, Telnet, SMTP (평문) | 명령과 응답 문자열 그대로 (139. FTP Packet 분석) |
| TLS, SSH | 암호화된 바이트. 초반 Handshake 일부 문자열 정도만 식별 |
| 누락 구간 있음 | missing 표시 → 이후 내용 해석 신뢰도 낮음 |
4. 예시
실습 예시 — 본인 소유 VM의 평문 HTTP 요청 캡처에서 대화를 꺼냅니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.
# 3번 스트림의 대화를 ASCII로
tshark -r /tmp/lab.pcapng -q -z follow,tcp,ascii,3
# 스트림 번호 대신 양 끝 주소로 지정
tshark -r /tmp/lab.pcapng -q -z follow,tcp,ascii,192.168.10.20:51544,192.168.10.10:80
# 바이너리 확인용 Hex 형식
tshark -r /tmp/lab.pcapng -q -z follow,tcp,hex,3
# 누락 구간이 있는 스트림 찾기
tshark -r /tmp/lab.pcapng -Y 'tcp.analysis.lost_segment' -T fields -e tcp.stream | sort -unfollow,tcp,ascii 출력의 형식 예시입니다.
===================================================================
Follow: tcp,ascii
Filter: tcp.stream eq 3
Node 0: 192.168.10.20:51544
Node 1: 192.168.10.10:80
78
GET /index.html HTTP/1.1
Host: 192.168.10.10
User-Agent: curl/8.x
Accept: */*
312
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html
...
===================================================================| 확인 포인트 | 읽는 법 |
|---|---|
| Node 0 / Node 1 | 먼저 보낸 쪽이 Node 0 |
| 들여쓰기 없는 78 / 탭 뒤 312 | 각 방향 데이터 조각의 바이트 수 (탭은 Node 1 방향) |
| 요청 다음 응답 | 한 요청에 한 응답이 짝을 이루는지 확인 |
📷 [실습 화면 삽입 위치] Follow TCP Stream 창에서 요청(붉은 계열)과 응답(푸른 계열)이 구분되어 보이고, 하단의 방향 선택·Show data as·Find가 보이는 화면
📷 [실습 화면 삽입 위치] 창을 닫은 뒤 Display Filter 입력줄에
tcp.stream eq 3이 남아 있는 Packet List 화면
5. 보안 관점
| 관찰 | 가능한 해석 | 확인할 것 |
|---|---|---|
| 평문 스트림에 계정·비밀번호 문자열 | 평문 인증 프로토콜 사용 (노출 위험) | 서비스 종류, 암호화 대체 가능 여부 |
| 요청에 쉘 명령, 인코딩된 긴 문자열 | 웹 공격·명령 실행 시도 (145. HTTP 메서드와 상태코드로 보는 이상징후) | 응답 상태·크기로 성공 여부 추정 |
응답 본문이 MZ 등 실행 파일 시그니처로 시작 | 실행 파일 다운로드 | 요청 URL, 파일 해시 |
| 비표준 포트인데 HTTP 형태 문자열 | 포트와 프로토콜 불일치 | 목적지 평판, 이전 통신 이력 |
6. SOC 관점
관제자가 확인할 질문
- 이 Alert를 발생시킨 문자열이 실제 스트림에 존재하는가? (IDS 탐지 검증)
- 요청 뒤에 서버가 어떤 응답(상태 코드·크기)을 보냈는가?
- 누락 구간 때문에 판단이 불가능한 부분은 없는가?
| 증거 처리 단계 | 주의점 |
|---|---|
| 저장 | Show data as Raw로 저장해야 원본 바이트 보존 |
| 무결성 | 원본 pcap과 추출 파일의 해시 기록 (148. pcap 증거 보존과 해시 검증) |
| 취급 | 추출한 파일은 실행하지 않고 격리된 분석 환경에서만 다룸 |
| 보고 | 스트림 번호·4-튜플·시각을 함께 기재 |
오탐 주의: IDS가 탐지한 문자열이 요청에 있더라도 응답이 404·403이면 시도에 그쳤을 가능성이 큽니다. 반대로 스트림에서 공격 문자열이 보이지 않으면 인코딩·분할 전송 때문일 수 있으므로 Hex Dump로도 확인합니다. 평문에 드러난 계정 정보는 보고서에 그대로 옮기지 않고 마스킹합니다.
7. 핵심 정리
- Follow TCP Stream은 한 연결의 페이로드를 seq 순서로 재조립해 대화 형태로 보여 주며,
tcp.stream eq N필터를 자동 적용합니다. - 헤더 정보는 보이지 않으므로 TTL·플래그·시각 판단은 Packet List에서 합니다.
- 바이너리는 Hex Dump, 증거 저장은 Raw, 압축된 HTTP 본문은 Follow HTTP Stream을 사용합니다.
[n bytes missing in capture file]이 있으면 이후 내용의 해석 신뢰도가 떨어집니다.tshark -q -z follow,tcp,ascii,N으로 명령줄에서도 같은 내용을 꺼낼 수 있고, 추출물은 해시 기록 후 격리 환경에서만 다룹니다.
