개념 사전/분석 · 관제 / 패킷 분석
개념 사전 · 프로그램

Wireshark

와이어샤크

는 캡처한 네트워크 프레임을 프로토콜별 필드와 흐름으로 해석하는 분석 도구다. 화면에 표시된 경고는 관측 지점과 캡처 품질을 고려하여 실제 통신 장애와 구분한다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

로고: Wireshark Foundation 공식 자료. 제품 식별을 위해 표시하며 각 상표의 권리는 권리자에게 있습니다.

01무엇이고, 어떤 일을 하나

  • 패킷 목록·프로토콜 트리·원시 바이트를 연결한다.
  • 순서·확인 응답·재조립으로 연결 상태를 추적한다.
  • 경보 시점과 해당 트래픽을 대조해 조사 증거를 확보한다.

02어떤 순서로 동작하나

  1. 입력 범위 확인

    인터페이스·캡처 위치·필터·시간 범위와 누락 가능성을 먼저 확인한다.

  2. 양방향 연결 묶기

    과 반대 방향을 연결하고 전후·재사용 포트·별도 실행의 흐름을 구분한다.

  3. 상태 추적

    ··순서 번호로 연결 시작과 바이트 진행을 읽고 ·를 종료 맥락과 연결한다.

  4. 재조립과 응용 해석

    재전송·순서 뒤바뀜·분할을 반영해 바이트 스트림과 HTTP· 등 의미를 읽는다.

  5. 다른 증거와 대조

    서버 로그·경보·시간 정보를 연결한다. 응답 상태와 실제 업무 성공 또는 공격 성공은 별도로 검증한다.

03먼저 알아둘 용어와 구성요소

캡처 시점에 수집 대상을 제한하는 필터.
이미 수집된 패킷 중 화면에 보일 대상을 고르는 필터.
양 끝 IP·포트와 전송 프로토콜로 연결을 식별하는 정보.
패킷마다 실제 저장할 최대 캡처 길이.
순서 번호를 동기화하는 연결 수립 플래그.
확인 번호 필드가 유효함을 표시하는 플래그.
해당 방향의 전송 종료를 알리는 플래그.
연결 재설정 또는 수용 불가 등을 나타내는 플래그.
나뉜 패킷·세그먼트의 데이터를 상위 메시지 형태로 다시 모으는 처리.
체크섬·분할 등 일부 처리를 네트워크 장치 등에 맡기는 기능.
LEARN THROUGH PRACTICE

핸드셰이크의 암호화 경계와 인증 실패 위치 찾기

메시지 순서를 패킷 관찰 가능 범위와 연결하고, 인증서 오류가 발생하는 단계를 설명한다.

실습 구성과 전제

  • 자신의 실습 서버에 정상 HTTPS 연결을 한 번 만들고 PCAP를 저장한다.
  • 전체 핸드셰이크 도해를 기준으로 하되 재개 연결·PSK· 1.2는 별도로 구분한다.

  1. 암호화되기 전 협상 필드를 찾는다

    • 에서 ClientHello와 ServerHello의 supported_versions, cipher suite, key_share를 비교한다. 구버전 호환 필드만 보고 1.2라고 단정하지 않는다.
    • ClientHello는 제안, ServerHello는 선택 결과다. 양쪽이 합의한 키 공유로 이후 핸드셰이크 보호 키를 도출한다.
    text
    tls.handshake.type == 1 || tls.handshake.type == 2

    표시 필터 예시. 저장된 자신의 실습 PCAP에서 사용한다.

    TLS 1.3 핸드셰이크 · TLS 1.3 Handshake의 전체 흐름원본 크기로 보기 ↗
    • ClientHello와 ServerHello 다음에 'Handshake 암호화 키 생성' 경계가 표시된다.
    • CertificateVerify와 Finished는 서로 다른 메시지로 그려져 있어 키 소유 증명과 핸드셰이크 무결성 확인을 나누어 읽을 수 있다.
    확인 기준

    같은 .stream에서 협상 버전과 키 공유를 확인한다.

  2. 안 보이는 메시지와 실패한 메시지를 구분한다

    • 에서는 ServerHello 뒤의 인증서 메시지도 보통 암호화돼 보인다. 키 로그가 없는 캡처에서 Certificate가 보이지 않는다는 이유만으로 서버가 인증서를 생략했다고 단정하지 않는다.
    • 실습 클라이언트의 브라우저 오류와 패킷 시각을 연결한다. 인증서 경고는 전송 암호화의 유무와 다른 판단이다.
    HTTPS 인증서와 브라우저 표시원본 크기로 보기 ↗
    • HTTPS 주소에서도 CA 신뢰 오류가 표시된다.
    • 경고 화면에는 협상 cipher suite나 Finished 성공 여부가 나타나지 않는다. 이 정보는 패킷·클라이언트 진단으로 보완해야 한다.
    확인 기준

    캡처 가시성 한계와 실제 인증 실패를 보고서에서 분리한다.

  3. 인증 성공 후 애플리케이션 동작을 확인한다

    • 핸드셰이크가 끝나도 HTTP 인가나 로그인 성공이 보장되지는 않는다. 연결 성립→서버 신뢰→애플리케이션 응답을 각각 판정한다.
    • 복호화 가능한 실습 PCAP에서는 정상 요청의 응답을 확인하고, 키 로그 파일은 학습 후 별도로 보호·정리한다.
    확인 기준

    성공과 HTTP 상태 코드를 같은 항목으로 합치지 않는다.

