企业官网建设流程全解析

说实话，现在很多做内网渗透测试的朋友上来就喜欢怼 Web 漏洞、打域控，反而把 ARP 欺骗这种"上古"攻击手段当成过时货。但我在一次授权测试里恰恰就靠 arpspoof 配合 sslStrip 这套老组合，撕开了客户口中"隔离做得很好"的办公网段。当时客户网络组很自信，说内网端口隔离已经覆盖到接入层，结果我拿到一个普通权限后，用一台测试机做 ARP 中间人，很轻松就把同网段一台主机的明文流量看光了。

这篇文章就围绕 arpspoof + sslStrip 这套经典组合，从 ARP 协议本身的缺陷讲起，再到完整实验步骤、常见坑、以及防御方案，完整跑一遍。适合刚入门网络安全、想理解中间人攻击原理的同学，也适合做授权内网测试的工程师，以及想搞明白"为什么内网 VLAN 隔离还会被 ARP 欺骗打穿"的网络管理员。声明一下：所有内容都请在你的自建实验环境或者明确获得授权的测试范围内进行，别拿公网或别人的网络练手。

1. ARP欺骗为什么到今天还能打穿交换网络的内网

很多人觉得交换网络天然比 Hub 时代安全，因为交换机是按 MAC 地址精准转发，不像 Hub 那样无脑广播。这个说法没有错，但它忽略了一个关键前提：交换机只负责转发二层帧，而帧头里的目标 MAC 地址是怎么来的？靠的还是 ARP 协议。ARP 这个协议本身太古老、太天真了，交换机再聪明也拦不住上层的协议缺陷。

1.1 ARP协议"无状态信任"的先天缺陷

ARP（Address Resolution Protocol）的作用，简单说就是解决"我知道对方 IP，但不知道对方 MAC，二层帧没法封装"的问题。主机要发数据包时，先查本地 ARP 缓存，没有对应表项就发一个 ARP 广播："谁是 192.168.1.1？请把你的 MAC 告诉我。" 正常情况下，拥有这个 IP 的设备会回一个 ARP Reply，告诉请求方自己的 MAC。

问题出在 ARP 协议设计时压根没有考虑安全验证。它没有状态，不校验请求是否由自己发出，也不校验应答方是不是 IP 的真正拥有者。任何一台主机收到 ARP Reply，只要发现"这个 IP 之前没见过"或者"IP 相同但 MAC 变了"，就会直接更新本地 ARP 缓存，覆盖原有表项。这个过程有个专门的名字叫 ARP 缓存投毒。

你可以把 ARP 缓理想象成小区门口门卫手里的住户登记本。本来这个登记本是用来记录哪户对应哪个人，方便访客寻路的，但门卫有个毛病：任何人过来说"我是 3 栋 502，登记一下"，他都信，还立刻把 502 原来的记录划掉改成新名字。攻击者就是那个乱报门牌号的人，他可以把自己的名字写到别人的门牌下，所有访客从此都被领到他家门口。

1.2 交换网络为什么拦不住ARP欺骗

交换机的工作模式确实比 Hub 先进，它会学习每个端口下连接设备的 MAC 地址，构建一张 MAC 地址表，之后数据帧就定向转发。但关键在于，交换机的 MAC 地址表完全依靠"收到帧的源 MAC 来自哪个端口"来动态学习，它不会去验证这个 MAC 地址是否被冒用。

攻击者发一个源 MAC 为"网关 MAC 地址"的帧，交换机看到的是"网关的 MAC 出现在这个端口下"，它怎么知道这个 MAC 已经被攻击者伪造了？它不知道。更麻烦的是，ARP 广播本来就会在整个广播域内传播，VLAN 隔离和接入层端口隔离可以防止跨 VLAN、跨端口的不必要访问，但在同一个 VLAN 内部的 ARP 欺骗，VLAN 划分是挡不住的。

举个真实的场景。在公司的办公网里，每个人的电脑和打印机、门禁系统都在同一个广播域里，只要有一台机器被攻破，攻击者就可以伪造网关 MAC，让所有同网段设备的出网流量都从自己这里过一遍。客户之前把 VLAN 划得很细，但他们忽略了：攻击者所在的 VLAN 内部依然有大量用户，VLAN 只是隔离了不同部门，没能隔离"内部的人的流量被同 VLAN 内的人偷听"。

1.3 中间人链路为什么必须双向欺骗

