실패한 시도와 재시도 추적하기

소개

Alder는 Lantern Room 예약 페이지가 두 시도를 처리했지만 한 번만 예약되었다고 말합니다. 지원팀에는 허가된 HTTPS 기록과 일치하는 TLS 키 로그가 있습니다. 두 시도는 같은 URI와 TCP 연결을 사용하며 파일에는 다른 방문자도 있습니다.

실제 Wireshark 화면에서 각 애플리케이션 결과를 식별하고 작은 증거 표와 완전하고 독립적으로 읽을 수 있는 캡처 묶음을 만듭니다. Read Your Authorized HTTPS Session을 마쳤거나 TLS 키 로그 설정과 Follow TLS Stream을 알고 있어야 합니다. 기본적인 터미널 입력과 경로 지식도 필요합니다. 이 실습은 자체 통제된 기록으로 독립적으로 시작하며 예상 시간에는 읽기와 일반적인 오류가 포함됩니다.

각 시도를 해당 비즈니스 결과와 연결하기

이 단계에서는 각 원본 요청 프레임을 고유한 전체 응답에 연결하고 두 결과를 기록합니다.

Desktop → Applications → Terminal Emulator에서 시작합니다. 준비된 입력을 빈 Booking 프로필로 엽니다.

wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng

Wireshark를 최대화합니다. 읽기 전용 입력 파일은 casebook.pcapng와 casebook.keys이며 결과는 모두 /home/labex/project/booking/output/ 아래에 둡니다. 데이터는 합성이지만 각 TLS 핸드셰이크, HTTP 교환, TCP 세그먼트는 실제 통제된 로컬 애플리케이션에서 생성되었습니다.

Edit → Preferences → Protocols → TLS에서 (Pre)-Master-Secret log filename을 설정합니다.

/home/labex/project/booking/input/casebook.keys

TLS 재조립 옵션 두 개를 켠 상태로 두고 OK를 누릅니다. 키 로그는 기록된 이 세션들을 복호화할 수 있게 하며 모든 HTTPS 연결을 여는 일반 키가 아닙니다.

다음 표시 필터를 적용하고 Enter를 누릅니다.

ip.addr == 127.0.0.22 && http

ip.addr는 어느 쪽 끝점이든 일치시킵니다. &&는 두 조건 모두 일치해야 한다는 뜻이므로 Alder의 양방향 복호화 HTTP 메시지가 표시됩니다. POST 두 개와 200 OK 응답 두 개가 보여야 합니다. 요청의 /api/bookings URI와 TCP 스트림은 두 시도가 공유하므로 어느 하나만으로 개별 트랜잭션을 식별할 수 없습니다.

첫 POST를 선택합니다. 가운데 패킷 세부 정보 창에서 작은 삼각형으로 Hypertext Transfer Protocol을 펼칩니다. 아래쪽의 **[Response in frame: ...]**를 읽습니다. 이 생성된 필드는 Wireshark가 실제로 짝지은 응답과 이 요청을 연결합니다. 해당 응답의 프로토콜 세부 정보에서 **[Request in frame: ...]**가 다시 요청을 가리킵니다. 패킷 목록에서 연결된 응답을 선택합니다. No. 열은 원본 프레임 번호입니다. 재조립된 HTTP가 마지막 세그먼트에 표시될 수 있으므로 인접한 TCP 행으로 추측하지 말고 이 분석 프레임 참조를 사용합니다.

펼친 HTTP 세부 정보에서 **[Response in frame: 21]**를 보세요. 이 링크는 선택한 첫 요청에 속하며 두 번째 요청은 다른 응답을 갖습니다.

요청을 오른쪽 클릭하고 Follow → TLS Stream을 선택합니다. 전체 요청과 응답을 읽습니다. 요청 JSON의 attempt, workshop, slot을 확인합니다. 응답은 이 값을 반복합니다. accepted, reason, confirmation을 함께 읽습니다. 같은 스트림 아래에서 두 번째 요청과 응답도 읽습니다.

