前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >获取来源IP地址的正确姿势

获取来源IP地址的正确姿势

作者头像
FB客服
发布2018-02-28 16:29:52
3.9K1
发布2018-02-28 16:29:52
举报
文章被收录于专栏:FreeBufFreeBuf

背景

笔者从去年6月份开始研究IP地址,陆续踩了很多很多坑,也结识了一大批同行业的前辈。

我能说我是这个圈子里年龄最小的么…..我一直在承受我这个年纪不该有的智慧和经历。

关于IP地址的研究,此前我写过一个完整的系列,先后被未央网、雷锋网和先知社区转载。如果你想看的话,可以戳这里:反欺诈专栏

我们首次建模完成之后,迫不及待地让同事帮忙把数据提取出来,进行人工审核评估,却发现结果中有很多很多保留IP,心里哇凉哇凉的。每次和客户对接,我都花很长的时间跟对方的技术人员解释如何正确地获取来源IP地址,但是每家公司的情况都有所差别,没有一个标准方法。也有一些公司,由于相关的代码已经存在了很久,没有人维护,而业务系统的架构已经变更了多次,原有的代码,获取出来的IP都是错的。

想象一下,每天都有人在问你:127.0.0.1这个IP是啥?这个IP怎么发了那么多请求?这是不是个基站?还是服务器IP?难不成是代理?还是我们被攻击了?诶你说话啊?

关于保留IP

下面是从维基百科上摘录的保留IP地址段,共计16个(最后两个段一般会合并,也可以认为是15个)。

保留地址段

地址起始

IP地址数量

用途

0.0.0.0/8

0.0.0.0 – 0.255.255.255

16,777,216

软件

10.0.0.0/8

10.0.0.0 – 10.255.255.255

16,777,216

内网

100.64.0.0/10

100.64.0.0 – 100.127.255.255

4,194,304

内网

127.0.0.0/8

127.0.0.0 – 127.255.255.255

16,777,216

主机(本机)

169.254.0.0/16

169.254.0.0 – 169.254.255.255

65,536

本地子网(DHCP Failed)

172.16.0.0/12

172.16.0.0 – 172.31.255.255

1,048,576

内网

192.0.0.0/24

192.0.0.0 – 192.0.0.255

256

内网

192.0.2.0/24

192.0.2.0 – 192.0.2.255

256

“TEST-NET”

192.88.99.0/24

192.88.99.0 – 192.88.99.255

256

6to4 anycast

192.168.0.0/16

192.168.0.0 - 192.168.255.255

65,536

内网

198.18.0.0/15

198.18.0.0 – 198.19.255.255

131,072

内网

198.51.100.0/24

198.51.100.0 – 198.51.100.255

256

“TEST-NET-2”

203.0.113.0/24

203.0.113.0 – 203.0.113.255

256

“TEST-NET-3”

224.0.0.0/4

224.0.0.0 - 239.255.255.255

268,435,455

预留

240.0.0.0/4

240.0.0.0 – 255.255.255.254

268,435,455

预留

255.255.255.255/32

255.255.255.255

1

广播

我经常拿这个问题去刁难人,能说出三个段的人,至少是具备网络基础知识的,说出5个以上的,一般我会请他喝酒。

连保留IP是啥都不知道的,我就得尝试用另外一种方式去跟他解释这个问题了。

保留IP可以说是TCP/IP协议的约定吧,每一个段都有相应的使用说明,都有与之对应的RFC文档。

比如,中国境内,移动设备在 4G 环境下获取到的内网IP,一般是 10.0.0.0/8 或者 100.64.0.0/10 的。

非物理隔离的网络系统,一般会是用 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8 内划分内网地址,比较常见。

据@高春辉说,除了这些之外,还有一些很小的保留 IP 段,如果不详细去看完整的 whois 数据,可能都不会发现。

聊聊XFF

X-Forwarded-For(XFF)是用来识别通过HTTP代理或负载均衡方式连接到Web服务器的客户端最原始的IP地址的HTTP请求头字段。 Squid缓存代理服务器的开发人员最早引入了这一HTTP头字段,并由IETF在HTTP头字段标准化草案中正式提出。

XFF的工作机制是,每经过一层代理,由代理服务器,把tcp报文中的Source IP,添加到XFF的末尾,多个IP以逗号分隔。这里说的代理是广义的,包括负载均衡(比如阿里云SLB),反向代理(比如Nginx),缓存服务器(比如Squid)。

一方面,XFF提供了向后端业务系统传递用户IP的机制,后端业务系统,可以通过XFF感知到访问者的真实IP。

另一方面,XFF非常易于伪造。很多浏览器插件,可以随机填充XFF字段,如果没有一套正确的机制来处理XFF字段,而盲目地提取XFF中第一个IP作为访问者的IP,就一定会出问题。

前面提到了,来源IP是保留IP的情况,其实大多数是由于业务系统直接以TCP报文中的remote address作为来源IP使用了。而这个IP,一般是企业自己的反向代理服务器。

除此之外,XFF伪造的过程中,IP地址是随机生成的,可能会出线保留IP,非法IP,有少数情况可能会出现“未启用IP”,也就是说这个IP已经分配给特定的运营商,但是运营商还没有添加这个IP的路由,这个IP无法被外界访问,也不会访问任何人。

这些IP是动态变化的,据老高说,只有分析BGP数据的时候,才能看到哪些IP是没有被启用的。

业务系统获取来源IP的正确姿势

下面是一个简单的示意图,简单地把整个访问链路划分成可信区域和不可信区域。

可信区域,就是平台自己,或者友商建立的系统,可以保证从这些系统中获取并传递的数据是真实的、可信的。

获取来源IP的正确方式,是提取并记录本次请求首次进入可信区域时的remote address。不论这个IP是不是代理。

XFF伪造的情况其实非常普遍,也陆续地出现了一些替代方案,我司目前使用的,是设置一个专用的字段来传递这个IP,不会和XFF相覆盖。

此外,某些CDN服务商,会有自己定制化的Header字段,情况比较多,建议结合具体的情况来决定如何获取用户的来源IP。

比如,之前遇到一个客户,使用了阿里云的SLB负载均衡,SLB会给每一个请求都加上X-Forwarded-For字段,他们自己的反向代理又加一次。那么其实只要获取XFF中倒数第三个IP,作为来源IP即可。

一种参考方式如下:

在反向代理(Nginx)上配置,增加Real-IP字段:

业务系统中,获取来源IP的代码如下(Java示例):

这个问题实在是简单到爆炸,懂技术的同学看到,肯定会喷我,居然写这种没水平的文章。

但是呢,作为一个数据分析师,看着每天系统里辣么多保留IP,非法IP传进来,真的很憋屈。体谅下咯~

而且,每每看别人说攻击溯源….我满脑子想的都是:你连获取到的IP是不是真的你都不知道,你在追溯个啥?

By the way,欢迎有兴趣深入研究IP地址的童鞋一起交流,没准能带你跟老高一块儿喝羊汤。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-07-25,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 FreeBuf 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 关于保留IP
  • 聊聊XFF
  • 业务系统获取来源IP的正确姿势
相关产品与服务
负载均衡
负载均衡(Cloud Load Balancer,CLB)提供安全快捷的流量分发服务,访问流量经由 CLB 可以自动分配到云中的多台后端服务器上,扩展系统的服务能力并消除单点故障。负载均衡支持亿级连接和千万级并发,可轻松应对大流量访问,满足业务需求。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档