很多人第一次做 ARP 欺骗，会以为只要欺骗受害者"网关的 MAC 是攻击者"就够了。实测下来你会发现，如果只发这一条，流量链路是残缺的。受害者发往网关的出向流量确实会先到攻击者这里，但网关回给受害者的数据，是直接以受害者真实 MAC 地址为目标发送的，走的是交换机的 MAC 地址表，根本不经过攻击者。

这样的话，攻击者只能看到受害者发出的请求，看不到服务器返回的响应。对于抓 HTTP 明文密码来说，请求里往往就带关键词了，但要做到双向劫持、改响应内容、实现 sslStrip 那样的精细操作，必须让两端的流量都从中间过。所以经典做法是同时发两条 ARP 欺骗：

• 欺骗受害者："网关的 MAC 是攻击者的 MAC"。
• 欺骗网关："受害者的 MAC 是攻击者的 MAC"。

这样受害者和网关之间的双向流量就都先到攻击者手里，再被转发出去。攻击者处在一个"透明人"的位置上，既能看到数据，又能改写数据。下面章节我会把这两条命令怎么跑、怎么验证、怎么收尾都讲清楚。

2. 攻击环境准备与工具选型取舍

做这种实验最重要的一点是环境可控。我不会建议你用自己公司的办公网或者宿舍网直接测，也别拿别人的设备当靶机。最稳妥的是自己搭一套最小化环境：一台 Kali 虚拟机当攻击机，一台普通的 Windows 虚拟机或者手机浏览器当靶机，再有一个家用路由器或者虚拟机里的虚拟网卡模拟网关。整套环境都可以在 VMware/VirtualBox 里完成，不需要真实硬件。

2.1 实验拓扑与版本选型

我自己的实验环境是这样的，你可以照着搭：

在这个环境里，攻击机和靶机必须在同一个广播域，也就是同一个 VLAN、同一个二层网络内。如果中间隔了三层路由，ARP 欺骗大概率是搞不动的，因为 ARP 广播不会跨三层传播。这是我无数次实测得出的结论，也是这类攻击的天然边界。

2.2 arpspoof/ettercap/bettercap：为什么我选了复古组合

现在做 ARP 欺骗的工具不少，常见的有三个：arpspoof、ettercap、bettercap。它们都行，但侧重点不一样。

我在这篇里用 arpspoof + sslStrip 这个复古组合，理由很简单：arpspoof 输出的每一条日志、发送的每一个 ARP 报文都清清楚楚，适合把原理讲透。ssltStrip 本身也只做一件事——把 HTTPS 降级成 HTTP，链路足够短，方便排查问题。bettercap 固然强大，但它把很多细节封装起来了，新手用完之后只知道"好像成功了"，却说不出到底怎么成的，这不是学习的态度。

2.3 环境准备清单

硬件拓扑定好之后，攻击机上要做几项准备，缺一样实验都可能翻车。

1. 安装 dsniff 工具包。arpspoof 就在 dsniff 里，Kali 默认装了，但一些精简版可能没有，用sudo apt install dsniff补上。
2. 获取 sslStrip。它是个老项目，GitHub 上还能找到源码，注意它依赖 Python 2 环境。新版 Kali 默认只有 Python 3，需要自己处理依赖。我通常是下载源码后手动指定 python2 解释器运行，具体踩坑后面专门讲。
3. 开启内核 IP 转发。Linux 默认不会转发数据包，如果不开，受害者发给网关的流量到攻击机这里就会被丢弃，表现为"网络直接断掉"。开启命令是：

   sysctl -w net.ipv4.ip_forward=1

   这条命令即时生效，重启后失效，实验做完记得关掉。
4. 确认攻击机防火墙没把转发流量挡住。有些 Kali 发行版默认有 firewalld 或 ufw，开着的话转发流量可能被 DROP。我习惯直接临时停掉：

   sudo ufw disable

   当然这只在实验环境做，生产环境千万别这么干。

还有个大前提：攻击机、靶机、网关的 IP 必须互通，且 ARP 缓存是干净的。如果之前实验留下了脏缓存，可以分别清一下。Windows 上用arp -d，Linux 上用ip neigh flush all。

3. 打通双向ARP欺骗链路：两条命令与其后的通信重构

环境准备好之后，第一步是把中间人链路打出来。这是整篇文章的地基，链路不通，后面 sslStrip 再怎么折腾都没有意义。

3.1 两条核心命令的语义

打开两个终端，分别跑两条命令。第一条：

sudo arpspoof -i eth0 -t 192.168.1.105 192.168.1.1

