분석 · 관제핵심 · 14분 읽기
Wireshark로 패킷과 흐름 읽기
패킷 분석은 한 줄의 색상이나 경고보다 시간 순서와 양방향 흐름을 읽는 작업이다. 캡처 지점의 한계부터 확인한다.
개념부터 찾아보기
정의·역할·동작 원리를 독립 페이지에서 확인하세요. 본문의 밑줄 용어에도 설명이 있습니다.
이 노트에서 설명할 수 있게 되는 것
- 캡처 위치·시간·드롭이 분석 결과에 미치는 영향을 설명한다.
- TCP 시퀀스·ACK·재전송과 애플리케이션 메시지를 구분한다.
- 패킷 번호를 서버 로그의 요청 증거에 연결한다.
먼저 알면 좋은 개념로그 읽기: 사건·시간·주체 연결
01개념과 구성 요소
- 캡처 자료패킷 목록·프로토콜 트리·원시 바이트는 같은 입력을 서로 다른 수준으로 보여 준다.
- 흐름주소·포트·프로토콜과 방향·시간을 연결하면 개별 패킷을 통신 상태로 읽을 수 있다.
- 한계캡처 위치·필터··손실··암호화가 관찰 범위를 제한한다.
02TCP 연결을 패킷에서 읽는 순서
- 입력 범위 확인인터페이스·캡처 위치·필터·시간 범위와 누락 가능성을 먼저 확인한다.
- 양방향 연결 묶기과 반대 방향을 연결하고 전후·재사용 포트·별도 실행의 흐름을 구분한다.
- 상태 추적·순서 번호로 연결 시작과 바이트 진행을 읽고 ·를 종료 맥락과 연결한다.
- 재조립과 응용 해석재전송·순서 뒤바뀜·분할을 반영해 바이트 스트림과 HTTP· 등 의미를 읽는다.
- 다른 증거와 대조서버 로그·경보·시간 정보를 연결한다. 응답 상태와 실제 업무 성공 또는 공격 성공은 별도로 검증한다.
03패킷 목록·프로토콜 트리·원시 바이트
- 세 화면패킷 분석 화면의 목록은 시각·주소·프로토콜·요약을 보여 주고, 상세 트리는 캡처 바이트를 ·IP··HTTP 같은 구조로 해석한 결과다. 원시 바이트 영역은 그 해석의 근거를 제공한다.
- Info의 한계표시된 Info 문장은 도구의 해석이며 원래 회선에 그대로 존재하는 별도 필드가 아니다.
- 계층 해석하나의 프레임 안에 IP 패킷과 세그먼트가 담길 수 있지만 캡처 형식·링크 종류·터널링에 따라 구조가 달라진다. 관찰 인터페이스, 링크 타입, 캡처 길이, 손실 지표를 먼저 이해해야 화면에 없는 바이트를 원래 전송되지 않은 것으로 오해하지 않는다.
04Capture Filter와 Display Filter
- 캡처·표시 시점는 저장할 입력을 제한하므로 제외된 패킷은 나중에 화면 필터를 바꿔 되살릴 수 없다. 는 이미 저장된 자료 중 표시 대상을 바꾼다.
- 필터 문법캡처 필터와 표시 필터는 서로 다른 문법을 사용한다. BPF의 port 80과 의 .port == 80은 같은 형태의 문자열이 아니다.
- 범위 좁히기주소→프로토콜→포트→연결 상태로 좁히면 무엇을 제외했는지 설명하기 쉽다. 부정 조건이 있는 필터는 다중 값 필드에서 의미가 달라질 수 있으므로 의도한 패킷이 남는지 실제 목록으로 대조한다.
- 분석 조건암호화된 HTTPS 내용은 포트 필터로 선택했다고 평문 HTTP로 해석되는 것이 아니다.
text
Capture filter:
tcp port 80
Display filter:
tcp.port == 80
http.request.method == "GET"
dns.flags.response == 0
tcp.flags.syn == 1 and tcp.flags.ack == 0
tcp.flags.reset == 1수업의 필터를 주소 없는 예로 재구성했습니다. capture와 display 문법을 구분합니다.
055튜플과 양방향 연결
- 연결 식별 연결은 출발지·목적지 IP, 출발지·목적지 포트, protocol을 기본으로 식별한다. 응답 패킷에서는 양쪽이 뒤집히므로 같은 연결의 역방향으로 해석한다.
- 방향·동일 웹 서버에 다시 접속해 출발지 포트가 바뀌면 새 flow가 될 수 있다. 전후나 다른 캡처 지점의 도 달라질 수 있다.
- Stream 번호 stream 번호는 분석 도구가 해당 캡처 안에서 부여한 식별자다. 다른 의 stream0이 같은 실제 연결이라고 볼 수 없다.
- 자료 연결두 자료를 연결할 때는 시각·방향·sequence·길이·원본 바이트와 관찰 위치를 함께 비교한다.
06SYN·ACK·FIN·RST가 나타내는 상태
- Handshake·SEQ→/→는 연결 설정의 기본 흐름이다. 재시도만 보이면 서버에 도달하지 않았거나 응답 경로를 보지 못했거나 상대가 응답하지 않는 등 여러 가능성이 있다.
- 바이트와 도 닫힌 포트·연결 거부·상태 불일치 등 문맥이 달라 단독으로 공격으로 판정하지 않는다.
- ·은 한 방향의 데이터 전송 종료를 나타내므로 반대 방향이 곧바로 모두 끝났다고 볼 수 없다. 는 받은 바이트의 다음 기대 위치를 알려 준다.
- 수신 확인의 범위분석 화면이 상대 sequence 번호를 0부터 표시할 수 있으므로 wire의 절대 번호와 구분한다. 데이터 길이·/의 순서 공간 사용까지 고려해야 의 변화가 설명된다.
원리 심화
07TCP 순서 공간과 누적 확인 응답
- 순서 번호의 SEQ는 바이트 스트림의 위치를 나타낸다. 한 세그먼트의 패킷 번호나 수신한 패킷 개수가 아니다.
- 의미누적 는 다음에 기대하는 순서 번호다. 중간 구간이 빠지면 뒤 바이트를 보았어도 누적 가 그 틈을 넘어가지 않을 수 있다.
- 제어 비트과 은 각각 순서 공간 한 칸을 사용한다. 데이터가 없는 만의 세그먼트는 같은 방식으로 한 칸을 소비하지 않는다.
- 상대 표시분석 도구는 읽기 쉽게 초기 순서 번호를 기준으로 상대값을 표시할 수 있다. 원시 헤더 값과 화면 상대값을 구분한다.
- 방향 상태각 방향은 독립적인 순서 공간을 가진다. 클라이언트 SEQ와 서버 SEQ를 한 줄의 연속 번호로 합치지 않는다.
LEARN THROUGH PRACTICE
SSH TCP 연결의 SYN부터 FIN까지 상대 번호 추적하기
패킷 목록의 플래그·Len·Seq·를 이용해 연결 상태와 다음 기대 바이트를 계산한다.
실습 구성과 전제
- 자신의 정상 SSH 연결을 저장한 또는 제공된 실습 캡처를 사용한다.
- 의 상대 순서 번호 사용 여부를 확인하고 같은 .stream만 비교한다.
연결 수립에서 SYN의 번호 소비를 읽는다
- 클라이언트 은 Seq=0, 서버 /은 =1, 클라이언트 는 =1로 보인다. 은 데이터 길이가 0이어도 순서 공간 한 칸을 소비한다.
- 출발지 임시 포트와 서버 22번 포트의 방향을 고정해야 Seq와 의 소유자를 바꾸어 읽지 않는다.
원본 크기로 보기 ↗- 세 줄은 SYN→SYN, ACK→ACK이고 모두 Len=0이다.
- 임시 포트와 22번 포트가 반대 방향으로 오가며 Ack가 1로 증가한다.
확인 기준상대 번호 기준의 0·1과 실제 와이어의 절대 번호를 혼동하지 않는다.
종료 요청 두 개를 각 방향의 상태로 읽는다
- 도 순서 공간 한 칸을 소비한다. 한 방향의 을 확인해도 상대 방향 전송이 바로 끝났다고 볼 수 없으므로 양쪽 과 를 추적한다.
- 종료와 SSH 애플리케이션의 종료 원인은 다른 정보다. 이유는 SSH 로그나 사용자 동작으로 보완한다.
원본 크기로 보기 ↗- 서버 방향 FIN,PSH,ACK에 이어 Ack=1165가 보이고 반대 방향 FIN에는 Ack=938이 대응한다.
- 첫 FIN의 Seq=1164와 다른 방향 FIN의 Seq=937이 각각 한 칸 뒤에서 확인된다.
확인 기준의 +1을 데이터 1바이트 전송으로 잘못 계산하지 않는다.
이상 표시를 다른 증거로 확인한다
- 재전송·중복 표시는 캡처 관찰을 바탕으로 한 분석 결과다. 누락 캡처·비대칭 경로·오프로딩 때문에 실제 네트워크 손실과 다를 수 있다.
- Stream별로 앞뒤 패킷과 진전을 확인하고, 캡처 위치와 드롭 카운터를 함께 기록한다.
texttcp.stream == 0 tcp.flags.syn == 1 || tcp.flags.fin == 1 || tcp.flags.reset == 1각 줄은 별개의 표시 필터 예시. stream 번호는 분석할 연결에 맞춘다.
확인 기준경고 색상만으로 장애 원인을 확정하지 않는다.
실습에서 확인한 동작 원리
- 과 은 각각 순서 공간 한 칸을 사용한다.
- 패킷 분석 경고와 실제 원인은 추가 증거로 구분한다.
설정·출력 추가로 확인하기 19장
아래 화면을 펼쳐 위 실습의 설정값, 명령과 확인 기준을 비교해 보세요. 각 묶음은 별도 실습 기록입니다.
실습 화면 묶음 01 6장
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「packet builder」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
실습 화면 묶음 02 1장
원본 크기로 보기 ↗- 에 삽입된 원본 학습 화면이다. Scapy의 packet.show()가 IP·ICMP·Raw 계층 필드를 표시한 예시이다. 인접 코드는 ICMP 요청 패킷을 만들고 sr1()으로 첫 응답을 기다리는 동작을 다룬다.
실습 화면 묶음 03 1장
원본 크기로 보기 ↗- 학습 원본 · Scapy 패킷 실습 환경의 Scapy에 수록된 화면·도식이다.
실습 화면 묶음 04 1장
원본 크기로 보기 ↗- 학습 원본 · Scapy 패킷 실습 환경의 Scapy에 수록된 화면·도식이다.
실습 화면 묶음 05 1장
원본 크기로 보기 ↗- 학습 원본 · TCP 스트림 내용 관찰의 Wireshark tcp stream에 수록된 화면·도식이다.
실습 화면 묶음 06 7장
원본 크기로 보기 ↗- 「port 미러링」 문맥에 삽입된 원본 설정·관리 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「port 미러링」 문맥에 삽입된 원본 설정·관리 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「숫자 출력( nn )」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「패킷 내용 보기( A , X )」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「패킷 내용 보기( A , X )」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
원본 크기로 보기 ↗- 「port 미러링」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
실습 화면 묶음 07 1장
원본 크기로 보기 ↗- 「실습」 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
실습 화면 묶음 08 1장
원본 크기로 보기 ↗- 문서 문맥에 삽입된 원본 실습·개념 참고 화면이다. Wireshark로 패킷과 흐름 읽기 학습 내용과 함께 당시 구성·설정·관찰 결과를 비교할 수 있다.
예제로 추적
08가상 연결에서 80바이트 전송과 종료 추적
- 송신클라이언트의 초기 순서 번호가 1000이라고 가정한다. 은 1000을 사용하므로 다음 번호는 1001이다.
- 연결 확인서버가 클라이언트 방향 =1001을 보내면 을 확인한 것이다. 서버 자신의 SEQ는 별도 공간이다.
- 데이터 송신클라이언트가 SEQ=1001에서 80바이트를 보내면 데이터는 1001~1080을 차지하고 다음 번호는 1081이다.
- 수신 확인서버의 =1081은 그 앞까지 연속적으로 받았다는 뜻이다. 애플리케이션이 이미 저장·처리했다는 뜻은 아니다.
- 정상 종료이후 의 SEQ가 1081이면 상대의 는 1082가 된다. 종료 비트가 순서 공간을 하나 소비한 결과다.
검증·예외
09재전송 경고를 실제 손실로 해석하기 전
- 캡처 누락 과부하·수집기 드롭·중간 캡처 시작 때문에 원래 세그먼트가 없을 수 있다. 캡처 통계와 반대편 자료를 비교한다.
- 영향호스트 캡처에는 NIC가 분할·체크섬을 완성하기 전 형태가 보일 수 있다. 비정상 길이·체크섬 표시를 즉시 통신 오류로 단정하지 않는다.
- 중복과 겹침같은 SEQ의 재전송과 일부 구간만 겹치는 세그먼트를 구분한다. 재조립 결과가 실제 바이트 스트림을 보여 준다.
- 저장 완료 와 업무 확인 응답을 분리한다. 수신 버퍼 도착 후 가 종료되면 애플리케이션 처리는 완료되지 않을 수 있다.
10재조립·재전송·순서 뒤바뀜
- 메시지 분할HTTP 메시지는 세그먼트 하나에 대응하지 않는다. 하나의 요청이 여러 세그먼트로 나뉘거나 하나의 세그먼트에 여러 응용 데이터 부분이 담길 수 있다.
- 재조립재조립은 sequence를 기준으로 바이트 흐름을 복원하고 응용 파서는 그 안에서 메시지 경계를 찾는다.
- 재전송 판단Retransmission·Out-of-order 같은 표시는 캡처 관찰에 따른 분석이다. 실제 손실 외에도 한 방향 누락·중복 미러링·캡처 시작 위치 때문에 유사하게 보일 수 있다.
- 손실·“가 안 보임”과 “상대가 를 보내지 않음”은 다르다. 여러 지점의 캡처를 비교하면 어느 구간에서 사라졌는지 좁힐 수 있다.
11DNS·ARP·HTTP에서 읽는 연결 증거
- ··HTTP같은 대역 문제는 request/reply와 이웃 매핑, 이름 문제는 질의 이름·응답 코드·반환 주소·재시도, 웹 문제는 HTTP 메서드·상태·redirect를 차례로 연결한다. 응답이 있다는 사실은 그 서버와 연결이 성공했다는 뜻은 아니다.
- FTP 연결 분리FTP의 제어 연결과 데이터 연결은 별개이며 active/passive에 따라 데이터 포트가 달라진다. 20/21번 포트만으로 모든 FTP 트래픽을 필터링하면 passive 데이터 연결을 놓칠 수 있다.
- 협상 추적프로토콜 관계와 협상 내용을 읽은 뒤 필요한 흐름을 함께 조회한다.
12캡처 길이·Offload·시간 정밀도
- Snap length가 짧으면 원래 패킷 길이보다 저장한 바이트가 적을 수 있다. 이 경우 payload가 잘렸다는 것과 패킷 전체가 누락된 것은 다르다.
- Checksum 송신 호스트의 checksum 나 segmentation 는 캡처 화면의 패킷 크기·체크섬을 실제 회선과 다르게 보이게 할 수 있다.
- 시각 정밀도Timestamp는 관찰 장치의 시계와 캡처 방식에 영향을 받는다. 시간 소수점이 많다고 시계가 그만큼 정확한 것은 아니며 서로 다른 센서의 오프셋도 고려해야 한다.
- 시간 문맥요청·응답의 시간 차이를 애플리케이션 처리 시간으로 해석할 때는 네트워크 지연과 관찰 위치를 함께 포함한다.
13ALPACA의 여섯 표본 비교
- 여섯 표본프로젝트 원문은 alert와 별도 캡처 경로의 HTTP 요청3개·응답3개를 비교했다. 세 표본은 timestamp가 같았고 세 표본은 1마이크로초 차이였으며 선택한 표본의 통신 정보와 순서가 일치한다고 기록했다.
- 표본의 한계이 결과는 해당 실험에서 자료 연결이 가능했음을 보여 준다.
- 비교표 범위다음 표는 실제 주소와 요청 내용을 제거하고 시간 차이만 복원한 것이다. 표본6건에서 일치했다는 관찰을 고부하 전 구간 무손실이나 모든 logger의 동시 출력 제한이라는 일반 명제로 확대하지 않는다.
- 방향 확인같은 방식으로 반복할 때도 raw bytes·길이·캡처 위치를 추가 근거로 남긴다.
| 표본 | 유형 | 시각 차이 |
|---|---|---|
| 1 | HTTP 요청 | 0 μs |
| 2 | HTTP 응답 | 1 μs |
| 3 | HTTP 요청 | 0 μs |
| 4 | HTTP 응답 | 0 μs |
| 5 | HTTP 요청 | 1 μs |
| 6 | HTTP 응답 | 1 μs |
14Alert에서 패킷으로 돌아가기
- 경보의 해석경보 시각·주소·포트·규칙 ID로 후보 패킷을 고른 뒤 같은 flow 전후와 요청·응답을 읽는다. 한 경보가 패킷 하나가 아니라 재조립된 stream·의 조건을 의미할 수도 있으므로 가장 가까운 timestamp 하나만 고르는 방식은 불충분할 수 있다.
- 패킷 근거패킷이 없으면 원래 저장 정책에서 제외했는지, 보존 기간이 끝났는지, 입력이 유실되었는지 구분한다. 경보는 남았지만 이 없다는 사실과 공격이 없었다는 결론은 연결되지 않는다.
- 보존 범위보관한 바이트가 설명하는 범위와 빠진 근거를 함께 기록하는 것이 패킷 분석의 기본이다.
설명과 함께 보는 보조 도식
메시지 순서
모식도 · 바이트 수신과 업무 처리의 차이
설명을 위한 데이터 시퀀스 값이며 연결 수립 단계는 생략했다.
01
데이터 구간 전송
시퀀스 1000부터 데이터 200바이트를 보낸다고 가정한다.
- 범위
- 1000~1199
전체 단계를 한 번에 읽기
- 01
데이터 구간 전송
시퀀스 1000부터 데이터 200바이트를 보낸다고 가정한다.
- 범위
- 1000~1199
- 02
누적 ACK
정상 수신 뒤 다음 기대 바이트 1200을 알린다.
- 증거
- TCP 수신 경계
- 03
바이트 전달
애플리케이션이 읽어 메시지 경계를 해석한다.
- 04
업무 응답
처리 결과를 새 바이트 흐름으로 보낸다.
- 구분
- ACK 성공 ≠ 업무 처리 완료
READ · OBSERVE · CONNECT
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
Wireshark: Follow Stream 화면과 데이터 방향
공식 화면에서 연결별 필터와 양방향 바이트를 비교하고 프레임 목록과 스트림 내용의 관점을 구분한다.
읽으면서 확인할 것
- Follow를 선택할 때 적용되는
- 양방향 데이터 표시와 스트림 선택
- 스트림을 읽는 데 필요한 키 자료
Wireshark: TCP 분석 표시의 판정 조건
Retransmission·Dup ·Previous segment not captured가 어떤 관찰값에서 생기는지 읽어 경고를 곧바로 망 장애로 단정하지 않게 한다.
읽으면서 확인할 것
- 예상 순서 번호와 현재 SEQ의 비교
- Dup 표시의 여러 조건
- 캡처에 없는 세그먼트와 실제 유실의 구분
학습 확인
이해했는지 확인하기
- 인터페이스·캡처 지점·드롭 수·시간대를 확인한다.
- 캡처 필터와 표시 필터의 적용 시점을 구분한다.
- 이상 패킷을 같은 흐름의 앞뒤 메시지와 서버 로그에 연결한다.