NetCatTest

Anonimato & OPSEC

IPv6 no Wireshark: extensões, fragmentos e ICMPv6

Siga cabeçalhos de extensão, NDP e remontagem IPv6. Um laboratório mostra fragmentos completos, ausência de parte final e DNS citado dentro de ICMPv6.

Por Daniel Felipe 8 min leitura

IPv6 forensics no Wireshark exige seguir a cadeia de cabeçalhos e o contexto de remontagem. Procurar apenas TCP ou UDP pode perder fragmentos e mensagens de controle. Um pacote ICMPv6 ainda pode incluir uma cópia do pacote que provocou o erro, fazendo um filtro encontrar protocolos que estão citados dentro dele.

O laboratório NetCatTest contém dez pacotes construídos offline: descoberta de vizinho, anúncio de roteador, consulta DNS com extensões, resposta fragmentada, Packet Too Big e uma remontagem deliberadamente incompleta. O Wireshark 4.6.9 real foi usado para validar os campos. Os endereços unicast usam 2001:db8::/32; multicast e link-local foram gerados como parte do cenário, sem captura da rede pessoal.

Um conjunto pequeno com diferenças importantes

Abra 29-ipv6.pcap. O tamanho reduzido ajuda a comparar cada frame sem ruído. Ele não mede o volume de uma rede real e não demonstra ataque contra um roteador. As condições de cada caso foram definidas no gerador e podem ser reproduzidas a partir do arquivo.

FrameConteúdoPergunta de investigação
1Router AdvertisementQuem anunciou o prefixo e com quais parâmetros?
2 e 3Neighbor Solicitation e AdvertisementQual vizinho foi procurado e qual respondeu?
4Hop-by-Hop, Destination Options e DNSQual a cadeia até o transporte?
6 e 7Resposta DNS fragmentadaA remontagem terminou?
8Packet Too BigQual pacote foi citado no erro?
9 e 10Fragmentos sem a parte finalO que permanece desconhecido?

Neighbor Discovery: contexto antes de suspeita

O frame 1 anuncia o prefixo fictício 2001:db8:50::/64. Os frames 2 e 3 mostram a procura e a resposta para 2001:db8:50::20. Expanda ICMPv6 e confira tipo, endereço alvo e flags. Não trate o endereço IPv6 de origem como substituto do campo Target Address.

icmpv6.type == 134
icmpv6.type == 135 || icmpv6.type == 136
ipv6.hlim == 255 && icmpv6

A RFC 4861 descreve Neighbor Discovery. No laboratório, o anúncio é um controle legítimo sintético. Em uma empresa, classificar um roteador como indevido exigiria confrontar o emissor com a topologia e a política autorizada, além de observar o efeito sobre os hosts.

Um anúncio diferente do esperado pode justificar investigação. Ainda assim, o PCAP precisa mostrar qual prefixo, lifetime e flags foram anunciados. Um alerta genérico de “RA encontrado” não diferencia o funcionamento normal da rede de uma configuração não autorizada.

Cabeçalhos de extensão: acompanhar cada Next Header

O frame 4 inclui IPv6, Hop-by-Hop Options, Destination Options, UDP e DNS. As opções do exercício são de preenchimento, sem payload de exploração. A consulta solicita AAAA para api.aurora.test.

Expanda os cabeçalhos na ordem em que aparecem. O campo Next Header aponta a próxima unidade da cadeia. Não se deve assumir que o transporte começa imediatamente depois dos 40 bytes do cabeçalho IPv6 base. Esse atalho pode gerar parsers que deixam de encontrar portas ou interpretam bytes de uma extensão como se fossem TCP.

ipv6.hopopts
ipv6.dstopts
ipv6.hopopts && ipv6.dstopts && dns && !icmpv6

Wireshark real detalhando Hop by Hop, Destination Options, UDP e DNS no frame IPv6 de laboratório

O filtro exclui ICMPv6 para selecionar a consulta original. O mesmo conteúdo também aparece citado em uma mensagem de erro posterior.

A RFC 8200 é a referência do IPv6 e de seus cabeçalhos. Para investigação, o ganho imediato é registrar a cadeia observada e distinguir presença de extensão, validade de enquadramento e comportamento aceito pelo endpoint.

Fragmentação: identificar o conjunto antes de contar mensagens

Os frames 6 e 7 pertencem à mesma resposta DNS fragmentada, com identificação 0x29000001. O conjunto utiliza um tamanho de fragmento controlado para caber no orçamento de 1.280 bytes do exercício. No frame 7, a remontagem permite interpretar a resposta com dez registros TXT fictícios.

ipv6.fraghdr
ipv6.fraghdr.ident == 0x29000001
ipv6.reassembled.in
ipv6.reassembled.length

Verifique offset, More Fragments, identificação e endpoints. Um identificador isolado não é suficiente para agrupar fragmentos de toda uma rede. A sessão de remontagem precisa considerar também os endereços e a cadeia de protocolo.

Wireshark real mostrando fragmentos IPv6 e resposta DNS reconstruída no laboratório

