137. HTTP Packet 분석

📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 137편
이전 글: 136. DHCP Packet 분석 · 다음 글: 138. HTTPS Traffic 이해

1. 개념

HTTP 메시지 구조와 주요 헤더의 의미는 61. HTTP 요청·응답 구조, 메서드·상태 코드 기반 이상 징후는 145. HTTP 메서드와 상태코드로 보는 이상징후에서 다룹니다. 이 글은 평문 HTTP가 Wireshark에서 어떤 필드로 해석되고, 그것으로 요청·응답을 짝지어 추출하는 방법에 집중합니다.

영역	Wireshark 필드	읽는 내용
구분	http.request, http.response	요청·응답 패킷 여부
요청줄	http.request.method, http.request.uri, http.request.version	메서드, 경로, 버전
전체 URL	http.request.full_uri	Host와 URI를 합친 계산값
요청 헤더	http.host, http.user_agent, http.referer, http.cookie	대상 호스트, 클라이언트 식별 문자열
응답	http.response.code, http.response.phrase, http.server, http.location	상태, 서버 표시, 리다이렉트 위치
본문	http.content_type, http.content_length, http.file_data	형식, 길이, 본문 데이터

계산 필드입니다.

계산 필드	의미
http.response_in	(요청 패킷에) 응답이 있는 프레임
http.request_in	(응답 패킷에) 원래 요청 프레임
http.time	요청부터 응답까지 걸린 시간

---

2. 동작 원리

TCP 페이로드 (기본 포트 80, 8080 등)
   ↓ TCP 재조립 (설정: Allow subdissector to reassemble TCP streams)
헤더 끝(빈 줄)까지 모음 → Content-Length / chunked 기준으로 본문까지 모음
   ↓
HTTP 해석: 요청줄 / 상태줄 / 헤더 / 본문
   ↓ gzip 등 Content-Encoding → 압축 해제 표시
같은 tcp.stream 안에서 요청 순서대로 응답 매칭
   → request_in / response_in / http.time

• 재조립이 켜져 있으면 HTTP 메시지는 마지막 세그먼트 프레임에 표시되고, 앞 세그먼트는 [TCP segment of a reassembled PDU]로 보입니다.
• Keep-Alive 연결에서는 한 tcp.stream에 요청·응답이 여러 쌍 들어 있으므로, 스트림이 아니라 http.request_in으로 짝을 확인합니다.
• 기본 포트 목록에 없는 포트의 HTTP는 Data로 보일 수 있습니다. 휴리스틱으로 잡히지 않으면 Decode As로 지정합니다.

---

3. 주요 특징

요청·응답 짝으로 판단하는 것

요청	응답	읽는 법
GET 스크립트 경로 + 공격 문자열	404 / 403	시도했으나 대상 없음·차단
같은 요청	200 + 큰 content_length	결과 반환 가능성, 본문 확인 필요
POST 로그인 경로	302 + http.location	인증 성공 후 이동 흔한 형태 (단정 불가)
요청만 있고 response_in 없음	—	응답 전 끊김, 캡처 누락, 인라인 차단

자주 쓰는 Display Filter

필터	용도
http.request.method == "POST"	데이터 전송 요청
http.response.code >= 400	오류 응답
http.request && !http.response_in	응답 없는 요청
http.time > 3	3초 이상 지연된 응답
http.user_agent contains "curl"	스크립트·도구 요청
http.content_type contains "application/x-dosexec"	실행 파일로 표시된 응답 (서버가 지정한 값일 뿐)
http.request && !(tcp.dstport == 80)	비표준 포트 HTTP

---

4. 예시

실습 예시 — 본인 소유 VM의 웹 서버(nginx)에 정상 요청과 없는 경로 요청을 보내 캡처합니다. 명령과 출력은 예시(값은 환경마다 다름)입니다.

sudo tcpdump -i ens33 -nn -w /tmp/http.pcapng 'tcp port 80' &
curl -s http://192.168.10.10/ -o /dev/null
curl -s http://192.168.10.10/admin/test.php -o /dev/null
sudo pkill -INT tcpdump

