[建议] 支持配置 XFF 解析规则，当使用多层CDN时，无法准确获取真实客户端IP

[nanxuanmoke]

问题描述

Version 3.3.0

CDN第一层使用的YUNDUN，第二层使用的奇安信。

使用多层CDN时X-Forwarded-For内会包含多个IP，第一个IP是客户端I，但雷池WAF只获取最后一个IP作为客户端IP。

这就导致了一些问题，一个是客户端IP不准确导致无法对IP组做出限制以及放行，还有导致用户访问超过限频阈值，因为全被计到一个IP头上去了。

以下为示例： X-Forwarded-For: 39.9.9.9, 183.9.9.9

39.9.9.9 正确的客户端IP 183.9.9.9 是奇安信CDN

雷池获取最后一个IP（183.9.9.9）作为客户端IP，而第一个才是正确的客户端IP。也有可能直接获取socket ip？

这里有个和我相同问题的同学，https://github.com/chaitin/SafeLine/issues/208。看到这里回复说会将X-Forwarded-For整体作为IP解析，解析失败则使用socket ip，这是个问题，如果使用了多层反向代理的话，则无法正确通过X-Forwarded-For获取客户端IP，X-Forwarded-For是有可能包含多个IP的，不应该将其作为一个整体解析，应该解析其中的IP，并获取第一个IP为客户端IP。

当X-Forwarded-For存在多个ip时，第一个IP为客户端IP，其余都是网络过程中负载均衡、CDN等。

[zclaiqcc]

第一层 CDN 把 socket ip 放在 X-Real-IP 里面，然后雷池解析这个 Header 就行了？ https://waf-ce.chaitin.cn/docs/faq/other#%E6%BA%90-ip-%E6%98%BE%E7%A4%BA%E4%B8%8D%E6%AD%A3%E7%A1%AE

[nanxuanmoke]

第一层 CDN 把 socket ip 放在 X-Real-IP 里面，然后雷池解析这个 Header 就行了？ https://waf-ce.chaitin.cn/docs/faq/other#%E6%BA%90-ip-%E6%98%BE%E7%A4%BA%E4%B8%8D%E6%AD%A3%E7%A1%AE

我设置不了，CDN服务商并不提供这个选项。有的CDN可以指定字段包含客户端IP，有的并不行，雷池这边修改匹配规则一劳永逸，而且X-Forwarded-For解析本该就是这样，第一个作为客户端IP。

[nanxuanmoke]

第一层 CDN 把 socket ip 放在 X-Real-IP 里面，然后雷池解析这个 Header 就行了？ https://waf-ce.chaitin.cn/docs/faq/other#%E6%BA%90-ip-%E6%98%BE%E7%A4%BA%E4%B8%8D%E6%AD%A3%E7%A1%AE

我设置不了，CDN服务商并不提供这个选项。有的CDN可以指定字段包含客户端IP，有的并不行，雷池这边修改匹配规则一劳永逸，而且X-Forwarded-For解析本该就是这样，第一个作为客户端IP。

X-Real-IP IP也不是正确的，而是CDN IP，只有X-Forwarded-For中第一个才是客户端IP。

[zclaiqcc]

第一层 CDN 把 socket ip 放在 X-Real-IP 里面，然后雷池解析这个 Header 就行了？ https://waf-ce.chaitin.cn/docs/faq/other#%E6%BA%90-ip-%E6%98%BE%E7%A4%BA%E4%B8%8D%E6%AD%A3%E7%A1%AE

我设置不了，CDN服务商并不提供这个选项。有的CDN可以指定字段包含客户端IP，有的并不行，雷池这边修改匹配规则一劳永逸，而且X-Forwarded-For解析本该就是这样，第一个作为客户端IP。

第一层的 CDN 也没法透传 socket IP 么？那讲道理感觉这个 CDN 不太行吧哈哈哈。

XFF 解析能力确实可以进一步优化一下，之前没做很丰富是考虑到大多数用户都不一定能用得明白，没有想到一种简单方案的产品设计。

