实习生接手3亿请求防御战：1个IP typo差点封了半个北美用户

入职第一天，文档还没读完，任务就来了——搭建一套全自动恶意IP拦截系统。不是打杂，是直接对3亿次日均请求负责。

这让我想起装修时的经历：师傅说防水没做好，楼下三家都得找你。网络安全同理，一个漏洞漏过去，整个服务集群都可能被拖垮。

手工封IP就像用漏勺抗洪

传统安全团队怎么干活？分析师盯日志发现可疑IP，登录云平台，手动添加防火墙规则。流程没错，但规模一上来就崩。

威胁情报每分钟都在变。某IP上午还是正常用户，下午就可能被僵尸网络征用。手工更新根本追不上这个速度，更可怕的是人为失误——输错一个网段，可能把半个北美用户的IP全封了。

我翻看了过去半年的工单记录，手工封禁的平均响应时间是47分钟。而一次典型的暴力破解攻击，从开始到成功撞库，最短只需要11分钟。

防御永远慢半拍，这仗没法打。

自动化不是写脚本，是重新设计"反应弧"

项目目标很明确：set and forget，部署后无需人工干预。但实现起来要拆解三层——数据从哪来、怎么判断、如何执行。

数据源选了三个互补渠道：商业威胁情报订阅、开源情报社区（如AbuseIPDB）、以及内部蜜罐捕获的主动探测行为。每个源给IP打分，加权后超过阈值自动触发封禁。

判断逻辑是核心难点。直接封禁会误伤，完全放行会漏检。我们设计了渐进式响应：首次可疑先限速，二次触发加验证码，三次确认恶意才彻底封禁。整个过程从检测到执行，目标控制在90秒内。

执行层对接云厂商的API，但这里有个坑——不同区域的防火墙规则是独立的。北美封了的IP，亚太可能还在放行。最终用基础设施即代码（Infrastructure as Code）统一管理，确保全球策略一致。

网络架构：先把自己藏好

系统本身也是攻击目标。如果自动化脚本被入侵，攻击者可以直接往白名单里加IP，或者批量封禁正常用户。

我们在虚拟私有云（VPC）里划了独立子网，安全服务全部部署在内网。对外通信走专用网关，脚本权限按最小原则拆分——读取情报的只读密钥、修改防火墙的写密钥、审计日志的只读密钥，三权分立。

路由策略也做了隔离：内部组件可以互相通信，但绝不直接暴露公网。这相当于给自动化系统穿了件防弹衣，就算外围被突破，核心逻辑也不会第一时间沦陷。

上线第一周，系统自己"抓"到了内鬼

全量部署后，监控面板开始滚动刷新。第一个24小时，系统拦截了12万次恶意请求，零误报。

但第三天凌晨，一个异常告警跳了出来：某内部测试环境的IP被标记为高风险。追查发现，是某个开发同事把测试脚本配错了参数，正在对外网发起高频探测——行为模式和真实攻击者几乎一样。

自动化系统没有"这是自己人"的豁免权，照样按规则限速处理。这件事让团队意识到：好的安全系统应该对事不对人，内部失误和外部攻击造成的后果没有区别。

现在这套机制已经跑了8个月，累计处理超过4亿次威胁判定。最近一次的架构复盘会上， mentor 提了一个问题：如果明天攻击者开始用住宅代理轮换IP，我们的评分模型多久能跟上？

这个问题目前没有答案——但系统留好了接口，新数据源接入只需要改配置文件，不用动核心代码。防御战没有终局，只有不断迭代的响应速度。