这条命令的参数含义是：-i eth0指定使用 eth0 接口，-t 192.168.1.105是目标主机（被欺骗的对象），最后的192.168.1.1是你要伪装的主机（即网关）。整条命令的意思是："告诉 192.168.1.105 这台机器，网关 192.168.1.1 的 MAC 是攻击机的 MAC。" 在输出里你会看到类似0:c:29:aa:bb:cc 192.168.1.1 192.168.1.105这样的行，表示正在持续发送伪造的 ARP 应答。

第二条命令：

sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.105

这条是相反的：告诉网关"192.168.1.105 这台机器的 MAC 是攻击机的 MAC"。两条命令一定要同时跑，而且不能中断，因为 ARP 缓存会刷新，靶机和网关会重新发 ARP 请求，需要持续应答才能维持欺骗状态。我之前见过有人只开一条命令，结果抓到的流量只有一半，怎么分析都不对，就是这个原因。

这两条命令背后的通信重构是这样的：受害者原本要把数据包发给真实的网关 MAC，现在 ARP 缓存被改了，数据包会发给攻击机；攻击机收到之后，因为已开启 IP 转发，会把目标 IP 重新封装成帧，再根据 ARP 缓存查到真实网关的 MAC，把包转发出去。网关返回给受害者的数据也是同理，先经过攻击机，再被改 MAC 后转给受害者。整个过程中，受害者上网不会断，只是延迟有一点增加，用户几乎感知不到。

3.2 验证中间人是否真的打通

链路打没打通，不要靠猜，有三个方法可以验证。

第一个方法是在靶机上查 ARP 表。Windows 上跑arp -a，如果你的欺骗生效了，网关对应的 MAC 会变成攻击机的 MAC，而不是真实网关的 MAC。看到这个变化，说明第一层的欺骗已经生效。第二个方法是直接在攻击机上用 tcpdump 抓包：

sudo tcpdump -i eth0 host 192.168.1.105 and host 192.168.1.1

如果你能看到靶机与网关之间的 TCP 数据包在攻击机网卡上经过，说明双向流量确实被导流了。第三个方法是让靶机访问一个 HTTPS 站点，然后在攻击机上抓包：如果抓到了访问目的地的 IP 和 TLS 握手包，说明你能看到加密流量；等到后面 sslStrip 生效时，还能进一步看到明文的 HTTP 请求。

还有一种情况是中间人断了，表现就是"靶机突然上不了网"。这个几乎都是 IP 转发没开导致的，去检查sysctl net.ipv4.ip_forward是不是 1。另外，靶机如果开了防火墙，也可能忽略伪造 ARP 应答，但这个比较少见，因为 ARP 是协议层面的行为，Windows 防火墙一般不管。

在链路稳定之后，我强烈建议你花一点时间用 Wireshark 抓一下 ARP 报文，看看攻击机持续发送的 ARP Reply 是什么样子的。你会看到攻击者不断告诉受害者"网关的 MAC 在这里"，这种直观观察比任何教程都更能建立对 ARP 欺骗的直觉。

3.3 实验收尾的干净清理

很多新手做完实验直接关虚拟机走人，但 ARP 缓存里的脏表项如果一直留着，靶机后续访问网络可能会出问题。正确的收尾流程是：

1. Ctrl+C 停掉两个 arpspoof 进程。
2. 等几秒，让靶机和网关按照正常 ARP 请求重新学习真实 MAC 地址。
3. 如果等不及，也可以在靶机上手动执行arp -d刷新缓存。
4. 关闭 IP 转发：sysctl -w net.ipv4.ip_forward=0。
5. 清掉 iptables 里临时加的各种规则（下面章节会讲到），避免下次实验被干扰。

这个步骤虽然不起眼，但在真实授权测试里，恢复现场是基本职业素养。你不想测试结束了客户网络还残留着你留下的中间人链路，那会变成一个新的安全事件。

4. sslStrip核心原理：不是破解HTTPS，而是让受害者忘掉HTTPS

ARP 欺骗打通之后，攻击者能看到的流量还是加密的 HTTPS 流量。直接嗅探只能看到 TLS 握手包和一堆密文，密码依然是安全的。这时候 sslStrip 登场，它做的事情非常巧妙，但又非常"损"。

4.1 sslStrip到底做了什么：HTTP和HTTPS之间的"翻译小偷"

先澄清一个常见误解：sslStrip 不是去破解 TLS 加密，也不是伪造证书去冒充站点。它做的是一件更鸡贼的事——把受害者的 HTTPS 请求悄悄降级成 HTTP 请求。

