企业官网建设流程全解析

凌晨两点半，SOC值班群被消息刷屏。十几个客户的防火墙几乎同时出现异常登录尝试，攻击源覆盖全球十几个国家，目标路径高度一致，全指向FortiGate的远程接入入口。老实说，FortiGate被批量扫描不是新闻，真正让我后背发凉的是攻击的节奏：同一时间窗口里，攻击脚本在针对不同固件版本、不同开放端口做多路试探和payload变体适配，这种编排能力，靠一个或几个自然人根本跑不出来。背后的引擎，基本可以确定是DeepSeek、Claude这类模型的辅助——它们把“漏洞情报收集、利用代码生成、批量调度脚本”串成了一条流水线。紧接着社区又爆出OpenClaw被大规模利用、3万实例沦陷的消息，两者放在一起看，整个行业都该重新评估一下：AI化攻击已不是PPT概念，而是正在发生的现实。

这篇文章我想把两件事完整复盘一遍：一是FortiGate那波批量攻击到底打的是什么、为什么能打成流水线，二是OpenClaw这类自建AI工具为什么会以三万台量级沦陷。更重要的是，作为一个常年做安全运维的人，我会把防守侧真正能落地的加固动作整理出来，给同样在做边界防护和自建AI服务的朋友一份直接可抄的作业。

1. 攻击流水线的本质：AI把“漏洞到利用”的门槛整个掀翻了

1.1 传统攻击与流水线攻击的差异

先用一张表把差别说清楚：

所谓流水线，就是把攻击切成了几个工序：情报、选靶、利用、横向、善后。过去每一道工序都依赖人的经验和时间，现在模型在每道工序都能充当“熟练工”。威胁情报的聚合、代码片段的生成、脚本参数的调整，这些以前是高级工程师几小时的活，现在几秒到几分钟就能完成。

1.2 DeepSeek、Claude在流水线里的真实角色

这里必须先澄清一个误区：模型本身不会发动攻击，模型是“生产工具”。攻击者真正在做的事，是用harness这类工作流封装去调模型API，把任务拆成小步骤交给模型处理，再拿结果喂给自动化脚本。

DeepSeek这类开源模型可以私有化部署，攻击者能把整个推理链路藏在自家基础设施里，不依赖外部API，日志完全不可见。而Claude这类商用模型在代码生成、长上下文规划上表现更稳，适合处理跨文件、跨步骤的复杂编排。两条路线一组合，效率和隐蔽性都拉满了。

最近社区里大量讨论“deepseek harness”“codex接入deepseek”“vscode配置claude code”，本质上都是把模型嵌入到工作流里。合法开发者这么干是为了提效，攻击者用同一套技术栈去调调制式负载，差别只在目标。安全人员必须意识到，这些工具现在被攻防双方同时使用。

1.3 为什么偏偏是FortiGate和OpenClaw

两个目标看似毫无关联，其实共用同一个被选中的逻辑：资产价值高、部署量大、历史暴露面清楚。

FortiGate是企业边界最普及的防火墙之一，几乎所有组织的远程接入都走它。攻击者只要打穿一台，等于进了内网主动脉。它的Web管理界面和远程接入入口常年暴露在公网，历史上反复出现高危害漏洞，攻击者早就把它的指纹、常见版本、漏洞组合研究透了。

OpenClaw及同类AI代理项目，则是近一年自建AI热潮的产物。大家都在搜DeepSeek本地部署、Ollama、vLLM、OpenClaw怎么装，但很少有人搜“OpenClaw安全配置”。这类服务往往默认监听0.0.0.0、API不带鉴权、部署者只管功能不管暴露。攻击者用扫描器全网搜一遍，三两下就能把没有保护措施的实例挑出来。3万实例沦陷，一点不夸张——互联网上这种“裸奔”的AI代理，可能比我们以为的多得多。

2. FortiGate批量攻击复盘：攻击者把老漏洞吃透了

2.1 攻击链长什么样

从公开事件和我自己观察到的大量告警来看，批量攻击的路径大致是：

1. 全网扫描开放了443端口（Web管理和远程接入入口）的FortiGate设备，识别固件版本。
2. 针对已知CVE（比如以往影响管理接口的认证绕过类漏洞、远程接入隧道的代码执行类漏洞）批量发送探测请求。
3. 对成功探针的结果快速生成针对性payload变体，绕过补丁差异。
4. 进入系统后往往先改配置、植入后门，再横向移动。

关键不是某个0day多厉害，而是这波攻击把已公开多年的旧漏洞组合起来，用AI把每个环节提速，最终产生了“每天都能把全世界扫一遍”的效果。

