DNS 与 ARP 流量分类实验

在 Arch Linux 工作站上完成的网络安全教育性数据包分析及解析器加固练习。

范围： 本仓库是一个学习项目。附带的流量捕获可用于练习 DNS 和 ARP 检查，但它本身不能证明存在实时的缓存投毒攻击、恶意硬件、对特定 CVE 的利用，或与 NetworkManager 路由度量存在因果关系。

我为何修订此项目

我的第一版分析将若干观察结果视为已确认的成因。那过于武断了。一个 839 字节的 DNS 帧并不自动意味着畸形或恶意，而 DNS-over-TLS 保护的是发往所配置上游解析器的 DNS 流量——它并不能阻止 ARP 欺骗或所有二层/三层攻击。

修订版保留了本实验中有用的部分，同时区分了：

1. 所提供数据展示的内容；
2. 我最初的怀疑；
3. 需要更多证据才能确认的内容；
4. 解析器配置实际改变的内容。

这种区分是良好事件调查工作的一部分。缩小结论范围总好过宣称超出证据支持的内容。

实验目标

• 使用 Wireshark 和 tshark 检查 DNS 与 ARP 流量。
• 在不将明文 DNS 误标为加密流量的前提下，将本地解析器结果与已知公共解析器进行比较。
• 配置 Unbound 通过经过认证的 TLS 转发上游 DNS 查询。
• 记录局限性及替代解释。
• 提供他人可重复执行的步骤。

环境

• Arch Linux 工作站
• Wireshark / tshark
• BIND dig
• Unbound 本地解析器
• Cloudflare 和 Quad9 上游解析器，经 TCP/853

实验室重跑时应记录确切的软件包版本。当前仓库所含版本元数据不足以将流量归因于某产品漏洞。

提供的证据

重现审查流程

1. 记录文件完整性

sha256sum evidence/incident_triage_snippet.pcap
capinfos evidence/incident_triage_snippet.pcap

将哈希值和捕获元数据连同你的笔记一并保存。不要把该捕获称为“完整事件证据”；它只是一个片段。

2. 审查 ARP 流量

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

查找重复或冲突的 IP 到 MAC 映射。冲突是需要调查的线索，而非存在攻击者的自动证明。检查这些地址是否为合成的实验数值、某个设备是否合法变更，以及时间线是否符合该假设。

3. 审查 DNS 流量

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

有用的后续过滤条件：

dns && frame.len == 839
dns.flags.response == 1
dns.qry.name == "."
arp.duplicate-address-detected || arp.duplicate-address-frame

仅凭数据包大小不能作为判定依据。DNS 响应大小可能因记录数、EDNS、DNSSEC 及传输行为而异。请检查解码后的记录，并与已知正常的基线进行比较。

4. 比较解析器

chmod +x scripts/checkdns.sh
./scripts/checkdns.sh example.com

该脚本会将直接使用 dig @1.1.1.1 的查询正确标注为端口 53 上的明文 DNS。当 kdig 可用时，它还会执行一次独立的 TLS 测试。

5. 验证 Unbound 转发

查看 configs/unbound.conf，根据本地系统调整证书路径，并在使用前进行验证：

sudo unbound-checkconf configs/unbound.conf
sudo ss -tnp | grep ':853'
dig @127.0.0.1 example.com

查询成功且与 TCP/853 建立连接，支持“Unbound 正在通过 TLS 将请求转发到所配置的上游”这一较窄的结论。这并不能证明无关的 ARP 或路由问题已被消除。

发现与局限

• 该捕获可用于识别 DNS 和 ARP 帧，并练习结构化审查。
• 839 字节的 DNS 帧只是一个观察结果，其本身并非失陷指标。
• 现有证据未指明存在存在漏洞的 BIND 9 解析器或受影响版本，因此 CVE-2025-40778 属于背景研究，而非事件归因。
• 经过认证的 DNS-over-TLS 提高了本解析器与其上游之间的机密性和完整性。它并不能保护整个本地网络。
• 强有力的归因需要完整的捕获来源、设备清单、解析器/版本证据、数据包编号引用、时间戳以及可重复的前后对比测试。

参考

• RFC 7858 — DNS over TLS
• RFC 8310 — DNS 隐私使用配置文件
• CVE-2025-40778 的 ISC 公告
• Wireshark 显示过滤器参考

法律与隐私说明

仅在你拥有或获授权测试的系统与网络上使用数据包捕获和网络测试工具。在发布捕获文件前，请检查其中是否包含私有地址、主机名、令牌、凭据及个人信息。