O conjunto 0x29000001 foi remontado. O conjunto 0x29000002 está incompleto por construção e não autoriza inferir seu conteúdo final.

Remontagem incompleta: ausência de evidência deve continuar visível

O segundo conjunto, com identificação 0x29000002, aparece nos frames 9 e 10. A última parte foi omitida deliberadamente. O arquivo permite observar os fragmentos disponíveis, mas não reconstruir uma mensagem completa desse conjunto.

Não classifique essa condição automaticamente como ataque de fragmentação. Em uma rede real, o último fragmento pode ter sido perdido, não espelhado, descartado pelo sensor ou transmitido fora da janela de captura. O laboratório demonstra o limite de informação, sem provar uma causa operacional.

Um relatório útil registra o conjunto, os offsets encontrados, o intervalo de tempo coberto e a falta de conclusão. Também explica qual nova captura ou telemetria permitiria diferenciar perda no caminho de perda na observação.

Packet Too Big: o pacote interno é uma citação

O frame 8 contém ICMPv6 Packet Too Big com MTU 1.280 e uma cópia da consulta do frame 4. Por isso, o filtro ipv6.hopopts && ipv6.dstopts && dns retorna dois frames: a consulta original e o erro que a cita. Não significa que duas consultas novas foram enviadas.

Essa é uma armadilha concreta de protocolo dentro de protocolo. Para selecionar somente a consulta original no nosso conjunto, acrescente && !icmpv6. Em capturas diferentes, confira a árvore antes de transportar esse filtro para uma regra ampla.

A RFC 4443 descreve ICMPv6. A mensagem de erro fornece uma indicação observada, mas seu efeito sobre a aplicação depende de como o endpoint a processou. O PCAP deste exercício não demonstra redução real de MTU em uma interface.

MTU mínima e diagnóstico de caminho

O número 1.280 aparece como parâmetro do cenário. Não use sua presença para declarar que uma interface estava configurada dessa maneira ou que um enlace real tinha aquele limite. Diferencie valor anunciado em uma mensagem, limite configurado e comportamento confirmado por teste.

Em um caso operacional, correlacione o erro com o pacote citado, retransmissões, tamanho das mensagens e logs do endpoint. Evite repetir tráfego grande contra terceiros apenas para “confirmar” uma hipótese. Um ambiente de reprodução autorizado permite isolar tamanho, extensão e tratamento de ICMP sem afetar produção.

Como testar parsers e sensores com este conjunto

Um parser deve conseguir seguir a cadeia até UDP, manter as duas perspectivas do frame ICMPv6 e não declarar conteúdo completo quando o reassembly não terminou. O arquivo fornece controles positivos e negativos para essas três condições.

Compare a saída de duas ferramentas com os mesmos bytes. Se uma disser “DNS” no frame 8 e outra disser apenas “ICMPv6”, isso pode refletir diferentes níveis de dissecação, não necessariamente uma falha de segurança. O passo seguinte é perguntar se a ferramenta manteve a informação de que o DNS estava citado dentro do erro.

tshark -n -r 29-ipv6.pcap -Y "ipv6.fraghdr" -T fields -e frame.number -e ipv6.src -e ipv6.dst -e ipv6.fraghdr.ident -e ipv6.fraghdr.offset -e ipv6.fraghdr.more
tshark -n -r 29-ipv6.pcap -Y "icmpv6.type == 2" -T fields -e frame.number -e icmpv6.mtu -e _ws.col.Info

O que poderia sustentar uma suspeita de evasão

Diferenças consistentes entre o que o endpoint processa e o que um sensor reconhece merecem investigação. A presença de extensões ou fragmentos, por si só, não prova evasão. É necessário um experimento que compare aceitação, reconstrução e decisão do controle em condições equivalentes.

Nossos pacotes não tentam explorar um produto. Eles mostram como criar uma base de comparação antes de investigar uma divergência. O exercício pode apoiar testes de regressão de parsers sem introduzir payloads contra redes reais.

Checklist IPv6 para preservar o contexto

  1. Registre o papel de unicast, link-local e multicast no cenário.
  2. Leia a cadeia completa de Next Header.
  3. Vincule mensagens NDP ao inventário e ao alvo anunciado.
  4. Agrupe fragmentos por contexto e identificação.
  5. Declare quando a remontagem está incompleta.
  6. Diferencie pacote original e pacote citado em ICMPv6.
  7. Use efeito no endpoint para confirmar hipóteses operacionais.

O pacote de laboratórios contém a captura e os resultados esperados. A referência IPv6 do Wireshark permite conferir campos da versão instalada. A conclusão mais útil mantém a hierarquia: uma extensão é parte da estrutura, um fragmento é parte da mensagem e uma citação de erro é parte de outra observação.

Escrito por

Daniel Felipe é criador do NetCatTest e produz conteúdos sobre cibersegurança, privacidade digital, OSINT, laboratórios autorizados e ferramentas para estudo técnico responsável.

Compartilhar

Enviar este artigo