那些伪造IP的软件都是什么原理

很多人可能都有过这个念头， 如何伪装客户端IP？ 还有那些投票刷票的工具是怎么个原理?

先复习下TCP

要明白伪装IP的原理，首先要回顾一下TCP的三次握手。 总所周知在链接初始化的阶段， 需要一次三次握手来建立链接， 之后客户端和服务端会依据初始的这个IP地址来通信。

从这个角度上来说， 想真正的伪装一个IP地址是不可能的。

因为即使从链路层把IP地址改了， 后续发出去的请求也回不来， 除非你只是想用来作为DDOS攻击，要不没什么意义。

所以要另辟蹊径。

代理转发规则

用过代理吧？ 不管是V**，还是局域网代理， 都是通过代理服务器转发客户端的消息到服务端。

这里就引出主角，一个在 Header里的字段 X-Forwarded-For， 很多地方简称 XFF。

XFF不是一个标准的HTTP协议， 但是它被广泛接受用作于标识代理转发的规则。

通常一个 XFF字段会像下面这样，

X-Forwarded-For: 127.0.0.1, IP2, ..., IP N

从左到右， 依次记录的是距离服务器距离远的代理服务器的IP。

通过这个字段， 服务端就能知道这个请求是通过哪些代理转发过来的了。

而有些服务端的bug在于， 他们不关心这个请求的原始地址，而只关心最后那个转发给他的 IP N的代理。

正常来说， 应该把三次握手的 IP 作为 Remote IP记录， 以这个为客户端的唯一 IP，这样才是准确的。

实现

说了那么多理论， 下面来看看如何使用这个 XFF字段。 首先我们用 postman 模拟一个 HTTP 请求，看看返回的字段里携带的客户端信息是怎样的。

这里随意找了个服务器发了个模拟请求， 下面的 device字段不仅包含了 IP 地址，也包括了经纬度。

然后我们再人为的添加上 XFF 字段， 看看 device信息变成了什么。

看到了吗， 现在已经变成了一个假的位置。

而且即使这个IP地址明显错误，

服务端也没用校验这个异常。

总结

今天介绍的这个伪造IP的方法， 只是希望做服务端的朋友知道这个bug的存在， 进而避免很多违规的刷单行为。 技术本身没有错， 但如果把技术用在歧途上就不对了。