凌晨三点十七分，网络我的攻击手机在床头柜上疯狂震动。不是整改闹钟，是报告值班工程师打来的——生产环境数据库CPU占用率100%，所有写入操作全部超时。网络

登录跳板机一看，攻击攻击流量从47个国家的整改600多个IP同时涌进来，每秒请求量峰值达到23万次。报告这不是网络普通的扫描，是攻击精心策划的分布式拒绝服务攻击，夹杂着针对我们API接口的整改定向注入尝试。防火墙日志显示攻击从23点47分就开始了，报告整整三个小时我们才从业务异常中察觉到不对劲——监控系统报警阈值设得太高，网络这是攻击第一个要改的地方。

我们花了40分钟才把流量引流到清洗节点，整改期间损失了大约18万条订单数据。有些客户已经开始在社交媒体上骂了。说真的，当你的业务系统在用户眼皮底下趴窝，任何解释都像借口。

事后复盘，攻击路径其实并不复杂。他们先对官网发起低强度扫描，摸清了我们的CDN节点分布，然后绕过了CDN直接攻击源站IP——这个IP是三个月前为了调试小程序临时开放的，一直没关。就这么个疏漏，被对方用Shodan轻松扫到。

整改从三个层面推进。网络架构上，源站IP全部迁移到内网，对外只保留负载均衡和WAF节点，同时给所有公网入口加了访问控制白名单。别嫌麻烦，业务方一开始抱怨访问变慢，但安全性和便利性本来就需要平衡。

监控系统彻底重构。原来的阈值是拍脑袋定的，现在基于过去180天的流量基线自动计算动态阈值，任何超过三倍标准差的变化都会触发告警，通知链路由原来的邮件升级为电话加短信双通道。另外加了实时流量分析模块，能自动识别异常协议特征并触发旁路阻断。

人这一环也出了大问题。攻击发生时，值班工程师第一反应是重启数据库，而不是先看流量状态。这种操作惯性很致命——我们专门做了应急演练，把攻击场景编成脚本，每周五下午随机触发一次，要求值班人员在15分钟内完成初步处置。刚开始通过率不到三成，练了一个月后能到九成以上。

还有个细节值得说说。攻击者利用了我们一个老旧的图片上传接口，那个接口没有做文件类型校验，被传了个PHP webshell上去。虽然权限受限没能提权，但这也暴露了资产管理混乱的问题——那个接口所属的系统按计划本该在去年底退役，结果因为业务部门一直在用，就搁置了。现在我们建立了严格的资产退役流程，超过服务期限的系统必须下线，除非业务方签署风险承诺书。

整个整改花了三周，投入了大概四十人天的工作量。代价不小，但比起客户流失和品牌信誉损失，这笔账怎么算都划算。

攻击者至今没抓到，但这不重要。重要的是我们弄明白了一个道理：网络攻击不是运气问题，是管理问题。每次漏洞背后都对应着某个流程上的松懈——要么是忘了关的端口，要么是没人跟进的旧系统，要么是应急响应时的手忙脚乱。把这些漏洞堵上，比追查谁攻击了你更有意义。