对TCP连接被重置解决方案的探究

分类: 网络与安全

对TCP连接被重置解决方案的探究——跨过GFW通向自由网络的可行途径

2010年05月25日 星期二 上午 00:19

这个标题有点长——其实开始只想写破折号之前的部分,因为这种技术文章说的隐晦一点没有坏处,但又担心大家不明白是怎么回事,硬着头皮还是补上了后面的部分。

中 国的网络环境很复杂,同时中国也是对互联网高度控制的国家之一,当然仅限于大陆。而控制中国网民自由上网的网络海关正是大名鼎鼎的GFW(Great Fire Wall,长城防火墙),GFW的工作原理就是重置TCP连接,那么在此就不得不提一下TCP协议三次握手的简单原理。

根 据TCP协议的规定,用户和服务器建立连接需要三次握手:第一次握手用户向服务器发送SYN数据包发出请求(SYN, x:0),第二次握手服务器向用户发送SYN/ACK数据包发出回应(SYN/ACK, y:x+1),第三次握手用户向服务器发送ACK数据包发出确认(ACK, x+1:y+1),至此一个TCP连接建立成功。其中x为用户向服务器发送的序列号,y为服务器向用户发送的序列号。

现在 我们来谈谈GFW的工作原理。GFW负责监控全国的TCP连接,当发现敏感词时就会介入,将服务器发回的SYN/ACK包改成SYN/ACK, Y:0,这代表TCP连接被重置,用户便主动放弃了连接,提示连接失败。可以看出,其实GFW就是在欺骗用户,让用户误认为服务器拒绝连接,而主动放弃继 续与服务器连接。

因为GFW是工作在TCP协议层上,这看似坚不可破,可我们不应忽略的是,检测全国TCP连接可不是一个 简单的工作,即便是上千台的分布式计算机也未必有能力逐个TCP连接监控,那么GFW是如何做到的呢?很简单,GFW只在连接发起时监测第一个TCP连 接,这样就可大大提高GWF的工作性能。但就是这样一个提供性能的方法却给GFW留下了一个致命的漏洞,我今天探讨的方案也正是建立在这个漏洞基础上。

首 先我们正常发送SYN数据包到服务器进行第一次握手,之后服务器发回SYN/ACK到用户进行第二次握手,接下来,用户继续发送第一次握手时的SYN数据 包,此时GFW根据TCP协议规则认为本次TCP连接结束,停止了对本次TCP连接用户的监视,而服务器知道TCP连接尚未建立怎么会结束,所以忽略了这 个数据包而不受影响。但我们至此只完成了工作的一半,因为GFW是双向监视的,服务器依然被GFW监控,如果服务器能发回一个连接重置的数据包,GFW也 会停止对服务器的监视。虽说来容易,可服务器并不收用户控制,如何才能让服务器随用户的意愿发送连接重置数据包呢?根据TCP协议规则,如果用户发回的数 据包有错误,服务器就会发回连接重置数据包,前文提到,第三次握手时用户发送的ACK数据包应该是ACK: x+1:y+1,可如果用户发送的是ACK: x+1:y,那么服务器自然会发生连接重置数据包。当GFW收到这个包时,认为服务器也重置了此连接也就不再监视服务器了。但这个连接重置包被用户接收后 不能主动放弃连接,这样就需要用户忽略这个重置数据包,不过用户这边我们说了算,怎么搞都行。至此,GFW不再监视本次TCP的用户和服务器,双方可以自 由通信。

下面我再总结下这个TCP连接的过程:

用户-[SYN, x:0]->GFW-[SYN, x:0]->服务器{第一次握手}

用户<-[SYN/ACK, y:x+1]-GFW<-[SYN/ACK, y:x+1]-服务器{第二次握手}

用户-[RST, x:0]->GFW[认为用户TCP连接结束]-[RST, x:0]->服务器{忽略}

用户-[ACK, x+1:y]->GFW[停止监视用户]-[ACK, x+1:y]->服务器{判断是坏包}

