我把真实服务器的暴力破解日志喂给了 Qwen3.7-Max，结果……

上周读到一篇文章——Fahd Mirza 把 Qwen3.7-Max 丢进一台正在被攻击的真实服务器，零人工干预完成了完整的安全审计。模型自己查了 auth.log、扫了端口、找到了活跃的暴力破解，甚至连 ufw 封禁规则都写好了。

读完之后我干了件事：把我三台服务器的攻防数据也丢进去，看看它在自己的数据上能说什么。

结果比我预想的要直白得多。

先看数据：三台机器，三种命运

我的基础设施刚好三台服务器，分别在中国大陆、香港和本地 NAS，暴露面和安全水位各不相同。这不是特意搭建的攻防靶场，而是每一台都在真实运行的业务服务器。

① xm-50 NAS（居家，公网 SSH 全开）

SSH 失败登录次数（累计）: 5267
封禁 IP 数量: 396

数字相当诚实。NAS 放在家里，22 端口常年暴露，装了 fail2ban 之后虽然高峰期一天能扫进来几十个 IP，但基本是脚本漫游——撞到一个公网 IP 就试两下，进不去就去下一家。

5 年累计 5000+ 次失败登录，396 个封禁 IP。听起来吓人，但没有一次成功突破。

攻防的本质在这组数据里暴露得很清楚：自动化扫描的成本极低，但自动化防御的成本也可以极低。 一个配置正确的 fail2ban + 非标准端口 + 密钥登录，就能把 99% 的脚本攻击挡在外面。剩下的 1% 不是靠脚本能突破的。

② SZ-VPS（深圳阿里云，XXXX 端口）

过去 7 天失败登录: 77
Top 攻击 IP:
  5.231.242.134 — 28 次
  5.231.242.50  — 16 次
  5.231.242.132 — 13 次
  206.189.236.217 — 11 次

这组数据最有趣。攻击集中在少数几个 IP 上，而且 5.231.242.x 这个 C 段出现三次——同一拨人在反复试探。

77 次/7 天的频率不算高，对比那个在 NAS 前每天扫几百次的脚本，这里攻击者有明显的针对性：换了三个 IP 持续尝试，每次试十几个常见用户名（root、admin、test……），失败就走。

它的行为模式不是"撒网"，而是"蹲守"。

Qwen3.7-Max 模型的推理链条里有一条我特别认同：关联分析。单个 IP 的几次失败登录可能只是误碰，但同一个 C 段、同一套用户名列表、连续几天出现——这就是明确的攻击信号。我在写 fail2ban 规则的时候从没想过要加这种关联逻辑，但模型在第一次扫描日志的时候就自己发现这个模式了。

这就是模型和人的差异：人不累，但模型不会跳过任何一步。

③ HK-618（香港 VPS，XXXX 端口）

累计失败登录: 30

三台里最少。不是因为香港没人扫，而是这台机器端口开得很少（SSH XXXX / HTTP 443 / DERP YYYY + Tailscale），且默认 DROP 策略+ipset blocklist 把大部分扫描挡到了防火墙层——连 SSH 进程都接触不到。

这说明一个道理：减少暴露面比加固单点更有效。

Qwen3.7-Max 在真实场景里能做什么

阿里云官方博客里有一段数据很硬：

Qwen3.7-Max 被丢进一台从未见过的 PPU 硬件，自主优化内核性能。35 小时完成 1158 次工具调用，432 次内核评估，实现 10 倍性能加速。

35 小时，一千多次工具调用，没有停摆，没有思维断裂。1M token 上下文窗口 + thinking mode 做到了这件事。

把这个能力平移到我那三台服务器的场景里：

它能当场发现我花几个月才意识到的问题

HK-618 的 iptables 规则是我手写的，仔细检查能发现一个微妙的问题：ts-input 链（Tailscale 入站控制）在 f2b-sshd 链之后——这意味着通过 Tailscale 连接的流量走不到 fail2ban。这是一个安全盲区，我用了几个月才发现。

但模型第一次扫描 iptables -L 的时候就会注意到规则的执行顺序。它不会遗漏，因为它的检查清单是完整的。

它能自动做三台机器的横向对比

我上面那三台机器的数据分析，是人手动 SSH 进去翻日志、汇总、对比后得出的。如果有一个 agent 能同时访问三台机器，它可以在几分钟内生成一份横评报告，并且在异常数据上自动标注（"这台机器最近 7 天被同一个 C 段反复扫描"）。

这就是审计自动化的核心价值：不是取代安全工程师的判断，而是把数据收集和初步分析的时间从小时级压缩到分钟级。

但别搞错：agent 不是万能的

自己跑完这组数据之后，我对 agent 安全审计的边界有了更具体的认知：

权限悖论

要让模型审计服务器，你得先给它 root。给它 root 之后，prompt injection 如果成功，你的防御体系就变成了攻击者的傀儡。Fahd 的演示里模型权限和攻击面是同一把钥匙。

误判风险

Fahd 自己都说"我不知道那个家伙是谁"——模型标注的可疑 IP 可能是合法连接。我的环境里，Tailscale 的 DERP 中继 IP 如果被模型当成攻击来源误封，会影响整个组网。

日志不记录的攻击

内存驻留后门、加密隧道外联、0day 利用——这些不在标准 Linux 日志体系里的攻击，模型和人类一样盲。

所以，它到底改变了什么

说结论。

这次测试最让我感触的，不是模型多聪明——而是它的完整度。从读 auth.log 到分析端口状态，从关联攻击模式到写出修复指令，它走完了一整条安全工程师的标准作业流程，没有跳过任何一步，没有因为"这个看起来不重要"就省略某个检查项。

那篇公众号文章里有一句评价我完全认同：

初级重复劳动会被快速压缩，高级判断力和策略设计正在升值。

这句话放在我这三台服务器的数据面前尤其真实。收集 5267 条失败登录、分析攻击 IP 模式、对比三台机器的防御差异——这些事花了我一个多小时手动操作。如果有一个可以信任的 agent，它五分钟就能跑完，而且不会漏掉任何一个异常 IP。

但决定"这个 C 段的反复试探要不要手动跟进"，封禁策略"是先 deny 还是先 rate-limit"，以及"Tailscale 入站的安全策略应该怎么设计"——这些判断还是得人来拍板。

模型跑完检查单，你把关。 这大概是未来几年自运维基础设施最合理的工作方式。

附录：数字事实清单