它的工作场景是：受害者在访问一个普通 HTTP 网页，页面上有个"登录"按钮，指向https://example.com/login。如果攻击者不干预，浏览器会向 example.com 的 443 端口发起 TLS 握手，正常加密登录。但 sslStrip 截获了这个流程：它监听在攻击机的某个端口上，将受害者发来的 HTTP 请求里所有https://链接替换成http://，受害者点击之后，实际请求就变成了http://example.com/login，走的是明文 HTTP。

此时更妙的是，sslStrip 作为中间人，会自己与真实服务器建立 HTTPS 连接，把服务器返回的内容解密后，再以明文 HTTP 形式转给受害者。受害者浏览器地址栏显示的是http://...，内容却和真实 HTTPS 页面一模一样。整个过程中，受害者不会看到证书错误，因为浏览器认为自己访问的是 HTTP 站点，压根不需要验证证书。这就是 sslStrip 和"伪造证书型中间人"的本质区别：后者要骗过浏览器的证书校验，前者直接绕过"需要证书"这个前提。

4.2 从iptables到sslstrip：完整启动流程

要让 sslStrip 接手流量，还得先把 HTTP 明文流量导给它。sslStrip 默认监听在 10000 端口（我用-l参数改成 8080 了），但受害者的 HTTP 请求是发往 80 端口的，所以要在攻击机上用 iptables 做一次端口重定向：

sudo iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

这条规则的含义是：所有进入攻击机、目标端口为 80 的 TCP 数据包，都重定向到 8080 端口，也就是 sslStrip 监听的位置。注意，这里用PREROUTING链而不是OUTPUT链，因为我们要劫持的是转发流量（受害者发给网关的流量），不是攻击机自己发出的流量。这也是为什么很多人在攻击机上自测没效果——攻击机本机发出的 HTTP 请求走的是 OUTPUT 链，根本不会被重定向。

然后启动 sslStrip：

cd sslstrip-0.9.2 && python2 sslstrip.py -a -w /tmp/sslstrip.log -l 8080

参数解释：-a表示记录所有 SSL POST 数据，也就是受害者通过表单提交的账号密码等敏感内容；-w指定日志文件，后面查看抓到的内容会用到；-l指定监听端口，必须和 iptables 里的 8080 一致。

此时完整的攻击链是：

1. 受害者浏览器访问一个 HTTP 页面，这个页面上有跳转到 HTTPS 的链接。
2. 浏览器发出 HTTP 请求，流量经 ARP 欺骗到达攻击机。
3. iptables 把 80 端口的流量转向本机 8080。
4. sslStrip 接管请求，把页面内容里的 HTTPS 链接改写成 HTTP。
5. 受害者点击"登录"，浏览器发出http://...的明文 POST 请求，再次经过攻击机。
6. 攻击机的 sslStrip 把明文 POST 记录下来，同时与真实服务器保持 HTTPS 连接，把响应转回给受害者。

受害者全程感觉不到异常，但账号口令已经躺在/tmp/sslstrip.log里了。

4.3 为什么直接输入HTTPS地址就失效了

这里有一个非常重要的边界条件：如果用户直接在浏览器地址栏输入https://example.com回车，sslStrip 是拦不住的。因为浏览器拿到这个地址后，会很自然地优先访问 443 端口做 TLS 握手，根本不会产生 80 端口的明文流量，sslStrip 监听在 8080 也无事可做。

所以 sslStrip 的实际猎物，是那些"入口还是 HTTP、内部包含 HTTPS 跳转"的站点。这类站点在今天依然大量存在，尤其是一些老旧系统、企业内部门户、某些路由器的管理后台。它们为了兼容性或者历史原因，首页是 HTTP，只有登录接口走了 HTTPS，给了降级攻击可乘之机。

我还记得第一次在实验室复现时，特意找了个支持 HTTP 入口的测试站点，用靶机从首页一层层点到登录页，然后打开日志，看到一行一行清清楚楚的POST /login HTTP/1.1，后面跟着username=admin&password=123456。那一刻你会真切理解什么叫"加密的终点不是加密，入口不封死等于白加密"。

5. 踩坑实测：sslStrip在现代浏览器上的存活现状

光看原理会觉得 sslStrip 很完美，但真在现在的浏览器环境里实测，你会发现一堆坑。这些坑不是工具本身的问题，而是网络环境和技术演进带来的变化。我把最常踩的五个坑列出来，每一个都是真金白银换来的教训。