2.2 被反复利用的脆弱面

这次事件里受害设备暴露出几个老问题：

• Web管理接口暴露在公网。这是最不该出现的问题。防火墙的管理接口设计上就应该只允许运维网段访问。
• 远程接入入口未启用多因素认证。攻击者拿到口令或利用漏洞后，进入内网的阻力大大降低。
• 固件长期不更新。不少设备还停留在多个有公开CVE的版本。
• 默认口令和弱口令。永远有人在用admin加旧密码。

这几个脆弱面单独看都是老话题，但一旦攻击者有了流水线，老脆弱面就会被24小时不间断地试探，直到命中为止。

2.3 我用FortiGate模拟器做了一轮“收敛验证”

为了避免在真实生产设备上瞎试，我专门在VM里用FortiGate模拟器搭了一套影子环境，验证加固方案是否有效。整个过程完全在本地测试环境完成，不碰任何生产系统。

验证步骤大致是：先在模拟器上恢复出厂配置，搭出一条接近常见的接入链路；然后对照清单依次执行加固项，把管理接口从WAN端口移除、配置Trusted Hosts只放行运维网段、开启管理员登录失败锁定、关闭用不到的Web服务；再从模拟外网侧发起连接测试，确认管理接口已不可达，同时验证内网运维网段登录正常、锁定策略生效；最后测试固件升级流程，确认升级后配置保留正常。

这套验证跑下来，最大的收获不是某条命令，而是“收敛暴露面”的效果比任何单点补丁都立竿见影。模拟器环境适合做这类验证，但别忘了模拟器和真实设备存在差异，生产变更前务必在官方兼容范围内做评估和变更评审。

2.4 只升级不收敛：这轮事件里最大的误判

事后沟通时，我发现很多管理员以为“我们打了补丁就安全了”。但补丁只是止血，只要管理接口还挂在公网上、远程接入还开着弱认证，新的漏洞一出，同一台设备还是首轮就被打到。

这次事件里不少受害设备，其实就是“升级了最新版但管理口对公网开放”的配置。收敛攻击面、做分层防御，才是让补丁真正起作用的前提。

3. OpenClaw 3万实例沦陷：默认配置把保险柜门敞开了

3.1 三万多实例是怎么暴露的

OpenClaw这类开源AI代理项目，本质是给你一个能调度模型、执行任务、连外部工具的数字助理。部署者通常是为了“给自己用”，于是下意识把服务启动在本机，监听所有网卡的0.0.0.0，然后为了方便远程访问，又在路由器上做了端口转发、甚至直接放进DMZ。坏就坏在这么一搞，服务就不只“本机”了，整个局域网乃至全网都可见。

很多项目默认没有鉴权，或只带一个弱访问口令。攻击者不需要什么高超技巧，开着扫描器在公网上搜特征端口和HTTP返回值，碰到没设口令、没开认证的实例直接接管。3万实例这个数字，给整个“自建AI”社区敲了警钟：工具越火，被全网扫描盯上的速度就越快。

另外还有一个WSL2/Windows部署场景的坑。社区里问“Windows下搭建OpenClaw”“wsl--status报错”的人很多，但很少人意识到WSL2默认NAT模式下，端口转发和监听特性会导致本机服务意外暴露给局域网。很多人说“我明明只在本机跑”，结果局域网里其他机器一访问就进来了。这也是这次大规模沦陷里很值得注意的一条技术伏笔。

3.2 实例被接管的常见痕迹与排查方法

如果怀疑自己的AI代理实例已经中招，建议按下面顺序排查：

1. 看监听端口：执行本机的端口监听查询命令，确认服务是不是监听在0.0.0.0上。如果绑了全局地址，外部就有访问可能。
2. 看认证配置：确认API token或访问口令是否还是默认值或空值，改掉之后立即重启服务。
3. 看日志与进程：检查容器日志、进程启动参数，有没有非预期的任务执行记录、异常外联IP。
4. 看网络连接：查当前活跃连接，如果发现大量对外的SSH、HTTP、IRC等连接，往往意味着你的机器被当成跳板了。
5. 检查文件变动：看部署目录里是否有新增的可执行文件、被篡改的配置文件。

发现异常先别急着删数据——先做快照，再断网隔离，保留现场便于取证。然后重置所有凭据、重新部署、把鉴权打开。

3.3 本地部署不等于安全：三个底线

