- upd at 2024/7/31: 请查看 七牛回应的后续
验证
在 上一篇博文 中，我添加了一个「第三天醒来的事」的章节。原因是发现了 v2ex 上的一个帖子，说阿里云早在2个月前就有了类似的问题。
我在上文中的表述一直是：有可能进一步影响 IP 黑白名单配置。为什么强调是「有可能」呢？因为在那个域名配置卡到今天的情况下，我并没有机会进一步测试。
目前确定已知的问题是：七牛云（现在又包括阿里云）的日志功能会记下 X-Forwarded-For 伪造的 IP 地址。
鉴于我上一个域名的配置跨越了一天还未完成。我去借了一个新七牛号把自己的IP段加进了黑名单，好消息是：七牛可以防住。
至此，七牛能不能被打穿的问题已经盖棺定论：在配置好黑名单的情况下可以防住。由此，对因上一篇博文可能造成的困扰向七牛诚挚致歉。
后日谈
尽管这一件事可以让大伙暂时喘口气，但是这件事暴露了更多的问题。
- 一部分问题已经在 上一篇博文 有说，阿里云也有相关的问题，从最外层看不见从用户端到 CDN 的全部 IP。
- 这个行为保底自 2 个月前就开始了，为什么迟迟防不住？
- 一切的一切，背后还有一个可能延宕了数年的问题：这次能加黑名单是因为这个团伙的行为太猖獗，IP 情报早已共享，把一大串复制加上就行；但要是以后，真正的个体使用一台境外服务器对你进行 XFF 刷量，你一边关停着 CDN，一边看着日志里「0.114.5.14」的 IP 暗自发闷。不对日志机制加以改造，你永远（在前台）拿不到攻击者的真实IP。
目前已知阿里云和七牛云存在这个问题了，其他的呢？
也正因此，七牛（也可能包括一众其他 CDN）在这件事上可能甩不掉锅。
最后
喜报：七牛的黑名单还是能防住 XFF 伪造的攻击，防护山西联通的当前攻势可能足够。
悲报：以后被单一个体攻击的时候，你可要注意日志里显示的究竟是不是真实的 IP 了。因为正如上文所言，分散在一堆正常用户里的零散请求也有可能是单一机器发出来的。
在这件事得到改善之前，我都不建议大家相信后台给出来的任何 IP，原因已经阐述了一次又一次。
不知道的还以为我是什么大站呢。
另外，考虑到攻击多会在非工作日时段进行，务必记得配好告警，然后找个黑名单配置下发没那么慢的 CDN。
后续
感谢七牛的商务老师，为本次盗刷申请了一个 500G 的补偿流量包，拿来冲抵本次损失已然足够。
工单那边，我的工单已经被标记为 「resolved」，工程师的回复如下：
您好，
非常抱歉之前的日志记录问题，给您带来了困惑和不好的体验。
日志client_ip输出异常的问题当前已修复，会记录真实客户端请求ip，而不再是由xxf伪造的第一段ip，
可以通过CDN日志看到真实客户端ip，从而配置黑名单对访问进行拦截
您可以再次验证下，有问题您再反馈这边
考虑到先前的经历，我将在一段时间后启用 CDN 并配置低阈值告警， 查看一下修复后的效果，希望他真的修了吧。