ARP与DNS欺骗工具包:从原理到复现的中间人攻击演示指南
简介面向高校网络安全课程第三次实验的ARP与DNS欺骗教学演示工具包基于Go语言编写用于在受控课堂环境中模拟地址解析协议欺骗和域名系统劫持展示中间人攻击的数据截获与篡改原理。压缩包内含6个文件以Go源码、YAML配置和说明文档为主另有License与版本管理配置整体约10KB轻量易部署适合学生在指导老师监督下完成实验操作。目前已有99人浏览学习属于小型但针对性较强的教学资源。学习者可从源码中看到ARP嗅探与响应伪造逻辑、DNS应答注入接口并通过配置文件调整关键参数结合说明文档中的步骤演示既能复现攻击流程也能据此设计防御策略加深对网络协议脆弱性与安全防护措施的理解。需特别强调的是该工具仅限合法教学场景使用任何非法用途均不被允许。1. 课堂演示里的“黑匣子”终于被拆开了这份工具包能带你完整走一遍欺骗链路某高校的计算机网络安全实验课上老师想演示ARP欺骗加DNS欺骗组成的中间人攻击结果打开某图形化工具点了两下屏幕上只跳出一句“攻击成功”学生全程没弄明白底层发生了什么。这份ARPDNS欺骗工具包就是冲着这个痛点来的它用命令行工具替代黑匣子你能亲眼看到发出的每一个ARP包也能自己编写DNS重定向列表把欺骗链路从原理到复现完整拆开。适合课堂演示、实验报告和想入门网络攻防的初学者。这里要强调一句它只允许在你有合法授权的测试环境里使用严禁用于任何非法用途。2. ARP 与 DNS 欺骗原理两个“信任缺陷”如何串成一条演示链路2.1 ARP 无认证把网关“顶替”掉的最小步骤ARP协议设计的核心前提是“局域网内所有设备都可信”。一台主机要跟另一台通信时先发广播问“谁的IP是192.168.1.1请告诉我你的MAC地址”然后所有收到广播的设备里只有目标IP的主机回单播应答其他设备保持沉默。问题在于这个应答没有任何身份验证任何一台机器都可以主动向别人发送“192.168.1.1的MAC地址是AA:BB:CC:DD:EE”的应答包接收方不做任何校验就更新自己的ARP缓存表。这就是ARP欺骗能成立的根本原因。攻击者要做的事情只有一件持续向目标主机发送伪造的ARP应答告诉它“网关的IP对应攻击机的MAC地址”。目标主机一旦相信就会把原本发给网关的流量全部投向攻击机的网卡。演示时最直观的现象就是目标主机ping网关不通但攻击机能通。这个过程中攻击机不需要做任何流量转发单纯通过ARP缓存投毒就能把目标主机“变成网络孤儿”。课堂演示时要理解三个角色的关系角色演示环境中的实体需要提前确认的信息攻击机运行工具包的Linux主机本机IP、网卡接口名、root权限目标主机被演示的终端设备目标IP、目标MAC网关局域网出口网关IP、网关MAC为什么不用Scapy现写一个脚本因为真正的课堂演示看的是稳定性和可观测性。Scapy写一个循环发包脚本很容易但包的发送间隔、MAC地址更新时机、以及持续运行时的资源占用都需要自己调调试过程中学生看到的是“脚本报错”而不是“攻击过程”。arpspoof这类经过大量场景验证的命令行工具发包节奏稳定日志输出简洁课堂时间有限把精力放在讲原理上而不是和Python库的版本较劲。2.2 DNS 应答劫持让“域名解析”替你指路ARP欺骗解决的是“流量路径”问题DNS欺骗解决的是“流量目的地”问题。目标主机在浏览器里输入一个域名时会先向DNS服务器发起解析请求。DNS欺骗的思路是在攻击机上监听UDP 53端口的查询包抢在真实DNS服务器之前返回一个伪造的应答告诉目标主机“这个域名对应我指定的IP”。工具包里的dnsspoof承担的就是这项工作。它的配置方式非常直观一个文本文件每行写“IP 域名”表示“当有人查询这个域名时返回前面的IP”。课堂演示时攻击机可以先用Apache或Nginx在本地或者另一台测试机上挂一个简单的演示页面然后在配置里把某个域名指向这个页面的IP。目标主机访问该域名时看到的是攻击者准备好的页面而真实服务器收不到任何请求。有一点容易被忽略dnsspoof只拦截配置文件中出现的域名其他域名会正常放行。这个设计对课堂演示很友好你可以只针对某个特定域名做重定向不影响其他网络服务。如果把配置写反了域名写在前面、IP写在后面dnsspoof会直接报错或加载空配置这个细节后续避坑章节再展开。从工具链的角度说arpspoof和dnsspoof都属于同一套命令行网络审计工具集安装时可以一次性装好。使用这套工具而不是单独找两个互不相关的程序最大的好处是参数风格统一、依赖关系简单而且两者配合做中间人时不需要额外开发桥接逻辑。网络实验课的时间有限主流的方案就是先用它把链路跑通再让学生基于抓包去理解每一个包的结构。3. 环境准备与依赖安装从哪里开始搭演示环境3.1 平台选型与依赖清单为什么选 dsniff 而不是新写的脚本这套工具包在Linux环境下运行最省事Debian系发行版比如Ubuntu、Kali都行Windows原生环境下arpspoof跑不了。如果你手头只有Windows一个常见做法是装虚拟机用桥接模式把攻击机放到目标主机所在的局域网里。需要注意虚拟机的NAT模式不能用来做ARP欺骗演示因为NAT模式下虚拟机处在另一个子网ARP请求根本到达不了目标主机。这一点在第5章还会再踩一遍。依赖方面工具包本身依赖libpcap抓包和发包的底层库和libnet构造网络包。在Debian系上安装dsniff套件时这两个库会自动作为依赖装上不需要手动编译。这里给出一组适合课堂环境的安装命令# 更新软件包索引 sudo apt update # 安装 dsniff 套件包含 arpspoof 和 dnsspoof与 ifconfig 工具 sudo apt install -y dsniff net-tools # 验证工具是否就位 which arpspoof which dnsspoof第一条命令更新软件源保证后面装到的包是仓库里可用的版本。第二条命令里的dsniff是主工具集它会带来arpspoof、dnsspoof、tcpkill、urlsnarf等一票工具net-tools提供ifconfig和arp命令方便查看网卡和ARP缓存。安装时如果遇到网络慢导致超时换一个国内软件源再执行apt update。为什么建议直接装dsniff而不是自己写脚本因为课堂演示过程中需要快速切换演示场景dsniff套件的工具互相配合成熟arpspoof把流量引过来dnsspoof做DNS应答劫持再用tcpdump或Wireshark抓包验证结果。每个阶段出问题时命令行日志足够清晰学生能直接看到发包计数。写脚本还要处理异常退出、进程清理等问题演示课上不值得为此消耗时间。3.2 安装、校验网卡与 IP把工具跑起来的最低前置条件工具装好之后先别急着开跑花两分钟确认网络环境。攻击机的网卡接口名在不同机器上不一样常见的有eth0、ens33、wlan0无线网卡则是wlan0之类的名字。先看接口名和IP再看网关地址最后确认目标主机在线。# 查看所有网卡接口和IP地址 ip addr show # 查看默认网关 ip route | grep default # 确认目标主机在线 ping -c 3 192.168.1.100 # 查看本机ARP缓存 arp -nip addr show输出里的eth0或wlan0就是后面arpspoof命令要用的接口名ip route里default那一行能读出网关IPping目标主机时要确保目标主机防火墙允许ICMP回显否则会出现“目标明明在线但ping不通”的误判。arp -n会把当前局域网内已知的IP与MAC对应关系列出来演示开始前记录一下网关真实的MAC地址之后欺骗是否生效就有对比依据。还有一个容易被忽略的点arpspoof需要root权限运行。如果你用的是普通用户命令前要加sudo否则会报“permission denied”或“socket: Operation not permitted”。在课堂环境里如果学生的账户拿不到sudo权限可以让老师预先用root启动一个Shell会话或者直接在教学用的root权限虚拟机里做实验。最后建议快速跑一次sudo arpspoof -i eth0 -t 192.168.1.100 192.168.1.1验证工具能正常发包跑几秒直接CtrlC停掉确认无报错。这一步能提前暴露网卡驱动或依赖库的问题免得正式演示到一半发现工具起不来。演示用的几个IP建议统一记在实验报告里攻击机IP、目标IP、网关IP、DNS欺骗时使用的页面服务器IP。4. 实战操作从单向欺骗到 DNS 重定向的完整流程4.1 单向 ARP 欺骗先让靶机“找不到网关”第一阶段演示的是纯粹的ARP欺骗断网效果。在这个阶段攻击机扮演的是“捣乱者”的角色它要做的事情就是不断向目标主机发送伪造的ARP应答告诉目标“网关的MAC地址是攻击机网卡的MAC地址”。目标主机信以为真后发往网关的流量全部送到攻击机但攻击机此时不转发目标主机自然就无法访问外部网络。# 单向欺骗告诉目标主机“网关的MAC是攻击机的MAC” sudo arpspoof -i eth0 -t 192.168.1.100 192.168.1.1命令里的-i指定网卡接口必须是攻击机上实际存在的接口名-t后面的第一个IP是目标主机第二个IP是网关。执行之后终端会持续输出ARP请求发送计数说明工具正在以固定间隔灌注伪造应答包。这个命令行窗口保持在前台运行一旦CtrlC停止发送目标的ARP缓存会在几十秒内自动恢复。此时在目标主机上执行ping 192.168.1.1会发现持续超时。这是因为目标主机把发往网关的数据交给了攻击机攻击机不转发所以数据包石沉大海。目标主机上用arp -a查看网关记录显示的不是网关真实的MAC地址而是攻击机的MAC。这个对比值得在课堂上强调一下为什么域名、IP都没变网络却断了因为链路层的第一跳就选错了方向。单向欺骗演示不需要开ip_forward目标主机的流量进入攻击机网卡后没有被任何服务接收直接丢弃。这个阶段展示的攻击效果有限但它把ARP协议的信任漏洞暴露得很彻底没有任何密码、没有任何认证只是几个伪造的包就能让一台机器的网络“消失”。演示时可以在目标主机上保留一个arp -a的观察窗口让学生亲眼看到MAC地址的变化过程比单纯看攻击机日志直观得多。4.2 双向欺骗与转发中间人链路的完整形态第二步把单向欺骗升级成真正的中间人。目标主机已经相信“网关的MAC是攻击机”接下来还需要让网关相信“目标主机的MAC也是攻击机”。这样目标发给网关的流量会先到攻击机攻击机再转给网关网关回给目标的流量也会先到攻击机再转给目标。两个方向的流量都在攻击机上过一遍中间人的位置就坐实了。# 开启内核IP转发让攻击机具备路由转发能力 sudo sysctl -w net.ipv4.ip_forward1 # 双向欺骗一条进程欺骗目标主机一条进程欺骗网关 sudo arpspoof -i eth0 -t 192.168.1.100 192.168.1.1 sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.100 # 确认两个进程都在运行 ps aux | grep arpspoof第一条命令里的net.ipv4.ip_forward是Linux内核参数值为1时允许内核把收到的数据包按照路由表转发出去。这里必须用sudo普通用户没有权限修改内核参数。第二条和第三条命令在后台启动了双向的ARP欺骗-t后面的参数顺序变成了两条相反的指令第一条欺骗目标第二条欺骗网关。如果没有同时跑两条目标主机依然会断网因为攻击机收到目标发来的数据后不知道要把回包路径也接上。后台运行的两个进程用ps aux检查是否正常驻留。演示中如果其中一条进程异常退出另一条还活着网络表现会非常奇怪——时通时断。这时不要急着重启工具先用ps检查进程列表确定是哪一条挂了再针对性重启。此时的网络状态用一句话总结目标主机以为攻击机是网关网关以为攻击机是目标主机中间的转发由内核完成。课堂上可以让学生从目标主机上ping通外网IP但用traceroute观察路径会发现第一跳不是真实网关而是攻击机的IP。这个阶段是整个实验的关键后续所有的DNS欺骗、内容篡改都建立在双向转发已打通的基础上。4.3 DNS 重定向演示把域名解析引向自己的页面双向中间人链路搭好之后第三阶段展示如何篡改DNS解析结果。目标主机的网络请求经过攻击机转发攻击机的dnsspoof监听UDP 53端口目标发出域名查询时dnsspoof会抢在真实DNS响应之前返回伪造应答。课堂演示时准备一个简单的本地页面然后把一个测试域名指向放页面的服务器IP。# 编辑DNS劫持配置每行格式IP 域名注意IP在前域名在后 echo 192.168.1.66 demo.lab.local dns.conf echo 192.168.1.66 mail.lab.local dns.conf # 启动DNS欺骗服务使用刚写好的配置文件 sudo dnsspoof -i eth0 -f dns.conf配置文件的格式需要特别留意每行先是IP地址空格之后是域名。这是新手最容易踩的坑写反了dnsspoof会读不出正确的映射关系。demo.lab.local这类以.local结尾的测试域名不会和真实站点冲突适合课堂演示。配置里出现的IP就是演示页面的服务器地址可以指向攻击机本机配合Nginx或Apache也可以指向一台独立的测试服务器。dnsspoof启动后在目标主机上执行nslookup demo.lab.local返回的IP会是配置文件里的192.168.1.66而不是真实域名对应的公网IP。在浏览器访问http://demo.lab.local页面显示的是攻击机准备的演示内容。这里有个细节dnsspoof只劫持配置文件中列出的域名其他域名照常走真实DNS解析所以课堂网络的其他业务不会受牵连实验结束后恢复压力也小。演示过程中要注意区分两个层面的效果。ARP欺骗阶段如果断了网DNS欺骗阶段必须先恢复双向转发目标主机能正常上网后才可能收到伪造的DNS应答。顺序上建议严格按“断网→恢复中间人→DNS劫持”三步推进每一步确认效果后再进入下一步。工具包的稳定性和实验结果的可验证性比“一步到位”更重要。5. 避坑排查课堂演示最容易翻车的五个瞬间5.1 现象目标主机直接断网但攻击机这边没抓到任何目标流量第一次演示单向欺骗时目标主机的网络确实断了但攻击机的Wireshark里看不到任何来自目标主机的数据包仿佛ARP欺骗只产生了“断网”副作用没有发挥中间人的作用。原因在于只启动了单向ARP欺骗且没有开启IP转发。目标主机相信了伪造的MAC地址把流量发给了攻击机但攻击机既没有转发能力也没有配置转发策略数据包进了网卡就被内核丢弃。表面上看起来是“攻击很成功”实际上中间人链路压根没建起来后续的DNS欺骗根本无从谈起。解决方法是先打开转发开关再启动双向欺骗。执行sudo sysctl -w net.ipv4.ip_forward1然后同时跑arpspoof -t 目标IP 网关IP和arpspoof -t 网关IP 目标IP两条进程。从那次以后我每次演示都会先跑ps aux | grep arpspoof确认两条进程都在再进入下一步。5.2 现象dnsspoof 启动无报错但目标主机访问域名还是真实 IP这桥段在课堂上翻车率很高。dnsspoof正常启动终端日志也没报错但目标主机nslookup返回的IP仍然是真实的公网地址。检查下来多半是两个原因。第一种是配置文件格式写反了把域名写在前面IP写在后面dnsspoof加载到的映射为空第二种是目标主机的DNS缓存还没失效它直接从缓存里取了上一次的解析结果根本没有发起新的DNS查询。解决方法是先检查配置文件用cat dns.conf确认每行都是“IP 域名”的顺序。接着在目标主机上清DNS缓存Windows上执行ipconfig /flushdnsLinux上执行sudo systemd-resolve --flush-caches。如果还是不行换一个从未访问过的新域名测试比如testxyz.lab.local这样能绕过缓存问题直接看骗没骗到。从那之后我写配置时会强迫自己先写一个IP再写域名避免顺手打反。5.3 现象无线网卡上 arpspoof 跑起来了但目标主机完全不受影响某次实验用了两台笔记本攻击机和目标主机连同一个WiFiarpspoof运行后终端老老实实输出发包计数但目标主机上网毫无变化。问题出在无线网络的AP隔离和网卡混杂模式上。很多无线路由器默认开启客户端隔离同一个WiFi下的设备无法直接互相通信ARP请求和应答都被AP挡在各自的客户端之间还有部分无线网卡的驱动对混杂模式支持有限根本收不到来自其他客户端的ARP流量。解决方法是优先使用有线以太网口连接同一台交换机或者把实验环境搬到虚拟机上把两块虚拟网卡桥接到同一个虚拟交换机。如果非要用WiFi先登录路由器后台关掉AP隔离选项。无线环境下抓不到包不能盲目判断骗术失败先确认是否满足链路层通信的前提。我现在做课堂演示前都会提前确认网络拓扑有线接口永远排在无线前面。5.4 现象ARP 包一直在发但交换机怎么都不买账在部分实验室场景里arpspoof运行正常抓包工具也确认攻击机不断向目标发送伪装ARP应答可是目标主机的ARP缓存始终显示的是网关真实MAC攻击毫无效果。原因是交换机开启了动态ARP检测或端口安全特性。这些交换机安全配置会检查每个端口的ARP报文发现MAC地址对应的IP和记录不符时直接丢弃报文。企业级交换机上这类功能很常见家用交换机基本不会开但高校实验室为了安全往往做了严格限制。解决方法是把实验环境挪到普通交换机上运行或者用GNS3、Mininet这类模拟器环境复现。如果实验室固定使用企业级交换机也可以请网络管理员在指定VLAN临时关闭DAI检测但这个协调成本较高课堂上还是直接换环境更省事。虚拟化方案最可控攻击机、目标机各一台虚拟机桥接到同一个虚拟网络既不依赖物理交换机也不会影响其他真实设备。5.5 现象实验结束后整个网段网络时断时续持续十几分钟演示全部完成后只关掉了工具窗体和浏览器攻击机的终端进程没有清理干净几分钟后整个网段的设备开始随机性断网。观察交换机端口发现攻击机网口的收发包计数异常高。原因是后台的arpspoof进程仍然在继续发送ARP欺骗包IP转发也没有关闭。实验结束后系统虽然退出了命令窗口但后台进程还活着它一直告诉整个网段“网关的MAC在这里”导致其他设备的流量全部绕道攻击机。攻击机一旦关盖或断网全网的通信随之遭殃。解决方法是严格执行恢复流程先停掉所有欺骗进程再关闭IP转发最后清理ARP缓存。课程演示不能只看“攻击成功”就收尾恢复环境的操作也需要学生照着做一遍。某次实验因为恢复不彻底实验室的同学赛后都来找我“要说法”从那以后我把“回收命令”写进实验报告模板每个学生演示完必须当场跑一遍确认网络恢复正常才能离开座位。6. 验证与收尾抓包、解析检查和环境恢复的完整顺序6.1 用 tcpdump 和 curl 验证欺骗确实生效课堂演示不能凭肉眼判断“好像成功了”要让学生看到可验证的证据。tcpdump是最直接的验证工具因为它抓到的包能精确反推攻击路径。# 在攻击机上监听ARP流量观察一秒钟内是否有大量伪造应答 sudo tcpdump -i eth0 -n arp # 监听53端口观察DNS查询与伪造应答的记录 sudo tcpdump -i eth0 -n port 53 # 从目标主机上验证域名解析结果在目标主机执行 nslookup demo.lab.local curl -I http://demo.lab.local第一个抓包命令会看到攻击机发出的ARP应答包源MAC是攻击机网卡地址IP却写着网关地址这正是伪造应答的直观证据。第二个命令能看到UDP 53端口的DNS查询报文和紧随其后的应答报文应答中的A记录IP与配置文件一致。注意一部机器同时跑arpspoof和tcpdump抓包窗口会刷得很快建议监听后加-c 20限制抓包数量避免终端被刷爆。nslookup和curl放在目标主机上执行如果DNS欺骗生效nslookup返回的IP不是真实公网地址而是配置里的IPcurl得到的页面内容是攻击机上准备的演示页面不是真实站点的首页。这里的验证顺序很关键先确认ARP层生效再确认DNS层生效最后确认HTTP层内容被替换每一层都要有对应的证据整个实验链路才算闭环。6.2 演示结束后的环境恢复清单收尾工作看起来不起眼却直接关系到实验环境的干净程度。我建议把恢复命令保存成一个脚本课堂演示结束直接执行。# 停止所有欺骗进程 sudo pkill arpspoof sudo pkill dnsspoof # 关闭IP转发恢复内核默认策略 sudo sysctl -w net.ipv4.ip_forward0 # 清空攻击机的ARP缓存强制重新学习 sudo arp -d $(ip route | grep default | awk {print $3}) # 目标主机上清DNS缓存Windows示例 # ipconfig /flushdnspkill按进程名精确匹配结束进程如果攻击机上同时跑了多个实例建议先用ps aux | grep arpspoof确认进程PID后再kill。sysctl这条命令把IP转发恢复为0防止内核继续对跨接口流量做路由。arp -d后面跟的是网关IP清空后攻击机会在下一次通信时重新发起ARP请求学习真实网关MAC这一步不能省略否则攻击机的ARP缓存里残留伪造条目。目标主机的DNS缓存清理根据操作系统选择对应命令Windows用ipconfig /flushdnsLinux用systemd-resolve --flush-caches。某次上课结束我漏掉了关闭IP转发这一步攻击机持续转发流量导致实验室其他同学的网络延迟从十几毫秒飘到几百毫秒。从那以后我强制自己把恢复命令做成一个脚本每次演示结束立即在终端里执行一遍确认所有进程退出、转发关闭、ARP缓存清空才允许学生关机离开。这套验证与恢复的顺序也写进了实验报告的评分标准里。希望帮到你在课堂上少踩几个我没躲过的坑。本文还有配套的精品资源点击获取