nGrinder TestRunner XFF / X-Forwarded-For

s

我们在压测请求报文里面带了这个"x-forward-for":"10.24.51.132"这个字段，所以我们所有的压测请求穿透到应用系统的时候，应用系统上采集到的请求ip都是这个"10.24.51.132"，但是这个不代表所有的请求是来自同一个ip地址，实际上的压测请求还是来自40台agent服务器

HTTP 请求头中的 X-Forwarded-For（XFF）

https://blog.csdn.net/yizhenn/article/details/60955599

在Java代码实践中，有两种方式可以从HTTP请求中获得请求者的IP地址。一个是从Remote Address中获得，另一个是从X-Forward-For中获得，但他们的安全性和使用场景各有不同。一旦用错，就可能为系统造成漏洞。因此，需要开发者对这两个参数深入的理解。
Remote Address代表的是当前HTTP请求的远程地址，即HTTP请求的源地址。HTTP协议在三次握手时使用的就是这个Remote Address地址，在发送响应报文时也是使用这个Remote Address地址。因此，如果请求者伪造Remote Address地址，他将无法收到HTTP的响应报文，此时伪造没有任何意义。这也就使得Remote Address默认具有防篡改的功能。
在一些大型网站中，来自用户的HTTP请求会经过反向代理服务器的转发，此时，服务器收到的Remote Address地址就是反向代理服务器的地址。在这样的情况下，用户的真实IP地址将被丢失，因此有了HTTP扩展头部X-Forward-For。当反向代理服务器转发用户的HTTP请求时，需要将用户的真实IP地址写入到X-Forward-For中，以便后端服务能够使用。由于X-Forward-For是可修改的，所以X-Forward-For中的地址在某种程度上不可信。
所以，在进行与安全有关的操作时，只能通过Remote Address获取用户的IP地址，不能相信任何请求头。
当然，在使用nginx等反向代理服务器的时候，是必须使用X-Forward-For来获取用户IP地址的（此时Remote Address是nginx的地址），因为此时X-Forward-For中的地址是由nginx写入的，而nginx是可信任的。不过此时要注意，要禁止web对外提供服务。

nginx 反向代理与 Real-IP 和 X-Forwarded-For

https://blog.csdn.net/broadview2006/article/details/54570943

总结
1.通过“proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for” 把从真实客户端IP和反向代理IP通过逗号分隔，添加到请求头中； 
<br>
2.可以在第一个反向代理上配置“proxy_set_header X-Real-IP $remote_addr” 获取真实客户端IP； 
<br>
3.配合realip模块从X-Forwarded-For也可以获取到真实客户端IP。<br> 
在整个反向代理链条的第一个反向代理可以不配置“proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for”，<br>
否则客户端可以伪造X-Forwarded-For从而伪造客户端真实IP，<br>
如果服务端使用X-Forwarded-For第一个IP作为真实客户端IP，则就出问题了。<br>
如果通过配置X-Real-IP请求头或者配合realip模块也不会出现该问题。<br>
如果自己解析X-Forwarded-For的话，记得使用realip算法解析，而不是取第一个。<br> 
当我们进行限流时一定注意限制的是真实客户端IP，而不是反向代理IP，我遇到过很多同事在这块出问题的。

　　

问题表象1：

拦截量从5点开始增多，从日志看是因为请求中x_forwarded_for字段为空，导致WAF获取不到用户的IP，WAF会将所有未获取到IP的请求当成同一个人发起，超过频率限制被拦截

分析问题1：

web访问软防火墙安全规则1：如果一个用户连续两次请求之前时间间隔不大于1秒，算1次；

web访问软防火墙安全规则2：B2C分区设置的每分钟一个用户此种情况拦截阈值为4200，除以集群系数，每台防火墙服务器上每分钟一个用户此种情况超过70次就会拦截。

解决问题1：

数据链路:用户 -- > CDN -- > F5 VIP(无配置x_forwarded_for导致) --> WAF防火墙（误认为同一IP，触发封禁规则） -->  B2C 主站。

解决方法1

数据链路:用户 -- > CDN -- > F5 VIP(无配置x_forwarded_for导致) --> WAF防火墙（同一F5 VIP设置白名单，临时解禁规则） -->  B2C 主站。

解决方法2

数据链路:用户 -- > CDN -- > F5 VIP(配置x_forwarded_for) --> WAF防火墙（不再认为同一VIP F5设备，终极解决） -->  B2C 主站。

　　

end