5.1 HSTS：让降级攻击直接哑火

第一个坑来自 HSTS（HTTP Strict Transport Security）。服务端可以通过响应头Strict-Transport-Security: max-age=31536000告诉浏览器："在接下来一年里，你只能通过 HTTPS 访问我，不许用 HTTP。" 浏览器一旦收到这个头，就会把该域名的所有 HTTP 请求自动升级成 HTTPS。

更狠的是，Chrome、Firefox 等浏览器还有一份 HSTS 预加载列表，里面收录了大量知名域名。哪怕用户第一次访问之前没收到过 HSTS 头，只要域名在预加载列表里，浏览器也会强制执行 HTTPS。sslStrip 帮用户把 HTTPS 链接改写成 HTTP，浏览器自己又会偷偷把它升级回 HTTPS，导致降级链路直接断裂。

实测下来，现在大部分主流互联网站点都启用了 HSTS，sslStrip 在纯互联网环境下作用大大缩水。我第一次测的时候，用靶机打开某个知名站点，从 HTTP 入口点进去，浏览器地址栏瞬间跳成 HTTPS，sslStrip 日志一条记录都没有。这是现代浏览器给 sslStrip 敲的丧钟。

5.2 环境兼容：python2与sslstrip的安装坑

第二个坑来自工具本身的老旧。sslStrip 最后一个版本是 0.9.2，距今已经很久了，代码是 Python 2 写的。新版 Kali 默认已经没有 Python 2 解释器，直接执行sslstrip.py会报SyntaxError或者ModuleNotFoundError。

解决办法是你得确保系统里装了 Python 2.7，并安装依赖包。我在 Kali 上是用 apt 安装python2和相关依赖，然后显式用python2 sslstrip.py来跑。这里要注意，Python 2 环境下有些依赖包版本很老，不要贪新把它升级到 Python 3 兼容版，反而会报更多错。

如果实在不想折腾 Python 2 环境，可以退而求其次用 bettercap 的http.proxy模块，它实现了类似的功能，而且是现代维护的项目。但如果你是为了理解 sslStrip 的原理，还是建议在隔离环境里装个老版本 Python 跑通一次，这种"亲手复活老工具"的体验不可替代。

5.3 验证误区：在攻击机上自测导致误判

第三个坑特别隐蔽：我一开始验证效果，习惯性地在攻击机自己浏览器里访问测试站点，结果怎么测怎么没反应。后来查了 iptables 规则才反应过来，我之前加的PREROUTING链只作用于转发流量，攻击机本机发出的流量走的是OUTPUT链，根本不会被重定向到 8080。

所以如果你要验证 sslStrip 是否生效，一定用靶机去访问，或者在攻击机上额外加一条OUTPUT链的重定向规则。不过像这种自测验证，我建议直接换靶机，保持攻击机环境的干净，排查起来也方便。

5.4 真正的重灾区：入口混杂、没有HSTS的内网Web系统

虽然 HSTS 在互联网站点普及率很高，但在内网环境里完全是另一回事。很多企业内网的自建系统、老旧应用、打印服务器、摄像头管理后台，根本没有配置 HSTS 的能力，甚至登录接口还跑在明文 HTTP 上。这类系统恰恰是内网渗透测试中最重要的凭证来源。

我在授权测试中遇到的问题就是这样的：客户办公网段里有一个老的 OA 系统，首页能通过 HTTP 访问，用户点"登录"后才会跳到 HTTPS 的登录接口。对一般用户来说，这个跳转很自然，不会注意地址栏的变化。但对攻击者来说，这就是一个完美的 sslStrip 猎物。只要让目标用户访问一次被改写的页面，账号口令就送到你手里了。

所以说，sslStrip 这套思路在远离互联网的封闭环境里依然有效。现代防御者往往只关注对外服务的安全，忽略了内网系统还停留在"上个时代"的访问习惯。

5.5 现代浏览器的"不安全"提示，反而成了附带防御

第五个坑跟浏览器 UI 有关。现代 Chrome 和 Firefox 对纯 HTTP 页面会直接标注"不安全"，这个提示在 sslStrip 的攻击场景里其实起到了一定的防御作用。当受害者看到 sslStrip 改写后的http://地址，地址栏会有一个显眼的不安全标识，警觉一点的用户可能就会停止输入密码。

但这个提示只对"有安全意识的人"有效。大量普通用户在登录一个页面时，根本不看地址栏，也不理解什么是 HTTPS 和 HTTP。我在实验室里做过小范围测试，让几个同事访问一个模拟的登录页面，超过一半的人完全没注意到地址栏显示的是http://。所以这个提示是防御手段，但绝对不能只依赖它。

