Introdução
Alder diz que a página de reservas da Lantern Room processou duas tentativas, mas apenas uma gerou uma reserva. A equipe de suporte tem um registro HTTPS autorizado e seu arquivo correspondente de chaves TLS. As duas tentativas usam o mesmo URI e a mesma conexão TCP, e outro visitante está presente no arquivo.
Você usará a interface real do Wireshark para identificar cada resultado do aplicativo e entregar uma pequena tabela de evidências e um conjunto de captura completo, legível de forma independente. Você deve ter concluído Read Your Authorized HTTPS Session ou já conhecer a configuração do arquivo de chaves TLS e Follow TLS Stream. Entrada básica no terminal e caminhos também são necessários. Este laboratório começa de forma independente com seus próprios registros controlados; sua duração estimada inclui leitura e erros comuns.
Associe cada tentativa ao seu resultado de negócio
Nesta etapa, você relacionará cada quadro original de requisição à própria resposta completa e registrará ambos os resultados.
Comece em Desktop → Applications → Terminal Emulator. Abra a entrada preparada no perfil vazio Booking:
wireshark -C Booking /home/labex/project/booking/input/casebook.pcapng
Maximize o Wireshark. Os dois arquivos de entrada somente para leitura são casebook.pcapng e casebook.keys; todos os resultados devem ficar em /home/labex/project/booking/output/. Os dados são sintéticos, mas cada handshake TLS, troca HTTP e segmento TCP foi gerado por um aplicativo local real e controlado.
Em Edit → Preferences → Protocols → TLS, configure (Pre)-Master-Secret log filename como:
/home/labex/project/booking/input/casebook.keys
Mantenha as duas opções de remontagem TLS habilitadas e clique em OK. O arquivo de chaves permite decifrar estas sessões registradas; não é uma chave geral para toda conexão HTTPS.
| Visitante | Endereço do cliente | Escopo |
|---|---|---|
| alder | 127.0.0.22 | As duas tentativas de reserva paper-lantern a explicar |
| birch | 127.0.0.23 | Outro visitante; exclua-o da entrega |
Aplique este filtro de exibição e pressione Enter:
ip.addr == 127.0.0.22 && http
ip.addr corresponde a qualquer extremidade. && exige as duas condições, portanto a visualização contém as mensagens HTTP decifradas de Alder nas duas direções. Espere duas requisições POST e duas respostas 200 OK. O URI /api/bookings e o fluxo TCP são compartilhados pelas duas tentativas; nenhum identifica sozinho uma transação.
Selecione o primeiro POST. No painel central de detalhes do pacote, expanda Hypertext Transfer Protocol pelo pequeno triângulo. Leia [Response in frame: ...] perto do final. Esse campo gerado relaciona a requisição à resposta que o Wireshark realmente associou a ela. Nos detalhes de protocolo dessa resposta, [Request in frame: ...] aponta de volta. Selecione a resposta vinculada na lista de pacotes. A coluna No. fornece o número original do quadro. O HTTP remontado pode aparecer no último segmento; use essas referências aos quadros de análise, em vez de adivinhar pela proximidade das linhas TCP.
Observe [Response in frame: 21] nos detalhes HTTP expandidos. Esse vínculo pertence à primeira requisição selecionada; a segunda tem outra resposta.
Clique com o botão direito na requisição e escolha Follow → TLS Stream. Leia a requisição e a resposta completas. O JSON da requisição identifica attempt, workshop e slot; a resposta repete esses valores. Leia accepted, reason e confirmation em conjunto. Depois, mais abaixo no mesmo fluxo, leia a segunda requisição e sua resposta.
A primeira tentativa de Alder é recusada porque a sessão está lotada: accepted é false, reason é "session_full", e confirmation é null. A nova tentativa é aceita e tem sua própria confirmação. As duas linhas de status HTTP são 200 OK: o servidor processou ambas as requisições, mas o resultado de negócio difere. Uma confirmação vista em outra parte do fluxo ou na visita de Birch não pode ser emprestada à tentativa recusada.
Feche Follow usando Close. O filtro de fluxo resultante inclui toda a conexão. Volte ao filtro original de Alder-e-HTTP acima para registrar os quatro números originais de quadro. Use este arquivo de entrada durante todo o exercício da tabela; um arquivo exportado renumera os pacotes.
Prepare attempts.csv, um pequeno índice de entrega que outro analista poderá conferir na captura. CSV significa valores separados por vírgulas: a primeira linha nomeia as colunas, e cada linha seguinte representa uma tentativa. São sete colunas:
| Coluna | Significado |
|---|---|
| attempt | O valor exato de attempt da requisição |
| request_frame | O quadro POST original no arquivo de entrada |
| response_frame | O quadro original de sua própria resposta vinculada |
| slot | O horário solicitado, repetido por essa resposta |
| accepted | true ou false do JSON da resposta |
| reason | O texto exato do motivo na resposta |
| confirmation | A confirmação dessa tentativa, ou um campo vazio para null |
Alterne para o terminal pelo painel inferior ou abra outro Terminal Emulator se o primeiro continuar ocupado pelo Wireshark. Inicie o editor de texto preparado:
mousepad /home/labex/project/booking/output/attempts.csv
Digite o cabeçalho exatamente como abaixo, seguido das duas linhas lidas na captura original. Não copie a palavra null para a coluna de confirmação: termine a linha da recusa com uma vírgula para representar o campo final vazio. Nenhum valor desses dados contém vírgulas, portanto não são necessárias aspas nos campos CSV. A ordem de linhas e colunas pode variar se os cabeçalhos continuarem correspondendo aos valores.
attempt,request_frame,response_frame,slot,accepted,reason,confirmation
Use File → Save e feche o editor. Confira se há uma linha para cada tentativa distinta e se cada uma aponta para a própria resposta. Se digitar um valor errado, reabra o mesmo arquivo com o comando acima, edite e salve. Um erro de digitação não exige nova captura nem redefinição da VM. Deixe o Wireshark aberto para a próxima etapa.
Entregue um conjunto de evidências legível de forma independente
Nesta etapa, você exportará uma conexão-alvo completa e a reabrirá com o arquivo de chaves entregue.
Comece em Desktop, com o Wireshark no arquivo original input/casebook.pcapng. Sua tabela indexa a fonte, enquanto a captura entregue deve conter somente a conexão TCP completa de Alder. O handshake TLS e os segmentos anteriores são necessários para decifrar e remontar os dados do aplicativo.
Substitua o filtro de exibição por:
ip.addr == 127.0.0.22
Isso mantém as duas direções e todas as camadas de protocolo de Alder. Selecione um POST decifrado, clique com o botão direito e escolha Follow → TLS Stream. Confirme que as duas tentativas pertencem a Alder e feche Follow com Close. Deixe o filtro tcp.stream eq ... ativo. Ele inclui toda a conexão selecionada, em vez de apenas as linhas identificadas como HTTP.
Escolha File → Export Specified Packets. Defina o formato pcapng, selecione Displayed e All packets dentro desse conjunto exibido. Salve em:
/home/labex/project/booking/output/evidence.pcapng
A caixa mostra Displayed e All packets, com 38 pacotes-alvo. O arquivo original tem 65 pacotes, portanto selecionar Captured também incluiria o outro visitante.
Não use Export Packet Dissections, que exporta resumos. Não exporte apenas as linhas http: elas podem omitir o handshake ou segmentos TLS/TCP anteriores necessários para decifrar e remontar. Não incorpore segredos por Inject TLS Secrets; o conjunto usa um arquivo de chaves separado.
Alterne para um Terminal Emulator e copie o arquivo autorizado de chaves para junto da saída. cp copia o primeiro caminho para o segundo, preservando a entrada original em vez de renomeá-la.
cp /home/labex/project/booking/input/casebook.keys /home/labex/project/booking/output/booking.keys
Esta entrega de treinamento permanece no mesmo escopo autorizado de análise. O arquivo fornecido contém segredos das sessões sintéticas no registro original; minimizar ou remover entradas do arquivo de chaves está fora deste exercício. A própria captura ainda deve excluir os pacotes de Birch. Arquivos de chaves correspondentes equivalentes são aceitos se decifrarem independentemente ambas as respostas-alvo completas.
Feche a janela principal do Wireshark e reabra o arquivo realmente exportado no perfil inicialmente vazio BookingReview:
wireshark -C BookingReview /home/labex/project/booking/output/evidence.pcapng
Em Edit → Preferences → Protocols → TLS, defina (Pre)-Master-Secret log filename para o arquivo de chaves de saída abaixo e clique em OK:
/home/labex/project/booking/output/booking.keys
Aplique http e siga um POST com Follow → TLS Stream. Leia novamente ambos os corpos completos de requisição e resposta. A exportação deve mostrar a recusa e a confirmação de Alder com suas próprias referências de attempt e nenhuma visita de Birch. Deve funcionar com o arquivo de chaves de saída, sem depender silenciosamente do caminho das chaves de entrada.
Leia o attempt repetido ao lado de cada resultado: a recusa não tem confirmação, e somente a nova tentativa tem ALDER-02-CONF. O título identifica o arquivo de saída evidence.pcapng.
Feche Follow e limpe o filtro de exibição para confirmar a presença do handshake e dos outros pacotes TCP. Este arquivo tem sua própria numeração de quadros; mantenha attempts.csv apontando para os quadros da entrada original. Feche a janela principal.
Se a saída estiver vazia ou faltar parte de um corpo, reabra a entrada, restaure o filtro da conexão completa de Alder e repita Export Specified Packets com Displayed → All packets, substituindo a saída incompleta. Se os pacotes continuarem criptografados, corrija o caminho do arquivo de chaves de saída nas preferências TLS. São problemas distintos: a falta das chaves impede a decifragem, enquanto segmentos ausentes na captura não podem ser recriados alterando uma preferência.
A entrega contém três arquivos reais: attempts.csv, evidence.pcapng e booking.keys. A captura e as chaves devem sustentar a tabela independentemente. Uma captura de tela ou uma afirmação de sucesso digitada não substitui a evidência real dos pacotes.
Resumo
Você distinguiu dois resultados de negócio transportados por códigos HTTP idênticos, associou cada requisição à própria resposta e registrou as referências originais dos quadros em uma tabela concisa de evidências. Você exportou toda a conexão TCP alvo e reabriu a saída real com seu arquivo de chaves separado.
A entrega de três arquivos pode ser verificada sem seu perfil Wireshark. Ela estabelece o que dizem essas trocas controladas de reservas; não comprova um pagamento de produção, uma atualização de estoque ou um defeito interno do servidor.