• 默认监听地址一定要改。服务要么只监听127.0.0.1，要么监听内网IP再加访问控制，没有必要时不要暴露到0.0.0.0。
• 鉴权是必须项，不是可选项。不管项目默认有没有，都要开启认证、更换默认口令，最好让API token具备最小权限。
• 公网访问必须过反代加认证。真需要远程访问，也要在反向代理层加HTTPS、基本认证、IP白名单，而不是把原始端口直接映射出去。

三条对任何自建服务都适用，不只是OpenClaw。这次事件最大的价值，就是让所有自建AI工具的玩家重新读了一遍安全基线。

4. 防守方第一梯队：把AI流水线挡在门外（可直接抄作业）

4.1 FortiGate加固清单

直接给一份可落地的清单，每一项都说明理由：

提示：生产设备的管理变更最好走正式变更流程，先在模拟器或测试机验证，再分批推广，别在业务高峰期直接改。

4.2 日志告警：让流水线留下痕迹

AI流水线速度快，但也不是无痕的，关键在于你愿不愿意把日志收集起来、把告警规则设好。

FortiGate侧至少要把这几类日志持续外送到统一的日志平台：管理接口登录成功和失败日志、远程接入认证日志、配置变更日志、防火墙策略变更日志、异常流量和攻击尝试日志。

配合外部日志平台，设定几条简单但高价值的告警规则：

• 来自公网IP的管理界面登录尝试，哪怕只是失败，也必须告警。
• 同一源IP短时间多次远程接入失败，必须告警。
• 管理员账号新增、配置被修改，必须告警。

有了这些，就算攻击者第一轮打得再快，防守方至少能在“事中”发现，而不是在“事后被通报”。

4.3 自建AI代理和服务的安全基线

给所有正在本地部署DeepSeek、Claude Code、OpenClaw以及各类AI代理工具的人一份基线：

1. 部署前先问“这个服务要不要对外网开放”。不要对外就绑127.0.0.1；要对外就反代加鉴权加HTTPS。
2. 所有默认凭据第一时间改掉，API key用环境变量管理，别硬编码进配置文件。
3. 依赖的第三方skill和插件本身就是供应链风险，安装前看一下来源和代码，别随便跑。
4. 操作系统和运行时（Node.js、Python、Ollama等）及时更新，容器镜像别拿latest当生产固定版本。
5. 给自己写一个“被攻破预案”：发生异常时怎么隔离、怎么重置、日志保留多久。

这五条里有几条是我维护自建AI服务时真正踩过坑才总结出来的。有一次图方便把服务端口映射到路由器上，第二天在日志里看到海外IP的暴力试探，吓得立刻撤了映射。这种反面教材，一次就够了。

5. 面对AI化的攻击，防守方该换哪些思路

5.1 用自动化对抗自动化

攻方有了流水线，防守方如果还靠“人肉巡检”，这场仗没法打。合理的做法是把重复性的安全检查也做成流水线：

• 每周自动扫描一次公网暴露面，对比基线，新增暴露项立刻通知。
• 把资产清单和补丁版本自动化核对，发现落后立即触发处理。
• 日志告警规则持续调优，把AI辅助日志分析纳入值班流程。

蓝队用AI不是“打不过就加入”的自我安慰，而是因为威胁情报、日志分析、策略审计这些工作，AI确实能帮人从大量重复劳动里解放出来。我自己的经验是，先拿低风险、重复度高的任务做试点，比如让模型辅助做告警分类、生成每周安全报告，风险小、见效快。

5.2 安全责任要下沉到每个部署者

过去我们说“安全是安全团队的事”，但现在大量员工在自建AI工具、部署智能体，安全边界比公司网络大得多。独立开发者、运维、甚至只是玩票的爱好者，都是攻击面的一部分。安全基线必须下沉到个人：只要你的服务跑了公网，你就有责任给它上锁。

这次OpenClaw事件里，如果每个部署者都守住了监听地址、鉴权、反代这几条基线，三万实例沦陷的可能性会小很多。

5.3 我的一点真实体会

这轮事件之后，我把自家和负责运维的所有边界设备重新过了一遍：资产清单重新梳理，把“不知道谁在用”的接口和服务全部下线；公网暴露面收敛到最小，管理类入口一个不留；日志全部接到统一平台，告警规则安排专人维护；对自建AI工具专门补了安全规范。

做下来最大的感触是：攻击者用AI把“发现和利用”的时间压缩到了分钟级，防守方的优势只剩下“资产自查和暴露面收敛”这一件事，而这件事恰恰是大部分人最容易拖延的。别等被通报了才动手，现在就打开设备看一眼管理接口是不是还在公网上挂着。这个动作，花不了十分钟。