内容摘要：去年十一月，我蹲在客户机房折腾到凌晨三点，原因说出来有点丢人——一台防火墙的默认口令没改，被人从外网直接登录，把内网三层交换机的ACL全删了。整个园区断网六个小时，生产线停了，老板的电话打爆了我的手机

去年十一月，必火我蹲在客户机房折腾到凌晨三点，网络原因说出来有点丢人——一台防火墙的安全默认口令没改，被人从外网直接登录，必火把内网三层交换机的网络ACL全删了。整个园区断网六个小时，安全生产线停了，必火老板的网络电话打爆了我的手机。这事之后我养成了一个习惯：给任何新设备上架前，安全先拔掉网线改密码。必火

“必火网络安全”这个名字听起来像个段子，网络但干这行的安全人都知道，很多事故之所以“必火”，必火纯粹是网络因为低级失误堆得太整齐了。我见过把数据库端口直接暴露在公网还沾沾自喜说“我们做了IP白名单”的安全运维，白名单里写的是0.0.0.0/0。也见过安全厂商的售前拿着拓扑图讲“零信任架构”，结果后台管理页面的登录验证码是前端JavaScript生成的，抓个包就能绕过。

这些事没人愿意往外说。圈子里有个默认的默契：出了事，内部复盘，罚酒三杯，对外统一口径“系统升级”。但问题不会因为不说就消失。去年某省级政务云被挖矿木马入侵，通报里写的是“遭受新型网络攻击”，实际上攻击者用的漏洞是两年前就公开的Log4j。为什么没修？因为那台服务器跑着一个外包公司三年前交付的系统，外包公司已经注销了，源码找不着，没人敢动。

这就是网络安全最荒诞的地方：技术更新快得离谱，但真正决定安全水位的东西往往特别原始。一个中型企业，防火墙买了，入侵检测装了，堡垒机也上了，结果所有运维人员共用一个root密码，离职半年了还没改。你跟他讲零信任，他问你零信任能不能开发票。

我自己的判断是，大部分“必火”的安全事件，根子不在技术，在权责。安全部门没预算、没话语权，业务部门一句“影响上线”就能把安全评估压下去。等真出了事，安全部门背锅，业务部门写个检查继续干活。这种结构下，买再多设备也是心理安慰。

有个做渗透测试的朋友跟我说过一句话，我记到现在：“我进一家公司内网的平均时间是四十分钟，其中三十五分钟在找入口，五分钟在利用。”那五分钟用的工具，可能就是个开源的脚本，GitHub上随便下。真正难的是前面三十五分钟——判断目标、收集信息、找那个“人”的疏忽。安全对抗到最后，拼的不是谁家防火墙吞吐量大，是谁家运维半夜三点被叫起来改密码的时候，不会骂骂咧咧地直接把密码设成admin123。

说回“必火”这两个字。火不火，看的是有没有人真的在乎。我在一个甲方做安全顾问的时候，每周给开发团队发一次漏洞报告，连续发了三个月，没人回。后来我把报告抄送给了CTO，附了一句“这个SQL注入能直接拖走用户表”，第二天修复排期就下来了。不是技术问题解决了，是责任链条通了。

所以别指望买个“必火”牌的安全产品就能高枕无忧。那东西大概率只能防住脚本小子，防不住一个铁了心要搞你的人，更防不住你自己人图省事留下的后门。安全这行干了八年，我最大的体会是：最有效的安全措施往往最不性感——改密码、打补丁、做备份、看日志。就这四件事，能做到的企业，我见过的不到三成。

剩下的七成，不是不知道，是觉得“不会轮到我”。直到轮到了，才想起来机房那台防火墙的默认口令还没改。