DNS 欺骗攻击是网络安全领域最经典的中间人攻击手法之一它用极其低廉的成本就能让目标机器访问到完全错误的站点。我有几年在做内网渗透测试和红蓝对抗时反复用它做授权演练也用它给运维同事演示过为什么“明明上了 HTTPS 还是会被劫持”。这篇文章我会把完整的攻击原理、实验环境搭建、ettercap 和 bettercap 两套实操方案、检测防御手段以及我踩过的坑一次讲完内容只适用于你拥有明确授权的测试环境千万别拿到别人的网络里乱试。1. 演示环境与工具选型1.1 实验网络拓扑怎么搭做这类演示我强烈建议先在本地虚拟化环境里搭一套隔离网络别直接在办公室局域网里试。别以为“我就测一下没事”ARP 欺骗是全网段广播的一旦发出同网段所有设备都会收到你的毒化响应轻则 DNS 解析异常重则整个办公室断网极容易翻车。我的标准实验拓扑是三台虚拟机加一台虚拟网关全都在 VMware 的 Host-Only 网络里跑。Host-Only 模式的好处是虚拟机之间可以互通但和物理网络完全隔离攻击流量不会污染真实办公网。三台机器的角色分配是这样的角色操作系统IP 配置作用攻击机Kali Linux192.168.88.10运行 ARP 欺骗和 DNS 欺骗工具受害者机Windows 10 或 Ubuntu192.168.88.88被欺骗的目标模拟普通用户网关虚拟路由器或 Linux 网关192.168.88.1受害者正常上网的出口如果你没有单独的虚拟网关机器也可以用 VMware 自带的 NAT 网卡作为网关。但我还是建议单独起一台 Linux 网关因为在实际排查时你能在网关上抓包做对照分析更容易理解“正常 DNS 应答”和“伪造 DNS 应答”的区别。攻击机的网卡要设为固定 IP不要开 DHCP因为 ARP 欺骗过程中网卡 IP 必须稳定否则中途 IP 变了毒化关系就断了。受害者机的 DNS 设置也很关键。为了让演示更接近真实场景我把受害者的 DNS 指向网关也就是 192.168.88.1让网关来做 DNS 转发。这样攻击机需要欺骗的对象就是“网关”而不是互联网上的真实 DNS 服务器实验链路更短也更容易验证成功与否。如果你直接把受害者的 DNS 指向 114.114.114.114攻击机在 Host-Only 网络里是无法和公网 DNS 直接通信的演示就会失败。1.2 工具选型对比ettercap、bettercap 还是 dsniffDNS 欺骗可用的工具很多但真正适合做授权测试演示的其实就那么几个。我做了一个简单对比方便你按场景选工具优点缺点适用场景ettercap经典稳定插件丰富过滤器机制灵活界面老旧命令参数复杂传统渗透测试演示深入理解协议细节bettercap模块化设计自带 HTTP UI实时交互强部分模块依赖较新内核老系统兼容性一般快速演示、红队作战、实时调整攻击参数dsniff 套件轻量级arpspoof dnsspoof 组合简单工具链比较老多年没维护在最小化环境里做原理演示Cain AbelWindows 图形化上手极快只能在 Windows 老版本运行纯教学演示不适合新环境我个人在写本文这类“原理 操作演示”的文章时首选的是ettercap原因是它的过滤器机制能让你从底层看到 DNS 应答报文是怎么被篡改的这对理解攻击原理非常有帮助。bettercap 则更适合在红队实战中用因为它的模块化设计让攻击者可以边打边调参数。后面的实操我会把这两套都讲一遍你按自己的环境挑一个就行。2. 攻击原理与完整链路拆解2.1 DNS 解析流程回顾从“打电话问路”说起要理解 DNS 欺骗先得搞清楚正常情况下一个域名是怎么变成 IP 的。你可以把 DNS 系统想象成一个全国联网的电话查号台。当你在浏览器输入一个网址操作系统会先去查本地缓存——就像你手机里存的通讯录查到就直接拨号。没查到就会去问系统配置的“查号台”也就是你电脑里的 DNS 服务器。正常解析有一个容易被人忽略的关键点客户端完全信任 DNS 服务器的应答。它不会去验证这个应答是不是真的来自它刚才问的那个服务器也不会验证应答里面的 IP 地址是不是真的属于这个域名。DNS 协议设计于互联网早期当时根本没有考虑加密和身份认证的问题这就给伪造应答留下了巨大的操作空间。一个完整的标准 DNS 查询流程是这样的客户端首先查本地 hosts 文件和浏览器缓存。没命中就向递归服务器比如 114.114.114.114发起查询请求。递归服务器如果自己没有缓存会替客户端去根服务器找“管理机构”。管理机构告诉递归服务器“这个域名的权威服务器是 xxx”递归服务器再向权威服务器查询。权威服务器返回真实的解析结果。递归服务器把结果缓存并原样返回给客户端。整个过程客户端只发出一个问题收下一个答案。答案是真的还是假的客户端一概不验证。这就是 DNS 欺骗能成功的根本原因。2.2 欺骗为什么可能发生把“查号台”换成“诈骗前台”既然客户端不验证应答的真实性那攻击者就有一个大胆的思路伪造一份 DNS 应答抢在真实应答之前发给客户端。只要攻击者的伪造包先到客户端就把它当成标准答案写进缓存里后续访问全部指向攻击者指定的 IP。这里有个网络前提攻击者必须能看到客户端的 DNS 请求才能“抢答”。而在一个普通局域网里设备之间的通信是靠 MAC 地址而非 IP 地址完成的。正常情况下客户端的报文会先发给网关再由网关转发出去。攻击者如果想插一脚就必须先成为客户端和网关之间的“中间人”。成为中间人的主流手法就是 ARP 欺骗。大概过程是攻击者向受害者不停发送伪造的 ARP 响应声称“网关的 IP 对应我的 MAC 地址”同时向网关发送伪造响应声称“客户端的 IP 对应我的 MAC 地址”。这样一来受害者发出的流量全部先到攻击机攻击机再转给网关网关回给受害者的流量也先经过攻击机。攻击机就成了一个透明代理收发流量都从它手里过一遍。搞定了流量路径之后攻击机开始监听第 53 端口的 UDP 包。只要发现受害者发给 DNS 服务器的解析请求攻击机立刻伪造一个应答包里面写着自己想要域名指向的 IP然后发给受害者。真实的 DNS 服务器应答到达时受害者往往已经把这个伪造应答写进缓存了后面的解析都用这个假记录直到缓存超时。整条链路用一个场景来比喻你给查号台打电话问某公司的电话结果电话刚打出去坐在旁边的人抢过话筒报了一个假的号码。你还当真了存进通讯录之后每次都是打给这个假号码。2.3 不只是 ARP其他常见欺骗切入点少数情况下攻击者不走 ARP 欺骗直接改受害者的 DNS 配置也能达到类似效果比如通过 DHCP 下发假 DNS 地址或者在公网部署一个恶意 DNS 服务器并诱导用户把电脑 DNS 指过去。这类手法虽然没有 ARP 那么“中间人”但效果非常相近。之所以我在实验环境里坚持用 ARP 欺骗加 DNS 注入的组合是因为这种方式最能反映内网渗透测试中的真实攻击路径攻击者已进入目标局域网且拥有一个网段内的普通权限。从威胁建模的角度看DNS 欺骗的破坏力不止是“访问一个钓鱼网站”那么简单。它还能做邮件域名劫持、软件更新源替换、验证码短信接口伪造甚至配合 HTTPS 降级攻击把用户的加密会话降级为明文。我在一次授权的红队演练中用 DNS 欺骗把目标的软件升级域名指向内网钓鱼页面结果目标办公终端在十五分钟内就自动“升级”并安装了我们的测试载荷。这是个很有说服力的例子真实的攻击从来不是靠用户手滑而是靠协议本身的缺陷。3. 实操基于ettercap的完整演示3.1 过滤器脚本编写定制你的“假报”ettercap 的过滤器是一个小型脚本它能让攻击者对经过的报文做实时修改处理 DNS 报文时尤其好用。以 Kali 自带环境为例先创建一个文本文件比如我命名为dns_spoof.filter内容如下if (ip.proto UDP udp.src 53) { if (search(DATA.data, www.test.com) ! -1) { set(DATA.data, www.test.com); set(DATA.data 12, 192.168.88.88); log(DATA.data, dns_cheat.log); } }上面这段脚本的意思是当我们抓到 UDP 的 53 端口流量DNS 应答时如果里面带有www.test.com这个域名就把它后续的 IP 全改成192.168.88.88。set(DATA.data, www.test.com)这行比较关键它保证头部信息完整性然后我们从数据偏移 12 字节处写入假 IP。然后使用 etttercap 自带的编译器把它编译成可加载的二进制过滤器文件etterfilter dns_spoof.filter -o dns_spoof.ef编译过程如果语法有错会直接报出具体行号。我之前写脚本时经常因为少了一个右括号或者字符串长度不对而编译失败。现在这个例子里的域名长度必须在 12 字节附近时才方便直接写偏移如果要替换的域名更长或更短就得用其他方式处理报文长度字段。为了省麻烦你可以在演示时直接找一个和目标域名长度相近的域名或者通过修改请求报文的 QNAME 字段来保证应答内容一致。3.2 启动攻击命令参数逐条解释过滤器编译好之后先用一条命令开启 IP 转发。这一步经常有人忘记如果不开攻击机收到受害者的流量后不会转发给网关受害者就会直接断网演示失败。执行echo 1 /proc/sys/net/ipv4/ip_forward接下来启动 etttercap。推荐用命令行模式便于记录和复现ettercap -T -q -F dns_spoof.ef -M arp:remote /192.168.88.1// /192.168.88.88//这个命令的每个参数拆开来看-T使用文本界面输出方便把过程记录到日志。-q静默模式只显示关键操作避免刷屏。-F dns_spoof.ef加载刚才编译的过滤器文件。-M arp:remote启用 ARP 中间人模式。remote这个关键字非常重要它表示同时欺骗两个目标让流量双向都经过攻击机。/192.168.88.1//和/192.168.88.88//分别是网关和受害者的地址空段表示我们不管 MAC 地址让 etttercap 自己去探测。启动之后ettercap 会先做一轮主机探测然后在界面上显示 ARP 毒化的状态。你会看到类似 “MITM Attack: ARP Poisoning” 的提示这时候攻击已经开始生效了。我习惯另开一个终端跑tcpdump专门抓目标 IP 的 DNS 流量方便后面做对照验证。抓包命令是tcpdump -i eth0 host 192.168.88.88 and port 53 -w dns_log.pcap3.3 攻击效果验证与取证攻击链路搭好之后轮到了验证环节。在受害者机上做三件小事打开命令行执行nslookup www.test.com。用浏览器访问http://www.test.com看看是不是跳到了攻击机上的一个假页面。查看系统 DNS 缓存Windows 用ipconfig /displaydnsLinux 用systemd-resolve --statistics或直接dig www.test.com。正常情况下浏览器会显示攻击机提前用 Apache 或 Nginx 搭好的页面。为了增加真实性我通常在攻击机上放一个仿冒的登录页面标题写着“内部系统统一认证”这样可以直观地给客户演示钓鱼页面的效果。但要注意实际做授权测试时不能真的收集别人的账号密码展示到“到达钓鱼页面”为止伦理上更干净。攻击机这边用tcpdump打开刚才抓的 pcap 文件看 DNS 应答包的来源 IP。正常情况你会在包列表里看到两个不同的应答包来源一个是真实的 DNS 服务器一个是你自己的攻击机 IP。只要时间顺序上是你的伪造应答包先到受害者网卡攻击就算成功了。这就是所谓“竞态条件”抢答。我把自己在实战中的体会总结成一句经验不是每次伪造包都会抢到真实应答前面所以做演示时建议在受害者机上连续执行两三次解析查询提高成功率。4. 基于bettercap的备选演示方案4.1 bettercap 核心思路模块化框架ettercap 的过滤器够用但每次改一个域名都要重新编译在需要频繁调整参数的实战演示中效率偏低。后来我换了 bettercap 做这类测试理由很简单它的模块化设计让整个流程像搭积木一样清晰而且支持交互式命令行可以随时改配置。bettercap 把攻击能力拆成很多独立模块和 DNS 欺骗直接相关的有三个net.probe探测网段内的存活主机建立主机列表。arp.spoof负责开启 ARP 欺骗。dns.spoof负责 DNS 应答的监听和伪造。这种模块化设计对调试很友好。你在启动状态就可以用一条命令临时改目标域名或者改伪造 IP不用像 etttercap 那样停下来改文件再重编译。4.2 关键命令和配置先启动 bettercap进入交互式模式sudo bettercap -iface eth0随后按顺序执行以下命令。第一条是开启网段探测net.probe on这时候 bettercap 会列出它发现的网段主机。接着指定要欺骗的网关和受害者set arp.spoof.targets 192.168.88.1,192.168.88.88 arp.spoof on设置 DNS 欺骗的域名和伪造地址set dns.spoof.domains www.test.com, *.test.com set dns.spoof.address 192.168.88.88 dns.spoof on当dns.spoof on执行后bettercap 会在终端里实时打印它伪造的 DNS 响应记录。你可以边看日志边告诉客户哪些域名已经中招、伪造的解析结果是什么。它默认的状态非常直观强烈推荐在做现场演示时使用 bettercap。4.3 与 etttercap 方案对比两套方案的差异还是挺大的。ettercap 的过滤器让你能精确控制报文里的每一个字节适合教学和协议研究bettercap 则是典型的“弹药充足、操作简单”在攻防演练中效率极高。我用下面的表格做个总结方便你决策对比项etttercapbettercap上手难度中等需要理解过滤器语法低模块化命令直观调整灵活性改域名需要重新编译过滤器交互式命令行实时修改调试可见性界面抽象需要配合抓包工具直接打印伪造响应日志适用阶段培训教学、原理验证红队实战、现场演示如果你是在团队内部做技术分享我建议把这两套都练一遍。先用 etttercap 把原理讲透再用 bettercap 展示攻击者视角下真正的效率和隐蔽性。两套工具互相印证团队的防御意识会提升得更快。5. 检测识别与防御加固5.1 快速自查三招被 DNS 欺骗之后用户自己是很难有直观感觉的。页面照样能打开就是内容不对。如果你是网络管理员想在内部排查这类问题我建议从三个层面入手。第一招命令行对比解析结果。在怀疑被欺骗的机器上执行nslookup www.test.com然后换一个公共 DNS 再查一次nslookup www.test.com 114.114.114.114如果第一次返回的内网 IP 和第二次返回的完全不一样而且第一次的结果指向一个内网地址那么极大概率中招了。这个方法的原理是被欺骗时的解析结果由攻击者控制第二次通过公共 DNS 查询会走正常链路两条链路的结果差异就会被暴露出来。第二招抓包看应答来源。在受害者机器或接入交换机上抓 DNS 流量重点看应答包的源 IP。正常的 DNS 应答应该来自你配置的 DNS 服务器。如果应答包来自一个奇怪的 IP那一定是有人伪造了 DNS 响应。抓包命令参考tcpdump -i eth0 port 53 -n第三招查看 ARP 缓存。Windows 下执行arp -aLinux 下执行ip neigh查看网关的 MAC 地址是否和网络设备实际 MAC 一致。如果不一致说明 ARP 已被毒化。这个方法能定位到攻击者的 MAC再配合交换机的端口排查就能锁定物理位置。5.2 终端侧的硬防御终端侧的加固方向有两个加密查询和校验应答。DNSSEC 是目前主流操作系统都已经支持的安全扩展它的核心逻辑是让权威服务器对 DNS 应答做数字签名递归服务器解析时先验签验签失败就直接丢弃从根上杜绝伪造。虽然 DNSSEC 的部署率在国内还不算高但如果你的网络环境都支持最好还是开启。另一个方向是 DoHDNS over HTTPS和 DoTDNS over TLS它们把 DNS 查询封装进加密隧道里。攻击者如果在局域网里做了 ARP 欺骗看到的只是加密流量无法读取里面的查询内容自然也就无法精确定制伪造应答。浏览器层面Firefox 和 Chrome 都提供了内置的“安全 DNS”选项打开后会自动使用 DoH 方式向指定服务器查询。我建议内部办公网络统一做策略下发让所有终端默认开启 DoH。5.3 网络侧的纵深防御网络侧做防御的核心是让 ARP 欺骗失败。具体措施有交换机的 DHCP Snooping开启后交换机只信任从合法 DHCP 服务器收到的应答不信任其他来源的 DHCP 报文有效阻止攻击者用假 DHCP 下发恶意配置。动态 ARP 检测DAI交换机结合 DHCP Snooping 生成的 IP-MAC 绑定表校验所有 ARP 报文如果不匹配直接丢弃。这是针对 ARP 欺骗最有效的防线没有之一。端口安全Port Security限制交换机端口只能学习有限数量的 MAC 地址超过就自动关闭端口减少攻击者插入中间设备的可能。部署这些防御策略后即使攻击者手动设置了静态 ARP 条目来绕开 DAI也只能影响自己的那台机器无法污染全网。多层防御配合使用才能把 DNS 欺骗的生存空间压缩到最小。我在实际运维项目中经常跟客户强调“不管你多信任你的内网都假定内网里已经有攻击者然后在这个前提下做纵深防御。”这个思路在很多安全圈朋友的实践中都验证过比单纯依赖一个防病毒软件靠谱得多。6. 适用范围、法律边界与职业底线6.1 哪些场景可以合法演示我这里必须把适用范围说得非常清楚因为 DNS 欺骗这种技术用对了是安全评估的有力工具用错了就是违法行为。可以合法演示和使用的场景包括企业内部授权的红队攻防演练。你有书面授权的渗透测试项目且目标明确写入授权范围。自己搭建的隔离实验环境不涉及任何真实业务系统。CTF 竞赛和靶场训练平台。在上述场景中技术人员可以放心练习和研究。但一定要保留好授权文件、测试范围和测试时间窗口的记录方便事后审计。我在每次红队项目启动前都会要求客户出具授权书上面写清楚允许测试的域名、网段和时间段。这个习惯让我避免了很多不必要的麻烦也建议你尽早养成。6.2 绝对不能踩的红线以下行为无论如何都不能做后果很严重对未授权的外部网站或内网系统发起 DNS 欺骗攻击。使用 DNS 欺骗手段获取他人的账号、密码、验证码等敏感信息。干扰公共网络或他人的正常上网造成业务中断。办公网环境中长期执行中间人攻击即使是“演示”也不行。我的经验是技术演示的边界要提前跟自己的团队或客户达成书面共识。即使有授权也不要让演示环境接入生产业务网络。每一步操作都在可控的、可回滚的范围内进行才是从业者的起码素养。6.3 测试报告怎么写如果你是在认真做一次授权测试DNS 欺骗的发现和验证要写进报告里。我通常会把报告按这个结构组织目标范围说明测试了哪些网段、哪些域名。漏洞描述讲清楚攻击路径ARP 毒化 DNS 伪造。影响分析列出被欺骗的终端数量、受影响的业务系统、可能的数据泄露风险。复现步骤写明工具、命令、抓包证据。修复建议按照 DNS 加密、ARP 防护、网络分段三个层面给出整改优先级。报告里附上关键抓包截图和命令输出是加分项但注意隐去敏感信息。比如真正的账号密码是不能出现在报告里的示例数据和脱敏数据才是正确做法。7. 常见问题排查与避坑实录7.1 高频故障排查速查表我把自己在实验室和授权项目中遇到过的坑整理了一张表按“现象—原因—解决办法”対照查看现象可能原因解决办法开启 ARP 欺骗后目标完全断网攻击机 IP 转发未开启执行echo 1 /proc/sys/net/ipv4/ip_forwardDNS 注入一直不生效过滤器未编译或未加载确认-F参数指定的是.ef文件而不是源码文件抓不到流向攻击机的 DNS 包监听网卡不在预期网段检查-I eth0参数换成正确的接口受害者能上网但解析结果不变目标是直连公网 DNS未走网关调整受害者 DNS 指向网关或使用双向 ARP 欺骗bettercap 报错找不到模块模块未开启或语法错误用help dns.spoof查看具体用法伪造应答抢不到真实应答网络延迟较高连续多次触发解析请求尽量选择目标本地网络内模拟 DNS 服务器实验结束后受害者仍被劫持DNS 缓存未清理执行ipconfig /flushdns或systemd-resolve --flush-caches每次实验做完我还会顺手清理环境关闭 etttercap/bettercap、恢复 IP 转发为 0、在受害者机上刷新 DNS 缓存、检查 ARP 缓存。这样下次实验从零开始不会被上一次的状态干扰判断。7.2 三个容易被忽略的细节第一个细节是 ARP 缓存超时时间。在 Windows 系统里ARP 缓存默认超时大约 2 到 10 分钟而 Linux 的更短。这意味着 ARP 欺骗不是打一次就永久有效攻击者需要持续发送伪造 ARP 响应来维持毒化关系。如果你做演示时发现攻击时好时坏多半是攻击工具在后台发送 ARP 包的频率不够或者被系统的 ARP 防毒机制干扰了。第二个细节是双网卡机器的路由问题。攻击机如果既有 N AT 网卡又有 Host-Only 网卡ettercap 会默认走第一个接口导致欺骗报文发到了错误网段。所以做实验前一定要用ip addr确认攻击机当前的活动网卡并在启动工具时显式指定接口参数。第三个细节是受害者机器的防火墙。某些防火墙会拦截来自非网关 MAC 的 DNS 应答导致伪造包虽然到达了系统但被安全软件直接丢弃。遇到这种场景在授权前提下可以先查看防火墙日志确认是不是它吞掉了 DNS 注入报文。如果确实是防火墙拦截这也是你在报告里值得写一笔的重要发现。这三点我踩过多次每次都能用它们快速定位问题。说起来也挺有意思很多初学者做 DNS 欺骗演示失败不是攻击手法不对而是环境细节没照顾到。先把这些容易忽略的角落填平整套实验就会顺畅很多。最后再分享一个个人操作习惯我在做任何 DNS 欺骗演示前都会写一个简单的恢复脚本内容包含关闭 IP 转发、结束 etttercap/bettercap 进程、刷新受害者 DNS 缓存。这样实验结束马上就能把环境恢复到初始状态既节约时间也避免留下影响后续测试的脏数据。你在搭建自己的实验环境时强烈建议把这个脚本当作标配哪怕只是在自己电脑上跑虚拟机也能省不少事。