실습에서 확인한 동작 원리

  • 의 암호화 경계는 ServerHello 이후에 생긴다.
  • 신뢰 오류·복호화 자료 부재·애플리케이션 오류는 다른 현상이다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

FTP 배너와 HTTP 응답에서 서비스 식별 근거 만들기

포트 열림·서비스 식별·취약점 확인을 다른 증거 단계로 나눈다.

실습 구성과 전제

  • 허가된 격리 장비에서 얻은 서비스 탐지 PCAP를 작업 사본으로 연다.
  • 사진 속 주소에 다시 접속하지 않고 저장된 요청·응답을 읽는다.

  1. 연결 확인과 서비스 대화를 구분한다

    • 사진에서는 초기 ·/ 뒤 가 있는 연결과, 별도 출발지 포트로 3-way handshake를 완료한 연결이 이어진다.
    • 포트 응답은 서비스가 대화할 수 있는 후보임을 보여 준다. 실제 서비스 식별은 연결 안의 배너나 응답 내용으로 보완한다.
    Nmap 스캔 응답과 포트 판독 · Version/OS 스캔 실습원본 크기로 보기 ↗
    • 21번 포트 연결에서 220 응답과 vsFTPd 3.0.5 문자열이 보인다.
    • 초기 확인 연결과 배너를 받은 연결의 출발지 포트가 다르다. 한 TCP 연결로 합치면 순서 해석이 틀린다.
    확인 기준

    과 .stream을 기준으로 연결을 분리한다.

  2. 응답 헤더를 제품 정보의 후보로 읽는다

    • HTTP의 Server와 X-Powered-By는 노출된 문자열이지 패키지 패치 상태 전체가 아니다. 관리자가 감추거나 변경할 수 있으며 배포판은 보안 패치를 백포트할 수 있다.
    • 응답 상태와 제품 후보·버전을 적고, 그에 대응하는 공식 권고와 설치 패키지 정보를 별도로 확인한다.
    Nmap 스캔 응답과 포트 판독 · Version/OS 스캔 실습원본 크기로 보기 ↗
    • GET / HTTP/1.0에 HTTP/1.1 200 OK가 돌아오고 Server·X-Powered-By 헤더가 표시된다.
    • 후속 연결도 계속 나타나며 요청 종류에 따라 연결이 새로 생성됨을 볼 수 있다.
    확인 기준

    버전 문자열 하나만으로 CVE 영향 여부를 확정하지 않는다.

  3. 발견 사항을 재시험 가능한 형태로 적는다

    • 증거에는 대상 역할·허가 범위·도구 버전·시각·포트·응답 필드·판단 한계를 남긴다. 서비스 노출과 실제 취약 기능을 분리한다.
    • 조치 후에는 같은 조건의 응답과 패키지 상태를 확인하고 정상 서비스가 유지되는지도 시험한다.
    text
    tcp.port == 21 || http.response
Follow → TCP Stream

    표시 필터와 연결 재조립 기능으로 저장된 PCAP를 조회한다.

    확인 기준

    '취약함' 대신 현재 증거로 확정할 수 있는 문장을 쓴다.

실습에서 확인한 동작 원리

  • 배너는 서비스 식별의 증거지만 취약점 성공 증거는 아니다.
  • 서로 다른 출발지 포트의 연결은 분리해서 읽는다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

