Anonimato & OPSEC
TCP Forensics no Wireshark: RST, perda e Zero Window
Investigue retransmissão, reordenação, RST e Zero Window com 47 pacotes controlados, frames identificados e prints do Wireshark real.
TCP forensics no Wireshark exige reconstruir a sequência de uma conversa. Retransmission, RST e Zero Window descrevem comportamentos diferentes. Um segmento repetido pode indicar uma confirmação atrasada, uma captura duplicada ou uma recuperação legítima. Um reset pode encerrar uma conexão normalmente. Uma janela zero indica pressão de recepção e não identifica, sozinha, um ataque.
Para transformar esses rótulos em evidência verificável, criamos um PCAP offline com quatro conexões fictícias, 47 pacotes e causas conhecidas. O Wireshark 4.6.9 identificou uma retransmissão, uma sequência de Zero Window e probes, um RST e um segmento fora de ordem. O tráfego usa endereços de documentação, não captura interfaces pessoais e não ataca nenhum serviço.
O mapa do laboratório TCP
Abra 20-tcp-forensics.pcap. O cliente é 192.0.2.10 e o servidor fictício é 198.51.100.20. As portas do servidor diferenciam os exercícios. A porta 80 inclui HTTP; 8081 demonstra janela zero; 8443 contém um encerramento por RST; 8082 apresenta entrega fora de ordem.
| Conversa | Frames importantes | Causa conhecida no gerador |
|---|---|---|
| TCP/80 | 6 e 7 | Repetição antes da confirmação |
| TCP/8081 | 20 a 23 | Janela zero, probe, confirmação e reabertura |
| TCP/8443 | 35 | Reset deliberado pelo servidor simulado |
| TCP/8082 | 41 e 42 | Bloco posterior aparece antes do intermediário |
Os handshakes estão presentes. Isso permite acompanhar os números relativos de sequência, a negociação de window scale e a origem de cada conversa. Em uma captura iniciada no meio da sessão, várias dessas informações poderiam estar ausentes.
Uma triagem que não mistura fenômenos
tcp.analysis.flags || tcp.flags.reset == 1
tcp.analysis.retransmission
tcp.analysis.zero_window || tcp.analysis.zero_window_probe
tcp.analysis.out_of_order
tcp.flags.reset == 1O filtro geral reúne eventos para triagem, mas não substitui a conversa completa. Quando encontrar um frame relevante, selecione-o e filtre pelo índice tcp.stream. Registre também a porta e o par de endereços. O número do stream depende da ordem em que as conexões aparecem no arquivo; não é um identificador global de rede.
Os rótulos exibidos foram produzidos pelo dissector do Wireshark. As causas do exercício são conhecidas porque os pacotes foram construídos offline.
Retransmissão: o mesmo intervalo de bytes voltou
No frame 6, o servidor envia os primeiros 100 bytes da resposta HTTP. No frame 7, repete esse intervalo depois de uma pausa controlada. A confirmação do cliente aparece somente depois. O Wireshark marca o segundo envio como TCP Retransmission.
Compare sequência, comprimento, ACK e direção. Um número de sequência não representa “o número do pacote”; identifica posição no fluxo de bytes. SYN e FIN também ocupam posições na sequência. Ignorar esse detalhe cria diferenças artificiais em contas de confirmação.
No laboratório, a repetição está explícita e não depende de perda real. Em produção, para afirmar que houve perda no enlace, seria útil comparar capturas em dois pontos ou métricas do transporte. O PCAP visto de um único local pode mostrar que bytes foram reenviados, sem revelar onde o primeiro envio foi descartado.
A RFC 9293 define o funcionamento básico de sequência, confirmação e estado TCP. A documentação da análise TCP do Wireshark esclarece que os rótulos são calculados sobre os segmentos observados.
Reordenação não é a mesma evidência que perda
Na conversa da porta 8082, o servidor envia A, depois C e só então B. O frame 41 cria uma lacuna na sequência observada. O frame 42 chega rapidamente e preenche a posição intermediária. No arquivo validado, ele aparece como TCP Out-Of-Order.
É tentador transformar “Previous segment not captured” em “o segmento foi perdido”. A frase informa uma ausência naquele ponto da observação. O segmento pode aparecer em seguida, ter passado por outro caminho ou não ter sido capturado naquele sensor. O nosso controle demonstra exatamente a primeira alternativa.
Construa uma linha do tempo com sequência inicial, intervalo de bytes e ACK do outro lado. Depois verifique se a lacuna foi preenchida e quando. Essa leitura conserva mais informação que contar todas as mensagens coloridas como retransmissões.
Zero Window: localizar quem não consegue receber
O frame 20 é enviado pelo servidor da porta 8081 e anuncia janela zero. Ele informa ao cliente que não há capacidade de recepção disponível naquele momento. A aplicação fictícia do lado servidor é o receptor pressionado; atribuir o problema automaticamente ao cliente inverteria o diagnóstico.
O frame 21 contém um probe de um byte. O frame 22 responde mantendo janela zero. O frame 23 reabre a janela. Depois, a transferência continua. O exercício não simula um link rompido: há resposta do receptor durante a pausa.
Entre o anúncio de janela zero no frame 20 e a reabertura no frame 23, o PCAP registra 1,818 segundo. Entre o segmento original do frame 6 e sua repetição no frame 7, registra 0,700 segundo. São durações impostas no cenário e medidas nos timestamps; não são estimativas de RTO calculado por um kernel real ou de desempenho da internet.
A pausa de recepção pertence à conversa TCP/8081. O frame 23 anuncia a retomada da capacidade de receber.
Em uma investigação operacional, relacione esse intervalo com CPU, memória, filas da aplicação e tempo de consumo do socket. Um proxy que demora para repassar dados pode produzir pressão parecida. A métrica útil é quanto tempo a janela permaneceu fechada e qual trabalho a aplicação executava, não apenas a existência de uma janela zero.
Window scale: evitar a leitura errada do número
Os handshakes do laboratório negociam escala 7. Um campo bruto de 512 passa a representar 65.536 bytes nas mensagens posteriores. A árvore TCP mostra tanto o valor bruto quanto o tamanho calculado. A janela zero continua zero mesmo com escala.
Se a captura não tiver o handshake, a escala pode não ser conhecida com a mesma confiança. Registre essa limitação antes de comparar o tamanho de janelas entre arquivos. Uma diferença aparente de capacidade pode ser apenas uma diferença de informação disponível para o analisador.
RST: distinguir encerramento de hipótese de injeção
No frame 35, o servidor fictício encerra a terceira conversa com RST e ACK. O gerador conhece a origem desse reset. O pacote não comprova exploração, bloqueio de firewall ou ataque externo. Ele serve para estudar como a interrupção aparece na captura.
Em um caso desconhecido, compare direção, sequência, confirmação, TTL, momento e comportamento posterior dos dois lados. Um reset fora do intervalo esperado pode não ser aceito pelo endpoint. A presença do pacote na rede e seu efeito no estado da conexão são fatos diferentes.
TTL diferente pode resultar de outro caminho, equipamento intermediário ou sistema operacional. Ele pode reforçar uma hipótese quando combinado com várias evidências, mas não identifica sozinho um emissor falsificado. A RFC 5961 é uma referência para entender mecanismos de resistência a resets indevidos, sem assumir que todo dispositivo implementa exatamente o mesmo comportamento.
Captura e offload também produzem pistas enganosas
Em capturas feitas no próprio endpoint, funções de offload podem alterar a aparência de checksums e tamanhos. Em espelhamento de portas, duplicação e descarte pelo sensor também mudam o conjunto visto. Compare as condições de captura antes de concluir que uma anomalia do analisador é uma anomalia do tráfego enviado.
Nossos pacotes foram validados com verificação de checksum IPv4, TCP e UDP habilitada. Não foram encontrados frames malformados. Essa validação elimina erros do gerador como explicação para os eventos escolhidos, mas não transforma um arquivo offline em medição de qualidade de rede física.
Uma extração curta para o relatório
tshark -n -r 20-tcp-forensics.pcap -Y "tcp.analysis.flags || tcp.flags.reset == 1" -T fields -e frame.number -e frame.time_relative -e tcp.stream -e tcp.seq -e tcp.ack -e tcp.len -e tcp.window_size -e _ws.col.InfoO relatório deve separar evento observado, interpretação e dado necessário para confirmar a causa. Por exemplo: “houve repetição de 100 bytes no frame 7 antes do ACK”, “compatível com recuperação após confirmação atrasada” e “captura no servidor ou telemetria TCP necessária para localizar a perda”. Essa estrutura permite revisar a conclusão quando surgirem novas evidências.
Roteiro de investigação TCP
- Determine quais lados da conversa estão presentes e se há handshake.
- Separe as conexões por stream e direção.
- Reconstrua intervalos de sequência e confirmações.
- Meça tempo de pausa, repetição e reabertura da janela.
- Confira reordenação antes de contabilizar perda.
- Vincule resets ao estado e ao efeito observado.
- Registre hipóteses alternativas e condições de captura.
O pacote da série inclui esse PCAP e o manifesto de frames. O objetivo é produzir uma conclusão que outra pessoa consiga conferir, preservando a diferença entre comportamento TCP, problema de aplicação e hipótese de ataque.