用户{忽略}<-[RST, y:0]-GFW[认为服务器重置连接]<-[RST, y:0]-服务器{重置连接}

用户-[ACK, x+1:y+1]->GFW[停止监视服务器]-[ACK, x+1,y+1]->服务器{第三次握手}

这样,一个三次握手的过程被我们改成了六次握手,成功骗过了GFW,好戏正式开始了。

下 面再来谈谈GFW的一些事吧。GFW并不是我们想象中的那么强大,相反它漏洞百出,非常脆弱。因为GFW是基于分布式的,所以修补漏洞十分困难,如果 GFW更改监视规则而监视所有TCP数据包则会使性能大大降低。另外GFW会记录下访问过敏感信息的ip一段时间,使该ip无法继续与相应服务器连接,那 么这个记录ip的缓存区就一定有上限,自然就有溢出的可能,如果大量ip访问敏感信息,GFW就会因为这个缓存区溢出而无法检视其他的TCP。没错,这个 其实就是DDoS,2010年1月3日前后的“解封”也听说是与北京GFW被DDoS有关。听说GFW有学生参与,而这些筑墙的哈工大和北邮的同学们能力 不一,导致GFW模块质量参差不齐,这也是GFW存在漏洞的重要因素之一。

但最终技术无罪,只是技术被政治所利用才是最大的悲哀。其实不止是中国,美国用来做网络深度检测的CNCI,预算300亿美元,是GWF的多少倍。区别只在于中国的执事者做事太笨拙而又没有底线,导致普通人也能看出破绽。

最后,对这个方案的探索体现了人们对技术的热衷,而对FQ的研究则体现了人们对事实与自由的追求。而不论是从对技术热衷的角度还是从对事实与自由追求的角度,我都很愿意成为他们中的一员。

参考文献:

[1]深入理解GFW,http://gfwrev.blogspot.com/2010/03/gfw.html (墙外)

[2] “西厢计划”原理小解,http://blog.youxu.info/2010/03/14/west-chamber/

[3]简述TCP三次握手过程,并说明为什么要3次握手,http://hi.baidu.com/it_hawk/blog/item/d053ab346830783e5ab5f54e.html

时间: 2024-07-28 19:50:16

对TCP连接被重置解决方案的探究的相关文章

解决不对称流量经过JUNIPER防火墙,tcp连接重置丢失问题

背景:公司网络增加一台JUNIPER防火墙,用于外网网关使用,其实配置上网配置很简单,配置完成后,外网连接测试也都正常,但在特殊的测试环境中会出现一种情况,该环境如图所示: 现象:当PC机的网关指定为防火墙的内网接口后(而不是核心交换机地址),当pc在telnet或者ssh连接10.10.2.*网段的服务器(网关在核心交换机上)等时,tcp连接均会在20s后重置.我的环境中其实存在一些问题的,就是流经防火墙的流量并不对称,其中pc→服务器的流量经过防火墙,而服务器→pc的流量不经过防火墙,造成的

TCP连接TIME-WAIT解决方案

问题根源: 为什么会产生time-wait? 当客户端与服务器之间进行四次断开时,当客户端接收 到服务器端发送过来的断开确认报文后,会发送最后一次 ACK报文,发送之后客户端会进入time-wait状态,这个过 成会持续一分钟,用来完成接收剩余所有从服务器端发送 过来的数据[由于网络延迟等原因导致数据延迟达到], 同时也可以确自己发送的最后一个ACK断开确认报文能被 服务器端收到! time-wait状态的危害: 1 time-wait状态会占据一定量的内存资源,虽然很少但 是如果这种连接在一个

为什么Google不返回我的搜索结果(无状态TCP连接重置)