ARP 캐시의 다음 홉 MAC 변경을 패킷과 맞추기

같은 IP가 다른 MAC으로 해석될 때 실제 전송 경로와 통신 영향을 설명한다.

실습 구성과 전제

  • 변조를 외부망에서 실행하지 않고 격리 실습의 전후 화면과 PCAP를 읽는다.
  • 단말·게이트웨이·중간 장비의 역할과 캡처 위치를 먼저 구분한다.

  1. 변경 전 캐시를 기준선으로 둔다

    • 캐시는 로컬 링크의 다음 홉 IP를 MAC으로 연결한다. 사진의 서로 다른 두 IP가 서로 다른 MAC에 매핑된 상태를 기준선으로 기록한다.
    • 캐시 항목이 dynamic이라는 사실은 자동 갱신될 수 있음을 뜻하며, 신뢰성이 검증됐다는 표시는 아니다.
    ARP 스푸핑 실습 · 공격 시나리오 (3)원본 크기로 보기 ↗
    • 인터넷 주소와 물리적 주소 두 열이 있고 두 IP의 MAC 값이 서로 다르다.
    • 유형은 모두 동적으로 표시된다. 이후 응답에 따라 캐시가 바뀔 수 있는 상태다.
    확인 기준

    기준선에는 단말 위치·게이트웨이 역할·시각을 함께 적는다.

  2. 같은 MAC으로 바뀐 매핑을 비교한다

    • 변경 후 게이트웨이로 쓰던 IP와 다른 실습 장비 IP가 같은 MAC으로 매핑돼 있다. 이후 프레임은 그 MAC을 목적지로 만들 수 있다.
    • 두 IP가 같은 MAC인 현상은 Proxy ·가상화·이중화 구성에서도 가능하다. 정상 설계와 대조해야 공격으로 판단할 수 있다.
    ARP 스푸핑 실습 · 공격 시나리오 (5)원본 크기로 보기 ↗
    • 전후 화면에서 첫 번째 IP의 MAC이 바뀌었고 두 항목의 MAC이 같아졌다.
    • 캐시 자체는 여전히 동적 항목으로 표시된다. 캐시 화면만으로 중간 장비가 패킷을 전달했는지는 알 수 없다.
    확인 기준

    경로 변경과 패킷 전달 성공·차단을 별도로 확인한다.

  3. ARP 응답과 실제 영향의 증거를 연결한다

    • PCAP의 sender IP·sender MAC과 캐시 변경을 맞춘다. 사용 여부는 중간 경로에서 평문을 볼 수 있는 범위에 영향을 준다.
    • Duplicate IP 경고는 상충하는 관찰을 알리는 단서다. 실제 공격 여부와 양방향 중간자 상태는 추가 패킷·장비 증거로 확인한다.
    ARP 스푸핑 실습 · 공격 시나리오 (7)원본 크기로 보기 ↗
    • ARP reply가 선택돼 있고 동일 IP에 서로 다른 MAC이 관찰됐다는 경고가 표시된다.
    • 원시 프레임의 출발지와 목적지 MAC을 확인할 수 있어 캐시 변경의 입력과 연결할 수 있다.
    확인 기준

    변화만으로 내용 복호화까지 주장하지 않는다.

실습에서 확인한 동작 원리

  • IP→MAC 변화는 다음 홉 프레임 목적지를 바꾼다.
  • 정상 가상·대리 와 공격을 구분하려면 기준 구성이 필요하다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

SSH TCP 연결의 SYN부터 FIN까지 상대 번호 추적하기

패킷 목록의 플래그·Len·Seq·를 이용해 연결 상태와 다음 기대 바이트를 계산한다.