# 요청 목록: 누가, 어디로, 무엇을
tshark -r /tmp/http.pcapng -Y http.request -T fields -E header=y -E separator=$'\t' \
  -e frame.number -e ip.src -e http.host -e http.request.method -e http.request.uri \
  -e http.user_agent -e http.response_in

# 응답 목록: 요청 프레임과 결과, 지연
tshark -r /tmp/http.pcapng -Y http.response -T fields -E header=y \
  -e frame.number -e http.request_in -e http.response.code -e http.content_length -e http.time

# 호스트·경로 통계
tshark -r /tmp/http.pcapng -q -z http_req,tree
tshark -r /tmp/http.pcapng -q -z http,tree

# 전송된 객체 추출 (GUI의 File → Export Objects → HTTP와 같은 기능)
mkdir -p /tmp/http_objs && tshark -r /tmp/http.pcapng -q --export-objects http,/tmp/http_objs

응답 목록의 형식 예시입니다.

frame.number http.request_in http.response.code http.content_length http.time
6            4               200                615                 0.001214
14           12              404                153                 0.000871

확인 포인트	읽는 법
프레임 14의 request_in 12	/admin/test.php 요청의 응답
404, 153바이트	경로 없음, 오류 페이지 크기
http.time	서버 처리 지연 비교 기준

📷 [실습 화면 삽입 위치] HTTP 요청 패킷 Details에서 Hypertext Transfer Protocol을 펼쳐 요청줄·Host·User-Agent·[Full request URI]·[Response in frame]이 보이는 화면

📷 [실습 화면 삽입 위치] File → Export Objects → HTTP 창에서 호스트·Content Type·크기·파일 이름 목록이 보이는 화면

---

5. 보안 관점

관찰	가능한 해석	확인할 것
URI·본문에 ../, <script, SQL 구문, 쉘 명령	웹 공격 시도	응답 코드·크기 (134. Follow TCP Stream로 원문 확인)
http.host가 IP 주소, 비표준 포트	도메인 없이 직접 접속 (악성 다운로드에서 흔함)	목적지 평판, 이전 DNS 질의 유무
Content-Type은 이미지인데 본문이 MZ로 시작	확장자·형식 위장 파일	http.file_data 앞부분, 추출 파일 해시
일정 간격으로 같은 URI에 작은 POST	비콘 형태 통신 가능성 (147. 외부 비정상 통신 분석)	요청 간격, User-Agent
특이하거나 비어 있는 User-Agent	스크립트·스캐너·악성 도구	같은 출발지의 다른 요청

---

6. SOC 관점

흔적 위치	확인할 수 있는 것
패킷 캡처	요청·응답 전체, 본문, 전송 파일
웹 서버 접근 로그	요청줄·상태·크기 (본문은 없음)
프록시·WAF 로그	차단 여부, 정책 이름
IDS	웹 공격 시그니처 이벤트 (293. Web Attack 탐지)

관제자가 확인할 질문

• 이 요청에 대한 응답은 무엇이었고, 공격이 성공했다고 볼 근거가 있는가?
• 패킷의 요청과 웹 서버 로그의 기록이 시각·경로·크기에서 일치하는가?
• 추출한 객체의 해시가 알려진 악성 파일과 일치하는가?

오탐 주의: 취약점 점검·모니터링 도구, 검색 엔진 크롤러도 이상해 보이는 URI를 많이 요청합니다. 또 http.content_type은 서버가 적어 보낸 값이므로 실제 파일 형식과 다를 수 있습니다. Export Objects로 추출한 파일은 해시만 기록하고 격리 환경 외에서 열지 않습니다.

---

7. 핵심 정리

• 평문 HTTP는 http.request.*, http.response.*, 헤더 필드, http.file_data로 해석됩니다.
• http.response_in·http.request_in·http.time으로 요청과 응답을 짝짓고, Keep-Alive 연결에서도 이 필드로 매칭합니다.
• 재조립 설정 때문에 HTTP 메시지는 마지막 세그먼트에 표시되며, 비표준 포트는 Decode As로 확인합니다.
• 공격 판단은 요청 문자열만이 아니라 응답 코드·크기와 함께 합니다.
• Export Objects와 --export-objects로 전송 파일을 추출할 수 있고, 추출물은 해시 기록 후 격리해서 다룹니다.