1.Great Firewall 它的存在会对境外涉及敏感内容的网站.IP地址.关键词.网址等进行过滤 结果就是:国内网络用户无法访问某些国外网站,国外网络用户也无法访问某些国内网站,其中有可以分成2类 永久性无法访问 暂时性无法访问 2.主要技术 域名劫持 特定IP地址封锁 特定IP地址端口封锁 无状态TCP连接重置 特定TLS证书阻断 明文HTTP协议关键字过滤阻断 对破网软件的反制 本文主要介绍无状态TCP连接重置 3.DNS小测试 引入:客户端如何获得Baidu, Bing, Googl

TCP连接的状态详解以及故障排查

转载自CSDN博客:http://blog.csdn.net/hguisu/article/details/38700899 TCP状态 TCP状态迁移路线图 TCP连接建立三次握手 TCP连接的终止四次握手释放 同时打开 同时关闭 TCP通信中服务器处理客户端意外断开 Linux错误信息errno列表 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 了解TCP之前,先了解几个命令:   linux查看tcp的状态命令: 1).netst

服务器后台TCP连接存活问题

0. 背景 公司的服务器后台部署在某一个地方,接入的是用户的APP,而该地方的网络信号较差,导致了服务器后台在运行一段时间后用户无法接入,那边的同事反馈使用netstat查看系统,存在较多的TCP连接. 1. 问题分析 首先在公司内部测试服务器上部署,使用LoadRunner做压力测试,能正常运行,然后那边的同事反馈该地方信号较差.考虑到接入的问题,有可能接入进程的FD资源耗尽,导致accept失败.推论的依据是对于TCP连接来说,如果客户端那边由于一些异常情况导致断网而未能向服务器发起FIN关

转载:TCP连接的状态详解以及故障排查

FROM:http://blog.csdn.net/hguisu/article/details/38700899 该博文的条理清晰,步骤明确,故复制到这个博文中收藏,若文章作者看到且觉得不能装载,麻烦请告知,谢谢. 我们通过了解TCP各个状态,可以排除和定位网络或系统故障时大有帮助.(总结网络上的内容) 1.TCP状态 linux查看tcp的状态命令: 1).netstat -nat  查看TCP各个状态的数量 2).lsof  -i:port  可以检测到打开套接字的状况 3).  sar

通过UDP建立TCP连接

解释 通过UDP广播查询服务器的IP地址,然后再建立TCP点对点连接. 应用场景 在服务器IP未知时,并且已知服务器与客户端明确在一个局域网或者允许组播的子网下. 通过UDP发现服务器地址然后再进行TCP连接. (PS:万维网很多路由器对组播进行了限制,所以不能通过UDP报文在万维网上进行服务器查询) 主要问题 Android真机和模拟器对组播处理不同 Android不同系统版本对组播处理不同 不同网络对组播有限制,如部分路由网络限制UDP报文 简单实现 传统组播方式,通过255.255.255

TCP连接的建立与关闭

TCP是主机对主机层的传输控制协议:建立连接要三个握手,断开连接要四次挥手. 位码即TCP标志位,有6种标示:SYN(synchronous建立联机),ACK(acknowledgement 确认),PSH(push传送),FIN(finish结束),RST(reset重置),URG(urgent紧急),Sequence number(顺序号码),Acknowledge number(确认号码) 各个状态的意义如下: LISTEN - 侦听来自远方TCP端口的连接请求: SYN-SENT -在发

socket使用TCP协议时,send、recv函数解析以及TCP连接关闭的问题

Tcp协议本身是可靠的,并不等于应用程序用tcp发送数据就一定是可靠的.不管是否阻塞,send发送的大小,并不代表对端recv到多少的数据. 在阻塞模式下, send函数的过程是将应用程序请求发送的数据拷贝到发送缓存中发送并得到确认后再返回.但由于发送缓存的存在,表现为:如果发送缓存大小比请求发送的大小要大,那么send函数立即返回,同时向网络中发送数据;否则,send向网络发送缓存中不能容纳的那部分数据,并等待对端确认后再返回(接收端只要将数据收到接收缓存中,就会确认,并不一定要等待应用程序调