[jamebal]

遇到了同样的问题，能使用X-Forwarded-For中第一个IP就好了

[jssolo]

现在取的不是X-Forwarded-For中的第一个吗，按理说X-Forwarded-For第一个才是真实ip

[nanxuanmoke]

现在取的不是X-Forwarded-For中的第一个吗，按理说X-Forwarded-For第一个才是真实ip

没有取第一个，而且根据之前的issue回复，他们是直接解析整个X-Forwarded-For，如果解析失败，直接取socket ip。 没有考虑到多个ip的问题，如果X-Forwarded-For内含有多个ip则会解析失败，然后取socket ip。 所以这是bug，需要修复。

[zclaiqcc]

目前确实不支持多个 XFF 头解析。页面上“源 IP 获取方式”从 HTTP Header 中解析设计就是取一整个字段，尝试整体解析为 IP，解析失败则使用 socket ip。

之前没有支持更丰富的 XFF 主要是配置和使用起来太麻烦了，很容易配置不明白，甚至配置错。所以基本上都是建议从最前面的网关设备透传 X-Real-IP 作为唯一的客户端 IP 字段，确实没有遇到过某个 CDN 不支持配置该字段的情况。

XFF 配置复杂在哪呢，举例来说，师傅提到：

而且X-Forwarded-For解析本该就是这样，第一个作为客户端IP。

首先有一个 XFF 的顺序，先不纠结正数第一个还是倒数第一个的问题。因为从左往右和从右往左看起来是两个顺序，然而大家似乎没有统一口径。（小问题）

其次是从左往右取第一个并不安全，因为这些都是可以伪造的，客户端随便发一个 XFF 127.0.0.1 的包就行了。只有进入到内部网络之后，最后追加的那些才是安全可信的。所以一般情况下比较安全可靠的 XFF 配置都是按照从右往左的顺序解析。

还有一种我遇到的实际情况，用户部署环境的流量来自不同的网络拓扑。有的客户端通过百度 CDN 到雷池 WAF，有的通过别的内部代理，导致 XFF 解析层次也不一样。不如各个网关设备都统一写入某一个固定的字段，比如 X-Real-IP，来得简单直接。

所以大多数情况下，对于 XFF 的解析都是配置类似于“从 XFF 解析最后一层非受信任 IP”，然后填入自己一堆内部网关的 IP，这样就是比较可靠的获取客户端 IP 的方式。

我认同很多情况下大家都是直接获取 XFF 倒数第一层作为源 IP 就够了，但是这不太正确。从功能设计的角度也不合理。相当于给大家提供了一个很难用，或者容易用错的产品设计。

为了避免增加使用者的理解负担，普通用户用不起来；同时确实没有遇到过哪家 CDN 不支持把客户端 IP 写入 X-Real-IP（或者随便其他自定义的 Header）。所以这个需求短期估计不会考虑实现在社区版。

issue 先留着，看有多少用户需要这个功能。

不过额外提醒一下，切勿混淆企业级需求和社区用户需求，企业需要的是全面、专业，有点“我可以不用，但是你不能没有”的意思。社区需求不是，首先就是能用就行，然后才是如何更好用，更全面。当然产品最终会迭代到相对成熟和全面的阶段，但是短期一定不会优先满足需求不算太普遍的场景，这样就做窄了，迭代速度快不了。

[iuime]

遇到同样的问题，多个xff头就没办法获取真实ip，建议优化一下

[ylwzbk]

还有一种情况就是 阿里 的 DCDN->WAF->web 当雷池上添加的域名a.com 阿里云DCDN 而 b.com其他CDN的时候WAF 获取的源IP也是五花八门 但阿里DCDN是Ali-Cdn-Real-Ip参数是客户源IP

[zclaiqcc]

遇到同样的问题，多个xff头就没办法获取真实ip，建议优化一下

