nicholasC03/DNS-Poisoning-Triage-Lab

# DNS 与 ARP 流量分流实验室 这是一项在一台 Arch Linux 工作站上完成的教育性数据包分析与解析器加固练习。 ## 为什么我要修改这个项目 我的第一份报告将几项观察结果视为已确认的原因。这种说法过于绝对。一个 839 字节的 DNS 数据帧并不一定就是恶意的或畸形的，而且 DNS-over-TLS 仅保护发往已配置的上游解析器的 DNS 流量——它无法阻止 ARP 欺骗或所有 Layer 2/3 攻击。 修订后的版本保留了实验室中有用的部分，同时区分了： 1. 提供的数据展示了什么； 2. 我最初怀疑什么； 3. 什么需要更多证据； 4. 解析器配置实际改变了什么。 这种区分是良好的事件处理工作的一部分。缩小结论的范围，总好过提出超出证据支持的声明。 ## 实验室目标 - 使用 Wireshark 和 `tshark` 检查 DNS 和 ARP 流量。 - 将本地解析器结果与已知的公共解析器进行比较，且不将明文 DNS 错误标记为加密流量。 - 配置 Unbound 通过经过身份验证的 TLS 转发上游 DNS 查询。 - 记录局限性和其他可能的解释。 - 提供可供他人重复操作的步骤。 ## 环境 - Arch Linux 工作站 - Wireshark / `tshark` - BIND `dig` - Unbound 本地解析器 - 通过 TCP/853 的 Cloudflare 和 Quad9 上游解析器 重新运行实验室时应记录确切的软件包版本。当前的代码库没有包含足够的版本元数据来将流量归因于某个产品漏洞。 ## 提供的证据 | 路径 | 用途 | |---|---| | `evidence/incident_triage_snippet.pcap` | 用于 DNS/ARP 检查的小型数据包捕获样本 | | `evidence/wireshark_anomoly.png` | 保留用于代码库历史记录的旧版截图文件名；正确的拼写应为 `anomaly` | | `reports/ANALYSIS.md` | 基于证据的审查和局限性说明 | | `scripts/checkdns.sh` | 比较解析器输出并清晰标记传输方式 | | `configs/unbound.conf` | 使用 DNS-over-TLS 的 Unbound 转发配置示例 | | `logs/remediation_validation.txt` | 包含修正后结论的验证输出示例 | | `CVE_RESEARCH.md` | 解释为什么现有证据不足以支持 CVE 归因 | ## 复现审查过程 ### 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](https://www.rfc-editor.org/rfc/rfc7858) - [RFC 8310 — DNS 隐私使用配置](https://www.rfc-editor.org/rfc/rfc8310) - [CVE-2025-40778 的 ISC 安全公告](https://kb.isc.org/docs/cve-2025-40778) - [Wireshark 显示过滤器参考](https://www.wireshark.org/docs/dfref/) ## 法律与隐私声明 请仅在你拥有或被授权测试的系统和网络上使用数据包捕获和网络测试工具。在发布捕获数据之前，请检查其中是否包含私有地址、主机名、token、凭据和个人信息。

标签：Cutter, DNS安全, GitHub Advanced Security, 安全加固, 流量取证, 网络协议分析