실습 구성과 전제

  • 자신의 정상 SSH 연결을 저장한 PCAP 또는 제공된 실습 캡처를 사용한다.
  • 의 상대 순서 번호 사용 여부를 확인하고 같은 .stream만 비교한다.

  1. 연결 수립에서 SYN의 번호 소비를 읽는다

    • 클라이언트 은 Seq=0, 서버 /은 =1, 클라이언트 는 =1로 보인다. 은 데이터 길이가 0이어도 순서 공간 한 칸을 소비한다.
    • 출발지 임시 포트와 서버 22번 포트의 방향을 고정해야 Seq와 의 소유자를 바꾸어 읽지 않는다.
    TCP 패킷 교환 · TCP 3way-handshake (1)원본 크기로 보기 ↗
    • 세 줄은 SYN→SYN, ACK→ACK이고 모두 Len=0이다.
    • 임시 포트와 22번 포트가 반대 방향으로 오가며 Ack가 1로 증가한다.
    확인 기준

    상대 번호 기준의 0·1과 실제 와이어의 절대 번호를 혼동하지 않는다.

  2. 종료 요청 두 개를 각 방향의 상태로 읽는다

    • 도 순서 공간 한 칸을 소비한다. 한 방향의 을 확인해도 상대 방향 전송이 바로 끝났다고 볼 수 없으므로 양쪽 과 를 추적한다.
    • 종료와 SSH 애플리케이션의 종료 원인은 다른 정보다. 이유는 SSH 로그나 사용자 동작으로 보완한다.
    TCP 패킷 교환 · 세션 종료 : 4way-handshake (12)원본 크기로 보기 ↗
    • 서버 방향 FIN,PSH,ACK에 이어 Ack=1165가 보이고 반대 방향 FIN에는 Ack=938이 대응한다.
    • 첫 FIN의 Seq=1164와 다른 방향 FIN의 Seq=937이 각각 한 칸 뒤에서 확인된다.
    확인 기준

    의 +1을 데이터 1바이트 전송으로 잘못 계산하지 않는다.

  3. 이상 표시를 다른 증거로 확인한다

    • 재전송·중복 표시는 캡처 관찰을 바탕으로 한 분석 결과다. 누락 캡처·비대칭 경로·오프로딩 때문에 실제 네트워크 손실과 다를 수 있다.
    • Stream별로 앞뒤 패킷과 진전을 확인하고, 캡처 위치와 드롭 카운터를 함께 기록한다.
    text
    tcp.stream == 0
 tcp.flags.syn == 1 || tcp.flags.fin == 1 || tcp.flags.reset == 1

    각 줄은 별개의 표시 필터 예시. stream 번호는 분석할 연결에 맞춘다.

    확인 기준

    경고 색상만으로 장애 원인을 확정하지 않는다.

실습에서 확인한 동작 원리

  • 과 은 각각 순서 공간 한 칸을 사용한다.
  • 패킷 분석 경고와 실제 원인은 추가 증거로 구분한다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

SPAN 수신 위치와 TCP 플래그 규칙을 연결하기

센서 가시성을 확인한 뒤 저장된 패킷의 조건을 규칙 헤더·옵션으로 옮긴다.

실습 구성과 전제

  • 와 Lua 설정을 사용하는 격리 센서, 스위치, 허가된 PCAP 작업 사본을 준비한다. 2의 .conf·실행 옵션을 그대로 섞지 않는다.
  • 사진의 구성도와 프로브 캡처는 관측 배치와 규칙 조건을 비교하는 자료이며 하나의 경보 발생을 자동으로 증명하지 않는다.

  1. 복제할 방향과 센서 연결 포트를 확인한다

    • source interface f1/2 both는 양방향 프레임을 복제한다는 뜻이며 destination interface f1/1은 복제본을 받는 포트다.
    • 센서의 실제 캡처 NIC와 이 포트가 연결됐는지 확인한다. HOME_NET 설정이 맞아도 패킷이 들어오지 않으면 규칙을 평가할 수 없다.
    7/30 - 발표 · 구성도 3원본 크기로 보기 ↗
    • 도해 오른쪽에 source f1/2 both와 destination f1/1이 표시된다.
    • Snort VM 연결이 f1/1 쪽에 그려져 있다. 이는 복제 수신 구성으로, 인라인 차단 구성과 구분해야 한다.
    확인 기준

    show monitor 출력과 센서 캡처 양쪽을 확인한다.

  2. 패킷 조건을 필요한 필드로 좁힌다

    • 캡처에는 ··PSH·URG가 함께 있는 데이터 없는 프로브가 보인다. 이 조합과 Len=0을 규칙 조건으로 옮길 수 있다.
    • 의 재전송·중복 문구는 분석 표시이며 flags 옵션의 값이 아니다. flags와 payload 길이는 각각 검사한다.
    text
    alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"LAB unusual TCP flags"; flags:FSUP; dsize:0; sid:1000201; rev:1;)

    교육용 패킷 조건 예시. 규칙 일치는 이상 플래그 조합의 관찰이며 도구나 공격 성공을 확정하지 않는다.

    Nmap·Snort 탐지 실습원본 크기로 보기 ↗
    • 일부 행에 [FIN, SYN, PSH, URG]와 Len=0이 표시된다.
    • 다른 행에는 <None> 플래그와 중복 ACK 표시가 있다. 서로 다른 조건을 하나의 룰로 무작정 합치지 않는다.
    확인 기준

    정상 표본도 함께 넣어 경보 범위를 비교한다.

  3. 문법과 실제 일치를 별도 시험한다

    • 설정 검증은 규칙을 읽을 수 있는지 확인하고, PCAP 재현은 실제 표본이 조건에 맞는지 확인한다. 검증이 성공해도 경보가 반드시 생기는 것은 아니다.
    • alert_json의 rule·action·src_ap·dst_ap·pkt_num을 패킷과 연결한다. 아래 alert 규칙과 오프라인 재생은 탐지 시험이다. would_drop 같은 표시가 나오더라도 실제 인라인 통신 차단 증거와 구분한다.
    shell
    snort -c snort.lua -R local.rules -T
