Triagem forense de envenenamento de cache DNS em hardware legado. Inclui análise de PCAP de injeções de registros não solicitados de 839 bytes, mapeamento CVE-2025-40778 e remediação via Unbound (DoT) endurecido no Arch Linux.
Um exercício educacional de análise de pacotes e fortalecimento de resolvedor realizado em uma estação de trabalho Arch Linux.
Escopo: Este repositório é um projeto de aprendizado. A captura incluída é útil para praticar inspeção de DNS e ARP, mas não prova, por si só, um ataque de envenenamento de cache ativo, hardware malicioso, exploração de uma CVE específica ou uma conexão causal com uma métrica de roteamento do NetworkManager.
Meu primeiro relatório tratou várias observações como causas confirmadas. Isso foi excessivo. Um quadro DNS de 839 bytes não é automaticamente malformado ou malicioso, e DNS-over-TLS protege o tráfego DNS para o resolvedor upstream configurado—ele não impede spoofing ARP ou todos os ataques de Camada 2/3.
A versão revisada mantém as partes úteis do laboratório enquanto separa:
Essa distinção faz parte de um bom trabalho de incidente. É melhor restringir uma conclusão do que afirmar mais do que as evidências suportam.
tshark.tsharkdigVersões exatas dos pacotes devem ser registradas quando o laboratório for reexecutado. O repositório atual não contém metadados de versão suficientes para atribuir o tráfego a uma vulnerabilidade de produto.
| Caminho | Propósito |
|---|---|
evidence/incident_triage_snippet.pcap | Amostra pequena de captura de pacotes usada para inspeção DNS/ARP |
evidence/wireshark_anomoly.png | Nome de arquivo de captura de tela legado mantido para histórico do repositório; anomaly é a grafia correta |
reports/ANALYSIS.md | Revisão baseada em evidências e limitações |
scripts/checkdns.sh | Compara a saída do resolvedor e rotula claramente o transporte |
configs/unbound.conf | Exemplo de configuração de encaminhamento do Unbound usando DNS-over-TLS |
logs/remediation_validation.txt | Exemplo de saída de validação com conclusões corrigidas |
CVE_RESEARCH.md | Explica por que as evidências disponíveis não suportam uma atribuição de CVE |
sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap
Salve o hash e os metadados da captura com suas anotações. Não chame a captura de “evidência completa de incidente”; é um trecho.
tshark -r evidence/incident_triage_snippet.pcap -Y arp \
-T fields -e frame.number -e frame.time_relative \
-e arp.opcode -e arp.src.proto_ipv4 -e arp.src.hw_mac \
-e arp.dst.proto_ipv4 -e arp.dst.hw_mac
Procure por alegações repetidas ou conflitantes de IP para MAC. Um conflito é uma pista para investigar, não prova automática de um atacante. Verifique se os endereços são valores sintéticos de laboratório, se um dispositivo mudou legitimamente e se o tempo suporta a hipótese.
tshark -r evidence/incident_triage_snippet.pcap -Y dns \
-T fields -e frame.number -e frame.time_relative \
-e ip.src -e ip.dst -e udp.srcport -e udp.dstport \
-e dns.id -e dns.flags.response -e dns.qry.name \
-e dns.count.answers -e frame.len
Filtros úteis de acompanhamento:
dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame
O tamanho do pacote por si só não é um veredito. Os tamanhos das respostas DNS podem variar devido à contagem de registros, EDNS, DNSSEC e comportamento de transporte. Inspecione os registros decodificados e compare-os com uma linha de base conhecida como boa.
chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com
O script rotula corretamente uma consulta direta dig @1.1.1.1 como DNS em texto simples na porta 53. Quando kdig está disponível, ele também realiza um teste TLS separado.
Revise configs/unbound.conf, adapte os caminhos dos certificados para o sistema local e valide antes do uso:
sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com
Uma consulta bem-sucedida mais uma conexão estabelecida com TCP/853 suporta a conclusão mais restrita de que o Unbound está encaminhando para o upstream configurado via TLS. Isso não prova que um problema não relacionado de ARP ou roteamento foi eliminado.
Use ferramentas de captura de pacotes e teste de rede apenas em sistemas e redes que você possui ou está autorizado a testar. Revise capturas em busca de endereços privados, nomes de host, tokens, credenciais e informações pessoais antes de publicá-las.