内容摘要：去年十一月，我们一台对外提供API服务的边缘节点在凌晨两点十七分被打了。流量从平时的30Mbps瞬间飙到4.2Gbps，持续了不到八分钟。值班同事被短信告警叫醒的时候，攻击已经结束了。事后复盘发现，攻

去年十一月，网络我们一台对外提供API服务的攻防边缘节点在凌晨两点十七分被打了。流量从平时的总结30Mbps瞬间飙到4.2Gbps，持续了不到八分钟。报告值班同事被短信告警叫醒的网络时候，攻击已经结束了。攻防事后复盘发现，总结攻击者用的报告是UDP反射放大，伪造源IP指向我们的网络节点，打的攻防是DNS的53端口。这种手法不新鲜，总结但足够有效——八分钟里我们损失了大约两千次正常请求，报告好在没有数据泄露。网络

这件事让我重新审视了手头这套防护体系。攻防说实话，总结大部分中小团队的网络防护，本质上就是“买了几台设备，配了几条规则，然后祈祷别出事”。我们也不例外。WAF是有的，但规则库更新频率取决于厂商心情。DDoS清洗服务是有的，但阈值设得偏高，等它自动触发的时候，服务已经挂了。防火墙策略更是祖传的，上一任运维留下的iptables规则里，居然还开着几个早就下线的测试端口。

攻击面这东西，你不主动去量，它就一直在暗处长。我后来花了两周时间做资产测绘，用Nmap扫了自己的公网段，结果吓一跳：一个被遗忘的Jenkins实例，版本是2.138，CVE-2018-1000861的漏洞明晃晃地摆在那里。没人知道它什么时候被部署的，也没人知道它为什么还在跑。这就是典型的“影子资产”——你以为你已经清理干净了，实际上角落里还蹲着一个。

防守方的困境在于，你面对的是一个非对称的战场。攻击者只需要找到一个入口，你需要堵住所有出口。而且攻击者的成本极低，一个开源的扫描器，加上几台VPS，就能发起一轮像样的探测。我抓过几次扫描流量，大部分来自境外云服务商，源IP段集中在几个已知的恶意网段。封禁当然有用，但治标不治本。真正的问题是，你的服务必须对公众开放，而开放的端口就是攻击者的入口。

说到具体案例，今年三月我们遭遇了一次针对登录接口的撞库攻击。攻击者用的是一个泄露的密码字典，大约五十万条记录，配合我们已知的用户名列表，尝试了将近十二万次登录。我们的限流策略是每分钟每个IP允许二十次请求，但攻击者用了代理池，IP分散在几百个C段里。最终有三十七个账号被成功登录，其中两个是管理员权限。发现的时候，攻击者已经用其中一个账号创建了后门API密钥。这件事的教训是，限流不能只看IP，还得看行为模式——比如同一时间段内，大量不同IP尝试登录同一批用户名，这种模式用简单的阈值规则根本抓不住。

防守策略上，我现在更倾向于“纵深防御”加上“主动狩猎”。纵深防御不是堆设备，而是把认证、授权、审计三层拆开，每一层都有独立的检测点。主动狩猎则是定期用攻击者的视角去审视自己的网络，比如用Metasploit跑一遍已知漏洞的利用模块，看能不能打进去。这种“自己打自己”的方式，比等别人来打要靠谱得多。

还有一点，日志。很多团队出事之后查不到东西，就是因为日志要么没开，要么存了但没人看。我们的做法是把所有关键节点的日志集中到一台ELK上，设置了几条简单的关联规则，比如“五分钟内同一账号从三个不同地理位置的IP登录”，触发就告警。这套东西不高级，但管用。上个月它帮我们抓到了一个内部员工的异常访问行为，后来查实是账号被盗，不是内鬼。

攻防这件事，没有一劳永逸的解决方案。你今天堵住的漏洞，明天可能因为一次业务变更重新打开。防守方的优势在于熟悉自己的网络，劣势在于永远处于被动响应。我的判断是，与其追求“绝对安全”，不如把精力放在“快速发现和响应”上。攻击者总会找到入口，关键是你能不能在他造成实质性破坏之前，把他踢出去。

最后说一个细节。那次DDoS攻击之后，我在防火墙里加了一条规则：任何来自我们已知反射放大列表的UDP流量，直接丢弃。这条规则很简单，但后来拦截了至少三次类似的攻击尝试。有时候，有效的防守就是这种不起眼的小事。