Alder의 첫 시도는 정원이 차서 거절됩니다. accepted는 false, reason은 "session_full", confirmation은 null입니다. 재시도는 수락되어 자체 확인값을 갖습니다. 두 HTTP 상태 행은 모두 200 OK입니다. 서버가 두 요청을 처리했지만 비즈니스 결과는 다릅니다. 같은 스트림의 다른 부분이나 Birch 방문에서 본 확인값을 거절된 시도에 가져올 수 없습니다.

Close로 Follow를 닫습니다. 남은 스트림 필터는 전체 연결을 포함합니다. 위의 원래 Alder-and-HTTP 필터로 돌아가 원본 프레임 번호 네 개를 기록합니다. 표를 작성할 때 계속 입력 파일을 사용하세요. 내보낸 파일은 패킷 번호를 다시 매깁니다.

다른 분석가가 캡처와 대조할 수 있는 작은 전달용 색인 attempts.csv를 준비합니다. CSV는 쉼표로 구분된 값입니다. 첫 줄은 열 이름이며 다음 각 줄은 시도 하나입니다. 열은 일곱 개입니다.

아래 패널에서 터미널로 전환하거나 첫 터미널이 Wireshark로 사용 중이면 다른 Terminal Emulator를 엽니다. 준비된 텍스트 편집기를 실행합니다.

mousepad /home/labex/project/booking/output/attempts.csv

아래 헤더를 그대로 입력한 뒤 원본 캡처에서 읽은 두 행을 입력합니다. 확인 열에 null이라는 단어를 복사하지 마세요. 거절 행 끝에 쉼표를 두면 마지막 필드가 비게 됩니다. 학습 데이터 값에는 쉼표가 없으므로 CSV 필드에 따옴표가 필요하지 않습니다. 헤더와 값이 일치하면 행과 열의 순서를 바꿔도 됩니다.

attempt,request_frame,response_frame,slot,accepted,reason,confirmation

File → Save 후 편집기를 닫습니다. 서로 다른 시도마다 한 행이 있고 각 행이 고유한 응답을 가리키는지 확인합니다. 오타가 있으면 위 명령으로 같은 파일을 다시 열어 수정하고 저장합니다. 새 캡처나 VM 초기화는 필요하지 않습니다. 다음 단계를 위해 Wireshark는 열어 둡니다.

독립적으로 읽을 수 있는 증거 묶음 전달하기

이 단계에서는 전체 대상 연결을 내보내고 전달할 키 로그로 다시 엽니다.

Desktop에서 Wireshark가 원본 input/casebook.pcapng를 연 상태로 시작합니다. 표는 원본을 가리키지만 전달할 캡처에는 Alder의 전체 TCP 연결만 있어야 합니다. 애플리케이션 데이터를 복호화하고 재조립하려면 TLS 핸드셰이크와 앞선 세그먼트가 필요합니다.

표시 필터를 바꿉니다.

ip.addr == 127.0.0.22

이 필터는 Alder의 양방향과 모든 프로토콜 계층을 유지합니다. 복호화된 POST 하나를 선택하고 오른쪽 클릭하여 Follow → TLS Stream을 엽니다. 두 시도가 Alder에 속하는지 확인한 뒤 Close로 Follow를 닫습니다. 남은 tcp.stream eq ... 필터를 유지합니다. HTTP로 표시된 행만이 아니라 선택한 전체 연결을 포함합니다.

File → Export Specified Packets를 선택합니다. 파일 형식 pcapng, 범위 Displayed, 표시된 집합 내의 All packets를 선택합니다. 다음에 저장합니다.

/home/labex/project/booking/output/evidence.pcapng

대화 상자에는 Displayed, All packets, 대상 패킷 38개가 보입니다. 원본 파일에는 패킷 65개가 있으므로 Captured를 선택하면 다른 방문자도 포함됩니다.