snort -c snort.lua -R local.rules -r lab.pcap -A alert_json

    의 재현용 예시 명령이다. 사진에 나온 실행 결과를 전재한 것이 아니며, 설치에 맞는 .lua와 자신의 PCAP를 사용한다.

    확인 기준

    기대 패킷 번호와 경보 SID를 연결하고 음성 표본의 결과도 남긴다.

실습에서 확인한 동작 원리

  • 센서 배치가 규칙보다 먼저 충족해야 하는 조건이다.
  • 규칙 문법·표본 일치·실제 차단은 각각 다른 증거를 요구한다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 송신: 클라이언트의 초기 순서 번호가 1000이라고 가정한다. 은 1000을 사용하므로 다음 번호는 1001이다.
  • 연결 확인: 서버가 클라이언트 방향 =1001을 보내면 을 확인한 것이다. 서버 자신의 SEQ는 별도 공간이다.
  • 데이터 송신: 클라이언트가 SEQ=1001에서 80바이트를 보내면 데이터는 1001~1080을 차지하고 다음 번호는 1081이다.
  • 수신 확인: 서버의 =1081은 그 앞까지 연속적으로 받았다는 뜻이다. 애플리케이션이 이미 저장·처리했다는 뜻은 아니다.
  • 정상 종료: 이후 의 SEQ가 1081이면 상대의 는 1082가 된다. 종료 비트가 순서 공간을 하나 소비한 결과다.

05혼동하기 쉬운 점과 확인 기준

  • 캡처 누락: 과부하·수집기 드롭·중간 캡처 시작 때문에 원래 세그먼트가 없을 수 있다. 캡처 통계와 반대편 자료를 비교한다.
  • 영향: 호스트 캡처에는 NIC가 분할·체크섬을 완성하기 전 형태가 보일 수 있다. 비정상 길이·체크섬 표시를 즉시 통신 오류로 단정하지 않는다.
  • 중복과 겹침: 같은 SEQ의 재전송과 일부 구간만 겹치는 세그먼트를 구분한다. 재조립 결과가 실제 바이트 스트림을 보여 준다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

Wireshark로 패킷과 흐름 읽기패킷 분석은 한 줄의 색상이나 경고보다 시간 순서와 양방향 흐름을 읽는 작업이다. 캡처 지점의 한계부터 확인한다.상세 노트 읽기 →
READ · OBSERVE · CONNECT

함께 보는 학습 자료

아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.

도해

Wireshark: Follow Stream 화면과 데이터 방향

공식 화면에서 연결별 필터와 양방향 바이트를 비교하고 프레임 목록과 스트림 내용의 관점을 구분한다.

읽으면서 확인할 것
  • Follow를 선택할 때 적용되는
  • 양방향 데이터 표시와 스트림 선택
  • 스트림을 읽는 데 필요한 키 자료
공식 가이드

Wireshark: TCP 분석 표시의 판정 조건

Retransmission·Dup ·Previous segment not captured가 어떤 관찰값에서 생기는지 읽어 경고를 곧바로 망 장애로 단정하지 않게 한다.

읽으면서 확인할 것
  • 예상 순서 번호와 현재 SEQ의 비교
  • Dup 표시의 여러 조건
  • 캡처에 없는 세그먼트와 실제 유실의 구분

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.