发布于 ,更新于 

验证:所幸,七牛云还是能「防护」住 XFF 的(附后续)

验证

上一篇博文 中,我添加了一个「第三天醒来的事」的章节。原因是发现了 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 并配置低阈值告警, 查看一下修复后的效果,希望他真的修了吧。