요약을 내보내는 Export Packet Dissections를 사용하지 마세요. http 행만 내보내면 복호화와 재조립에 필요한 핸드셰이크 또는 앞선 TLS/TCP 세그먼트가 빠질 수 있습니다. Inject TLS Secrets로 비밀 정보를 삽입하지 마세요. 이 묶음은 별도의 키 로그를 사용합니다.

Terminal Emulator로 전환하고 허가된 키 로그를 출력 옆에 복사합니다. cp는 첫 경로를 두 번째 경로로 복사하므로 원본 입력의 이름을 바꾸지 않고 보존합니다.

cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys

이 학습용 전달은 동일한 허가된 분석 범위 안에서 이루어집니다. 제공된 로그에는 원본 기록의 합성 세션 비밀 정보가 들어 있으며 키 로그 항목의 최소화나 삭제는 이 연습의 범위 밖입니다. 캡처 자체에서는 반드시 Birch의 패킷을 제외해야 합니다. 두 전체 대상 응답을 독립적으로 복호화할 수 있다면 동등하게 일치하는 키 로그도 허용됩니다.

Wireshark 메인 창을 닫고 초기 빈 BookingReview 프로필에서 실제 내보낸 파일을 다시 엽니다.

wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng

Edit → Preferences → Protocols → TLS에서 (Pre)-Master-Secret log filename을 아래 출력 키 로그로 설정하고 OK를 누릅니다.

/home/labex/project/booking/output/booking.keys

http를 적용한 뒤 POST에서 Follow → TLS Stream을 엽니다. 두 전체 요청과 응답 본문을 다시 읽습니다. 내보낸 결과는 고유한 attempt에 연결된 Alder의 거절과 확인을 보여 주고 Birch 방문을 포함하지 않아야 합니다. 원본 입력 키 경로에 몰래 의존하지 않고 출력 키 로그로 작동해야 합니다.

각 결과 옆에 반복된 attempt를 읽으세요. 거절에는 확인값이 없고 재시도만 ALDER-02-CONF를 갖습니다. 제목은 출력 파일 evidence.pcapng를 가리킵니다.

Follow를 닫고 표시 필터를 지워 핸드셰이크와 다른 TCP 패킷도 있는지 확인합니다. 이 파일은 자체 프레임 번호를 사용합니다. attempts.csv는 원본 입력 프레임을 계속 가리켜야 합니다. 메인 창을 닫습니다.

출력이 비어 있거나 본문이 빠졌다면 입력을 다시 열고 전체 Alder 연결 필터를 복원한 뒤 Displayed → All packets로 Export Specified Packets를 반복하여 불완전한 출력을 교체합니다. 패킷이 여전히 암호화되어 있다면 TLS 설정에서 출력 키 로그 경로를 고칩니다. 두 문제는 다릅니다. 키 로그가 없으면 복호화할 수 없고 캡처 세그먼트가 빠졌다면 설정을 바꿔도 복구되지 않습니다.

전달 결과는 실제 파일 세 개 attempts.csv, evidence.pcapng, booking.keys입니다. 캡처와 키가 표를 독립적으로 뒷받침해야 합니다. 스크린샷이나 입력한 성공 주장은 실제 패킷 증거를 대신할 수 없습니다.

요약

동일한 HTTP 상태 코드에 담긴 서로 다른 비즈니스 결과를 구분하고 각 요청을 고유 응답에 연결했으며 원본 프레임 참조를 간결한 증거 표에 기록했습니다. 전체 대상 TCP 연결을 내보내고 별도의 키 로그로 실제 출력 파일을 다시 열었습니다.

결과인 세 파일 묶음은 자신의 Wireshark 프로필 없이 검토할 수 있습니다. 이 통제된 예약 교환의 내용을 입증하지만 운영 결제, 재고 갱신, 내부 서버 결함을 증명하지는 않습니다.