1、背景说明

记录一次某业务系统被恶意请求,因而主机处理性能被消耗,造成业务访问缓慢,业务通过防火墙把应用端口映射到公网,文中出现的IP已脱敏。

2、拓扑结构

在防火墙把公网IP:111.111.111.60和端口8007映射到负载IP:172.16.10.10:8007(VIP);负载的后端节点为172.16.10.20(该地址为业务主机IP),F5 LTM旁挂在交换机上,当请求流量到达F5-LTM时会进行源地址替换(即SNAT),默认替换为F5设备的Floating IP(172.16.10.254)地址,由于使用了SNAT应用主机要获取客户端源IP的情况下,在F5转发的时候会插入一个X-Forwarded-For简称 XFF头部,把客户端的真实源IP地址写入XFF。
画了个简略图如下:

X-Forwarded-For欺骗引发应用故障及防护措施

3、故障排查

3.1 故障现象

某天正好在上班摸鱼的时候,应用负责人找了过来,反映说业务调用好慢,在应用web页面可以看到提取的源地址为一个私网IP。

3.2 故障定位

  1. 于是和主机运维人员一起排查,登陆172.16.10.20主机查看会话连接,存在大量未建立成功的TCP会话连接,发起端都是F5的Floating IP(172.16.10.254),这样看会话IP是正常的,但业务在web应用上看到的连接数多的源IP为10.5.2.253(应用层会提取XFF头的IP),查询这个IP在内网是没有路由的,又不是客户端公网源IP,这就有点奇怪了
  2. 没办法只能一步步查,登陆F5设备后台查看LB负载IP会话连接:

    show sys connection cs-server-addr 172.16.10.10(VIP)

    在会话里面筛选10.5.2.253这个IP,也没有找到这个IP的连接信息。

  3. 于是想到tcpdump+wireshark大法,在F5设备上和主机端抓包,在F5设备使用tcpdump抓包,命令如下
    tcpdump -s0 -nni 0.0:nnnp host 172.16.10.10 -w /var/tmp/111.pcap
    (-s0是防止包截断,要禁用名称解析,请使用-n标志,-i 指定接口,:nnnp捕获与过滤器相关的 F5 客户端和服务器端的流量)
  4. 通过wireshark打开然后在包中搜索IP:10.5.2.253,果然有惊喜,原来客户端送过的报文已经有XFF头部,还有IP值

X-Forwarded-For欺骗引发应用故障及防护措施

  1. 找到IP就好办了,查看网络层源iP找到真实发起请求的客户端源IP然后在防火墙拒绝掉。在通知应用查看业务状态,此时业务已恢复正常。

X-Forwarded-For欺骗引发应用故障及防护措施

3.3 故障总结

X-Forwarded-For 是一个 HTTP 扩展头部,用来表示HTTP请求端真实 IP,HTTP/1.1 协议并没有对它的定义,但现如今X-Forwarded-For已被各大 HTTP 代理、负载均衡等转发服务广泛使用。

  • X-Forwarded-For 请求头格式:X-Forwarded-For: client, proxy1, proxy2
  • X-Forwarded-For 请求头的内容由英文逗号和空格隔开,每经过一级代理服务器,X-Forwarded-For 后面就会继续添加该代理设备的IP地址。正常情况下,我们所获得第一个IP应该是客户端 IP,但是如果客户端对 X-Forwarded-For 进行了修改,我们仍旧采用以上方法获得客户端 IP,那么客户端 IP 将会是被伪造过的。

4、改进措施

为了防止IP客户端被伪造,F5设备可以通过IRule来移除客户端送过来的XFF头部,把客户端请求来源IP插入X-Forwarded-For,客户端请求来源IP是不能被伪造的,因为在客户端和服务端进行通信的时候,我们需要进行三次握手,如果这个来源IP是假的,那么我们的握手是不会成功的,Irule规则如下:

X-Forwarded-For欺骗引发应用故障及防护措施
用postman伪造XFF头部IP发起请求,经过验证经过F5设备后,客户端送过来的XFF头部移除成功,这里就不在演示。
::: hljs-center

获取Irule规则,可以关注微信公众号后台回复“irule”

:::
扫码_搜索联合传播样式白色版1.png

qip