前言

 

坦白讲，没想好怎样的开头。辗转三年过去了。一切已经变化了许多，一切似乎从没有改变。

 

前段时间调研了一次代理相关的知识，简单整理一下分享之。如有错误，欢迎指正。

涉及

Proxy IP应用

原理／层级wireshark抓包分析

HTTP head： X-Forwarded-For/ Proxy-Connection/伪造  X-Forwarded-For/

以及常见的识别手段等几个方面。 

应用

 

Web 代理(proxy)服务器是网络的中间实体。代理位于客户端和服务器之间,扮演 “中间人”的角色,在各端点之间来回传送 HTTP 报文。本章介绍了所有与 HTTP 代理服务器有关的内容,为代理特性提供的特殊支持,以及使用代理服务器时会遇

到的一些棘手的问题。   －引用自《HTTP权威指南》

 

代理的应用想必大家都很熟悉了，不再过多的描述，简单上图达意。

1:FQ

 

2:ANONYMOUS

 

3:“提升网速”

哈，这个不说大家也明白，以前在学校宿舍里的小伙伴打游戏经常用，各种联通跨电信等等（OK，不发ad～）

  当然这个非普通的HTTP代理可以做到的。

4:xxxx

(前段时间一个词语叫做“不可描述”嗯，大家都懂得撒 :-)

 

 

当然代理还有很多功能，比如：局域网上网管理，好多年前的“绿@坝计划”

 

代理原理

这里要说明的是WEB代理区别于网关：

代理连接的是两个或多个使用相同协议的应用程序,而网关连接的则是 两个或多个使用不同协议的端点。网关扮演的是“协议转换器”的角色,即使客户端和服务器使用的是不同的协议,客户端也可以通过它完成与服务器之间的事务处理。如发邮件时连接HTTP协议与SMTP协议。

 

代理分为两种：普通代理与隧道代理

普通代理：

　　　　　　　　　　　　　　－引用自《HTTP权威指南》 

这里的代理既是服务器,又是客户端

 

隧道代理

 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　－引用自《HTTP权威指南》

 

网关允许某客户端使用隧道之前,可以对其进行代理认证

（为了降低对隧道的滥用,网关应该只为特定的知名端口,比如 HTTPS 的端口 443）

 

比较

 

• 普通代理可以用来承载 HTTP 流量；
• 隧道代理可以用来承载任何 TCP 流量，包括 HTTP 和 HTTPS。

 

这里分别拿 赶集的登录页面，58的主站页面做简单的测试。

 

 

WireShark出场

捕获HTTP（以58主站为例）

 

捕获TLS（前身是SSL）（以赶集登录为例）

 

 

Follow TCP Steam

可以看出赶集用的是verisign的证书

WireShark很是强大，在各个平台上都有。网上的范例也不少，抓包的好助手之一。

 

1. Frame:   物理层－数据帧

2. Ethernet II: 数据链路层以太网帧头部信息

3. Internet Protocol Version   IP包 头部信息

4. Transmission Control Protocol:  传输层的数据段头部信息，如上图的TCP

5. Hypertext Transfer Protocol:  应用层的信息，如上图中的HTTP协议

既然说到这里，那么就复习一下三次握手吧。

（－。－ ～～）

                                      

OK，简单图示回顾一下，  四次挥手这里就不再展开了。

另外 梳理一下

wireshark过滤用法

1:ip.addr/src/dst   用来过滤目标ip及来源ip

2:port

    tcp.port eq 2016 or udp.port eq 2016

    tcp.dstport == 2016    tcp.srcport == 2016

    tcp.port >= 1 and tcp.port <= 2016

3:常用协议支持 非

    Tcp udp arp icmp http smtp ftp dns msnms ip ssl oicq bootp

4:过滤MAC

。

。

。

等等，还有很多，具体可以看官方的，很强大的说。

 

 

 

咦，好像跑的偏了，言归正传，继续回到本文的话题继续谈论一下代理IP HTTP Head相关的

层次对比

 

 

 

这里简单做的一个表格汇总，显然，高匿的代理IP最具挑战，也是最常用的。

 Http Head

 

• Http 常见的Head 和识别IP相关的有如下几个，其中只有REMOTE_ADDR 这个字段是可靠的。其余的字段都是可以伪造的。因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接。
• 由于只能识别上一层的REMOTE_ADDR 字段，对于多层代理的情况下还是比较麻烦的。如下图：

 

 

• REMOTE_ADDR

• X-Forwarded-For

• X-Real-IP

• Proxy-Connection

简单讨论一下-Forwarded-For

 

 

https://en.wikipedia.org/wiki/X-Forwarded-For

https://tools.ietf.org/html/rfc7239

The X-Forwarded-For (XFF) HTTP header field was a common method for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. As of 2014 RFC 7239 standardized a new Forwarded header with similar purpose but more features compared to XFF.[1] An example of a Forwarded header syntax:

Forwarded: for=192.0.2.60; proto=http; by=203.0.113.43

简单理解就是一个后出来一个非标准但被业内默认常用的一个用来识别proxy的一个http haed。

 也就是说 如果在直连的情况下是不会存在这个 参数的

当配置了反向代理 如 nginx(关于nginx，

网上有很多参考，自己也摘录过一些http://www.cnblogs.com/wenthink/p/nginxsetting.html)

• 测试地址：
• http://wenthink.com/headdemo

简单伪造 ：curl http://wenthink.com/headdemo -H 'X-Forwarded-For: 192.168.8.8' -H 'X-Real-IP: 192.168.8.8'

 

Proxy-Connection

 

 

 

 

这个字段同样也是常见的非标准要求字段，简而言之，有了这个字段可以判定为代理IP的可能性极大。

做一个简单的配置代理IP 这里不做展示

再次请出Wireshark

 

 

好吧 mask 有点儿多，其实就是验证下 多了一个Proxy—Connection这个请求头。

 

识别

那么对于代理IP的识别又是怎样的呢？

网上也有很多通用的说法

• 反向探测扫描IP是不是开通了80,8080等代理服务器经常开通的端口，显然一个普通的用户IP不太可能开通如上的端口。
• HTTP头部的X_Forwarded_For：开通了HTTP代理的IP可以通过此法来识别是不是代理IP；如果带有XFF信息，该IP是代理IP无疑。
• Keep-alive报文：如果带有Proxy-Connection的Keep-alive报文，该IP毫无疑问是代理IP。
• 查看IP上端口：如果一个IP有的端口大于10000，那么该IP大多也存在问题，普通的家庭IP开这么大的端口几乎是不可能的。

常见的方式类型及方式：HTTP TCP UDP ／ Ping,telnet,nmap ,socket

 

 

这里简单画一个基本的流程图 

 

OK

简单粗浅分析先到这里吧，后期或许继续补充，或许不再就这方面展开。

计划陆续写一些其他的。

参考资料:

《HTTP权威指南》

https://en.wikipedia.org/wiki/List_of_HTTP_header_fields

以及各路网友总结的这方面相关资料。

如果你觉得本文对您有所帮助,请点击一下推荐,感谢您的阅读!!

ps：前两天园子里博客打赏挺的，我试试看看有没有人可以赞助一杯酸奶 ^_^