同样的建议，通过让前面的网关设备把客户端的真实 IP 放到 X-Real-IP（或者别的名字）里面？

[zclaiqcc]

还有一种情况就是 阿里 的 DCDN->WAF->web 当雷池上添加的域名a.com 阿里云DCDN 而 b.com其他CDN的时候WAF 获取的源IP也是五花八门 但阿里DCDN是Ali-Cdn-Real-Ip参数是客户源IP

同样的建议，通过让前面的网关设备把客户端的真实 IP 放到 X-Real-IP（或者别的名字）里面？

[ylwzbk]

还有一种情况就是 阿里 的 DCDN->WAF->web 当雷池上添加的域名a.com 阿里云DCDN 而 b.com其他CDN的时候WAF 获取的源IP也是五花八门 但阿里DCDN是Ali-Cdn-Real-Ip参数是客户源IP

同样的建议，通过让前面的网关设备把客户端的真实 IP 放到 X-Real-IP（或者别的名字）里面？ 阿里的DCDN 控制台 没有设置的办法， 雷池设置了X-Real-IP， b.com 是腾讯的CDN 就没问题 a.com 阿里的就是获取的DCDN -ip

[fankejing-just]

现在XFF，默认取右边第一个，不科学，很多源IP是其实左边第一个，建议至少增加一个取XFF的方向按钮，最好可以弄成可以自己写正则或者脚本解析的。 雷池对阿里云CDN回源的源IP处理的不错（毕竟是一个家人，呵呵）但是对其他CDN回源默认取XFF右边第一个，基本都是错，目前测试下来，华为云、腾讯云都无法争取取得源IP，获取IP都是CDN节点IP

[f0re1gnKey]

其实这种问题，设置一个【取XFF第几个IP】的数字填写框，就可以完美解决，隔壁uuwaf也是这样解决这个问题的。

但是自定义Header一定要保留下来，XFF并不是唯一选择

[gitlsl]

微软在asp.netcore中的实现是 添加信任IP， 把XFF头分割， 去掉信任ip， 再 根据 limit（控制第几个）取ip

[fobole-openthedoor]

现在增加的几个选项，我觉得还是有点死了。

如果选择了取上上级，在XFF是ip1,ip2的情况下能正常取到ip1，但是如果XFF只有ip1的情况下无法解析到上上级是只能取socket ip。

建议能不能增加一个取最左侧IP的选项或者在取不到设定的几级IP时向右兼容比如上述情况时直接取ip1 ？

我知道长亭是安全出身的，对这个东西很敏感，但是还是有很多CDN并不是按照规范做事，希望还是能够给予用户选择的权利。

[Lorna0]

现在增加的几个选项，我觉得还是有点死了。 如果选择了取上上级，在XFF是ip1,ip2的情况下能正常取到ip1，但是如果XFF只有ip1的情况下无法解析到上上级是只能取socket ip。

建议能不能增加一个取最左侧IP的选项或者在取不到设定的几级IP时向右兼容比如上述情况时直接取ip1 ？

我知道长亭是安全出身的，对这个东西很敏感，但是还是有很多CDN并不是按照规范做事，希望还是能够给予用户选择的权利。

没理解，如果XFF只有ip1，为什么不直接选取上级呢。

如果 waf 前面的代理情况是混杂的，一部分有 1 级代理，一部分有 2 级代理，那么并不适合使用这种按可信数量配置的方法。如果继续向右取的话，仍然存在安全风险。可以参考：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For#selecting_an_ip_address

[Lorna0]

5.4.0 版本支持了取 XFF 中上三级代理的地址，也即从 XFF 中排除可信代理数量的取法：

这个 issue 可以算阶段性结束了，感谢师傅们花时间参与讨论和分享自己的使用情况。当然，XFF 的解析方法有很多，也有很多细节需求，目前我们只是做了一个平衡安全性、易用性和产品简洁度的解法，如果大家还有其他想法的话，可以再提个具体的 issue，方便集中意见讨论和跟进。