关于来源IP地址的那些事

本文原创作者：戒贤（RadeBit瑞安全引用）

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

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

关于保留IP

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

原文地址：https://en.wikipedia.org/wiki/Reserved_IP_addresses

保留地址段	地址起始	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是不是代理。

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

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

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

一种参考方式如下：

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

location /{ ... proxy_set_header Real-IP $remote_addr; ...}

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

@SuppressWarnings("unchecked") public static
ClientIps getClientIpAddr(HttpServletRequest
request) { // 获取真实ip String ip = request.get
Header("real-ip"); if (StringUtils.isBlank(ip) ||
("unknown".equalsIgnoreCase(ip.trim()))) { ip
= request.getHeader("remote-host"); } if (Strin
gUtils.isBlank(ip) || ("unknown".equalsIgnoreC
ase(ip.trim()))) { ip = request.getRemoteAddr()
; } ClientIps clientIps = new ClientIps(); clientIp
s.setTrueIp(StringUtils.trimToEmpty(ip));
// 获取代理ip ip = request.getHeader("x-forwar
ded-for"); StringBuilder proxyIps = new StringB
uilder(); if (StringUtils.isNotBlank(ip) && (String
Utils.contains(ip, ","))) { String temp = StringUtil
s.substringBeforeLast(ip, ","); if (StringUtils.isNo
tBlank(temp)) { proxyIps.append("x-forwarded-
for:"); proxyIps.append(temp); proxyIps.appen
d("n"); } }