6. 防御视角：网管和安全管理员怎么从根上消掉这类攻击

讲了这么多攻击原理，要是不讲讲怎么防，这篇文章就不完整。ARP 欺骗和 sslStrip 虽然是老技术，但至今仍能在内网掀起风浪，是因为很多网络管理员压根没想过在二层做防护。下面这些手段，按有效性从高到低排。

6.1 交换机源头防御：DHCP Snooping与DAI

要从源头上解决 ARP 欺骗，最有效的手段是交换机的动态 ARP 检测（DAI），但它必须配合 DHCP Snooping 一起用。原理是这样的：交换机启用 DHCP Snooping 后，会监听 DHCP 交互过程，建立一个 IP 到 MAC、端口、VLAN 的绑定表。然后 DAI 会检查每一个 ARP 报文：如果报文的 IP-MAC 关系和绑定表不一致，交换机直接丢弃这个报文。

这意味着攻击者即使发出伪造的 ARP 应答，交换机根本不转发，受害者根本收不到。这是目前对抗 ARP 欺骗最釜底抽薪的办法，比什么终端软件都靠谱。配置的时候注意，要在接入交换机上对所有终端接口启用，同时把上联口（接路由器或核心交换机）设置为信任端口，否则会误伤正常的网关 ARP。

6.2 网关与服务器侧：静态ARP与强制加密入口

如果交换机层面一时半会儿改不了，也可以在关键设备上配置静态 ARP。静态 ARP 表项不会因为收到的 ARP 应答而改变，攻击者再发伪造应答也没用。Windows 上可以用netsh interface ipv4 set neighbors配置，Linux 是arp -s IP MAC。缺点是维护麻烦，IP 变了要手动改，所以一般只用于核心服务器和网关。

另一条腿是强制加密入口。所有需要登录的系统，都应强制 HTTPS 并启用 HSTS。注意，HSTS 要尽早配置并保证整个站点的所有子资源都走 HTTPS，否则降级点依然存在。对于开发者来说，登录页面绝对不能用http://作为入口，就算首页是 HTTP，也要在页面初始化时立刻跳转 HTTPS，不给中间人改写链接的机会。

6.3 开发与运维的整改清单

我把防御要点整理成一份清单，供网管和开发排期参考：

这套清单不追求面面俱到，但能覆盖 ARP 欺骗和 sslStrip 主攻的几个环节。你可以根据自己的网络情况挑重点做，优先级上网络层的 DAI 无疑是最值的。

6.4 终端检测与用户意识

最后再说终端侧。现在很多 EDR 产品会检测本机 ARP 缓存异常变化，一旦发现网关 MAC 频繁变动就告警，这个对 ARP 欺骗非常有效。开源方案里有 ARPwatch 可以监控 ARP 表变化，XArp 是 Windows 上的老牌工具，都可以用来做辅助检测。

用户意识这块，与其天天培训大家看地址栏，不如直接引导大家用密码管理器。密码管理器的核心特性是自动填充时会校验域名，如果在http://的页面里，它一般会拒绝自动填充或者发出强警告，这比人眼识别可靠得多。我在实验室里让同事测试 sslStrip 钓鱼页面，安装了密码管理器的同事基本都能躲过去，反而是一帮自以为懂技术的同事，手一抖就把密码输进去了。

写在最后的个人体会

折腾 arpspoof 和 sslStrip 这套老组合，给我最大的感受是：安全攻防永远是在跟"人性"和"历史包袱"作战。ARP 协议设计于信任年代，当时没人想到网络里会有恶意主机；HTTPS 的部署本来是为了加密，但只要入口不封死，加密就成了马奇诺防线。sslStrip 本身已经濒临淘汰，但它教的这个"降级"思路一点都不过时——今天各种钓鱼攻击、中间人代理、流量劫持，本质上都是在想方设法让用户走一条看似正常但实际被控制的路径。

如果你刚接触这类实验，我的建议是不要急着上工具链，先把每一步都拆开看明白：ARP 缓存怎么被污染、IP 转发为什么必须开、iptables 重定向是怎么回事、sslStrip 改写链接的逻辑是什么。等你把这个链条里的每一个环节都亲手验证过，再去看 bettercap 这种集成工具，会发现自己能理解它在做什么、为什么这么做、出了问题怎么排查。这种底层能力的积累，才是安全从业者真正值钱的地方。