移动端 | 加入收藏 | 设为首页 | 我要投稿 | 赞助本站 | RSS
 

freefq.comfree——免费、自由fq——翻墙

困在墙内,请发邮件到freefqcom#gmail.com获得最新免费翻墙方法!
您当前的位置:首页 > 网络安全

缓解假墙伪墙攻击勒索的多种技术手段

时间:2021-10-25  来源:  作者: 条评论
原题:301海外跳转原理解析兼谈缓解假墙伪墙攻击勒索的多种技术手段(一)

我们知道,墙封锁一个网站的手段有DNS污染、IP封锁、TCP Reset(TCP连接重置)等手段。而一个网站一旦被墙,一般情况下是无法直接通过301(或302)跳转到其他网站的。如果只是IP被封还好说,换IP通常能解决问题。但如果是根据域名关键字进行的TCP Reset,这时候不管怎么换IP(除非是国内IP)都无法解除封锁,当然也不可能进行301跳转(浏览器在收到HTTP服务器的301跳转Response之前TCP连接就已经被墙Reset而断开了,浏览器根本收不到HTTP服务器的任何Response)。而DNS污染的话自然更不用多说,只能换域名了,301跳转更不可能做到。然而,现在出现了很多号称可以解决域名被墙的服务,可以在网站被墙后通过301跳转到新的网站上。经过测试,还真能做到绕过墙的TCP Reset封锁,而这些服务的IP却都在海外(并非是使用了国内IP避免被墙的原因),而客户端只需要一个正常的浏览器即可(即客户端并不需要开启科学上网)。那么它们是怎么做到的呢?xDi免费翻墙网

要解释清楚其中的技术原理,还得回到2010年的西厢计划。很早就经常科学上网的同学们应该都对西厢计划并不陌生,它是一个只需要运行在客户端就能绕过很多封锁访问目标网站的工具,解决TCP Reset的原理是对本地的TCP/IP协议进行修改,在不伤害客户端和服务器之间的TCP连接的前提下让墙误以为TCP连接已经断开或者无法正确跟踪到TCP连接。之后出现的INTANG项目同样是这个想法的延续。xDi免费翻墙网

不过,不管是西厢计划还是INTANG,都是运行在客户端上的工具,理论上只在服务器上运行无法起到效果,经过测试也能看到实际和理论相符。那么有没有一种工具可以在只服务器上运行,修改TCP/IP协议从而绕过封锁的工具呢?这方面同样有团队做了研究,研究的成果就是Geneva项目GFW Report也对其做了详细介绍。在这篇文章中,列举了6种可以绕过TCP Reset的规则,6种规则都可以在只客户端部署生效(这时候服务器并不需要运行Geneva),而前4种可以在只服务器部署生效(这时候客户端并不需要运行Geneva)。不过Geneva的官方Github中只收录了客户端的规则,文章中的服务器规则并没有被收录在Geneva的官方Github中。而且文章中的策略3只给出了客户端的规则,遗漏了服务器端的规则。经过阅读Geneva的规则介绍和策略3的描述,我已经重新还原了策略3的服务器规则,重新收录了4种服务器规则到我自己的Github Fork中。经过本地环境的模拟加上tcpdump抓包观察测试,看到还原的策略3服务器规则和文章中描述的行为一致,可以认为就是策略3本来的服务器规则。但是,在之后的真实环境的测试中发现这4种服务器策略全都失效了,墙依然对TCP进行了Reset。经过抓包看到服务器的行为确实和文章中描述一致,所以可以确认并非是由于Geneva没有正常工作导致的,而是墙已经为了应对这4种策略进行进化了。所以,墙并不是一成不变的,而是会进化的,那我们又该怎么办呢?xDi免费翻墙网

讲到这里,就不得不提另一个策略发现工具SymTCP了。虽然现有的4中策略已经失效,但并不代表我们不能发现新的策略。而SymTCP就是新策略发现工具,通过自动学习可以自动发现新的策略绕过墙的TCP Reset。之后我们就能把新的策略转换为Geneva的规则格式进行使用了。不过,这样的话我们就会陷入到和墙的无休止争斗中,不断发现新策略,而墙则不断封锁新策略。而且规则的转换也是一个麻烦事,暂时还没有工具可以自动从SymTCP的规则转换为Geneva的规则,需要人工转换。并且需要修改SymTCP使其不仅可以发现客户端规则同样也能发现服务器端规则。xDi免费翻墙网

那么,有没有一种一劳永逸的方法,使墙再怎么进化也无法避免这种策略的影响,而且这种策略只需要运行在服务器上,从而绕过封锁呢?在下结论之前,我们需要来研究一下一个正常的HTTP协议通讯是怎么进行的: 1、浏览器发起TCP连接,经过3步(次)握手建立和服务器的TCP连接。 2、浏览器发送HTTP Request。 3、服务器收到Request,发送HTTP Response。 而墙通常在看到浏览器发送的HTTP Request中包含关键字就会进行TCP Reset。讲到这里,聪明的同学或许已经想到了:如果服务器不等HTTP Request,而在TCP连接建立后立即发送HTTP Response,在墙进行TCP Reset之前就将Response送到浏览器进行抢答,是不是就能绕过TCP Reset了?而且还能无视之后墙的进化(因为浏览器的请求根本还没有经过墙)?说干就干,由于抢答模式不符合HTTP规范,所以常见的HTTP服务器无法实现抢答模式,所以让我们写个Python小程序来测试一下:xDi免费翻墙网

import socket
import threading
import time


def main():
    serv_sock = socket.socket()
    serv_sock.bind(('0.0.0.0', 80))
    serv_sock.listen(50)
    while True:
        cli_sock, _ = serv_sock.accept()

        # 关闭Nagle算法,立即发送数据
        cli_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

        cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
            b'''Content-Type: text/html\r\n'''
            b'''Content-Length: 0\r\n'''
            b'''Connection: close\r\n'''
            b'''Location: https://www.microsoft.com/\r\n\r\n''')

        def wait_second():
            time.sleep(1)  # 等待1秒钟,确保数据发送完毕
            cli_sock.close()

        threading.Thread(target=wait_second).start()


if __name__ == '__main__':
    main()

写完了来测试一下,发现依旧被TCP Reset了。那么,问题出在哪里?让我们重新回到上述HTTP协议通讯的3个步骤中的第1步:TCP的3步握手:xDi免费翻墙网

TCP三步握手+数据xDi免费翻墙网

从TCP的3步握手中,我们可以看到第3步中客户端发送了ACK就已经完成了TCP连接的建立,这时候客户端并不需要再等服务器的回复就能立即发送数据。也就是说,浏览器会在发送ACK后立即发送HTTP Request,ACK和HTTP Request几乎是同时发出的。而服务器在收到浏览器的ACK后基本也就代表着已经收到了HTTP Request了,抢答失败!xDi免费翻墙网

那么,有没有办法让浏览器在TCP连接建立后延迟发送HTTP Request,而又不改动客户端行为呢?讲到这里,对TCP协议比较熟悉的同学或许已经想到了,那就是TCP window size。而通过调用setsockopt()就能修改TCP window size。让我们来修改一下Python小程序,把window size改为1再进行测试(TCP连接建立完成后,客户端只能发送1个字节,等待服务器的确认后才能继续发送更多的数据):xDi免费翻墙网

import socket
import threading
import time


def main():
    serv_sock = socket.socket()
    serv_sock.bind(('0.0.0.0', 80))
    serv_sock.listen(50)
    while True:
        cli_sock, _ = serv_sock.accept()

        # 设置TCP window size为1
        cli_sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1)

        # 关闭Nagle算法,立即发送数据
        cli_sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

        cli_sock.sendall(b'''HTTP/1.1 302 Moved Temporarily\r\n'''
            b'''Content-Type: text/html\r\n'''
            b'''Content-Length: 0\r\n'''
            b'''Connection: close\r\n'''
            b'''Location: https://www.microsoft.com/\r\n\r\n''')

        def wait_second():
            time.sleep(1)  # 等待1秒钟,确保数据发送完毕
            cli_sock.close()

        threading.Thread(target=wait_second).start()


if __name__ == '__main__':
    main()

改完测试,发现仍旧被TCP Reset了。什么原因?通过抓包,我们看到对TCP window size的修改并没有生效,window size依旧很大。在查阅了Linux man page后我们看到关于SO_RCVBUF有这么一段话:xDi免费翻墙网

The minimum (doubled) value for this option is 256.xDi免费翻墙网

这也就意味着即使我们通过setsockopt()SO_RCVBUF设置为1,Linux内核也会将其作为256处理。而Linux man page中也对SO_RCVBUFFORCE做了说明:只能突破最大值的限制(but the rmem_max limit can be overridden),但不能突破最小值的限制。而256字节基本就可以容纳整个HTTP Request。看来通过setsockopt()行不通(不管SO_RCVBUF还是SO_RCVBUFFORCE都行不通),我们得找别的方法。xDi免费翻墙网

讲到这里,我们很自然地又想到了Geneva:上述Geneva的策略2中服务器规则正是利用了TCP window size做到的四字节分割(设置window size为4)。这样,就绕过了setsockopt()的限制,直接对TCP数据包进行修改了。xDi免费翻墙网

在我们把四字节分割法部署到服务器运行Geneva后,再结合上述Python小程序,经过测试我们发现已经成功绕过了TCP Reset,浏览器跳转到了微软网站。我们终于成功了!xDi免费翻墙网

然而,在浏览器第二次访问服务器时发现依然被TCP Reset了。不过,这已经影响不到301跳转(上述Python小程序还是302跳转,需要301的同学自行修改)了,301跳转的话浏览器已经被重定向到新的网站了,不会再次访问这个服务器(需要保证新旧网站不能使用相同IP),但这并不妨碍我们继续探究一下为什么第二次访问会被TCP Reset:通过抓包我们看到,第一次访问时浏览器虽然在第一个附带用户数据的数据包中只发送了4个字节,但后续会将剩余的整个HTTP Request通过一个数据包发送到服务器导致TCP Reset。而墙是有审查残留的,一段时间(几分钟)内不管是否出现关键字,对源IP和目标IP之间的TCP连接会进行无差别的Reset。所以在之后的这段审查残留时间内,只要TCP连接建立就会被Reset,抢答模式无法起到作用。xDi免费翻墙网

知道了原因我们就能采取对策了,我们知道客户端是因为收到了服务器确认数据包中的TCP window size很大,所以才能一次性把剩余的Request发送完毕,所以需要对后续的TCP window size做同样的修改,保证客户端看到的window size一直处于比较小的水平:通过对TCP协议的了解,我们知道连接建立时的window size是通过SYN+ACK包确定的,而后续的window size是通过ACK包确定的。所以,我们对规则2做少许的修改就能做到对后续window size的修改:xDi免费翻墙网

[TCP:flags:A]-tamper{TCP:window:replace:4}-|xDi免费翻墙网

在服务器上我们同时运行规则2和上述修改后的规则(需要开2个Geneva进程,注意第2个进程需要在命令行中指定--in-queue-num和--out-queue-num避免和第1个冲突),我们终于能稳定地运行上述抢答模式,再也不会被TCP Reset了。xDi免费翻墙网

实际上我们可以将2条规则中的window size都设置得更小一些,甚至设置为0,避免客户端发送任何数据(实际上由于window size探测机制的原因,客户端仍旧会以极慢的速度一个字节一个字节地发送数据,不过不影响我们的抢答模式):xDi免费翻墙网

[TCP:flags:SA]-tamper{TCP:window:replace:0}-|
[TCP:flags:A]-tamper{TCP:window:replace:0}-|

至此,HTTP的抢答模式就基本完成了。不过,由于Geneva和上述小程序都是用Python编写的(甚至都没有使用asyncio),性能会比较差一些。Geneva会自己添加iptables的NFQUEUE规则,不过规则太过于宽松,导致不需要处理的数据包也会经过Geneva。所以大家可以在启动Geneva后手动删除这些规则,自行添加更精确的规则(只处理SYN+ACK和ACK)。不过经过我的测试,即使使用精确的iptables规则也差不多只能利用20Mbps左右的带宽。如果希望有更高的性能,可以使用C/C++(结合libev,或asio,或直接epoll;或者使用golang、rust等)结合libnetfilter_queue,利用iptables的NFQUEUE来完成,可以跑满千兆带宽。其实Geneva的底层用的也是libnetfilter_queue和NFQUEUE。由于本系列只做概念验证,而且因为篇幅的限制(本文已经很长了),在此就不展开C/C++的实现了,感兴趣的同学可以和我联系,如果感兴趣的同学比较多的话我就再新开一个系列讲一下这方面的内容。另外需要注意的是,Geneva的编译环境为Python 3.6,使用Debian 10自带的Python 3.8/3.9会出现各种莫名其妙的问题,建议大家还是从Python官网下载Python 3.6的源码进行编译使用GenevaxDi免费翻墙网

在解决了HTTP的TCP Reset问题后,我们还需要解决HTTPS的TCP Reset。而HTTPS由于需要完成TLS握手才能发送HTTP Response,所以抢答模式似乎无法应用于HTTPS。在下一篇中,我会介绍几个绕过HTTPS的TCP Reset方法。敬请期待。xDi免费翻墙网

如果对本系列话题感兴趣的同学也可以联系我。我的联系方式为:xDi免费翻墙网
1、Email: lehui99#gmail.comxDi免费翻墙网
2、Twitter: @davidsky2012xDi免费翻墙网
3、TG: @davidsky2000xDi免费翻墙网
4、本系列Github: lehui99/articlesxDi免费翻墙网

BTW,本来想将此文首发于hostloc的(因为hostloc上站长朋友比较多,而本系列是帮助站长解决TCP Reset问题的),不过由于hostloc需要邀请码,一直没有注册成功,而淘宝购买hostloc邀请码曾经有过不愉快的经历,遂作罢。xDi免费翻墙网

最后,本文欢迎转载,不过转载时还请保留原文链接,因为之后我还会对本文进行完善(如错误修正、内容补充等)。xDi免费翻墙网

来顶一下
返回首页
返回首页
欢迎评论:免登录,输入验证码即可匿名评论 共有条评论
用户名: 密码:
验证码: 匿名发表

推荐资讯

Dubai VPN - Free, Fast & Secure VPN下载
Dubai VPN - Free, Fa
Free VPN - limitless secure hotspot proxy vpnify
Free VPN - limitless
LittleVPN免注册无限流量永久免费VPN
LittleVPN免注册无限流
高速免费VPN Бесплатно ВПН прокси
高速免费VPN Бесп
相关文章
栏目更新
栏目热门
墙外新闻
读者文摘

你可以访问真正的互联网了。You can access the real Internet.

管理员精中特别提醒:本网站域名、主机和管理员都在美国,且本网站内容仅为非中国大陆网友服务。禁止中国大陆网友浏览本站!若中国大陆网友因错误操作打开本站网页,请立即关闭!中国大陆网友浏览本网站存在法律风险,恳请立即关闭本站所有页面!对于您因浏览本站所遭遇的法律问题、安全问题和其他所有问题,本站均无法负责也概不负责。

特别警告:本站推荐各种免费科学上网软件、app和方法,不建议各位网友购买收费账号或服务。若您因付费购买而遭遇骗局,没有得到想要的服务,请把苦水往自己肚子里咽,本站无法承担也概不承担任何责任!

本站严正声明:各位翻墙的网友切勿将本站介绍的翻墙方法运用于违反当地法律法规的活动,本站对网友的遵纪守法行为表示支持,对网友的违法犯罪行为表示反对!

网站管理员定居美国,因此本站所推荐的翻墙软件及翻墙方法都未经测试,发布仅供网友测试和参考,但你懂的——翻墙软件或方法随时有可能失效,因此本站信息具有极强时效性,想要更多有效免费翻墙方法敬请阅读本站最新信息,建议收藏本站!本站为纯粹技术网站,支持科学与民主,支持宗教信仰自由,反对恐怖主义、邪教、伪科学与专制,不支持或反对任何极端主义的政治观点或宗教信仰。有注明出处的信息均为转载文章,转载信息仅供参考,并不表明本站支持其观点或行为。未注明出处的信息为本站原创,转载时也请注明来自本站。

鉴于各种免费翻墙软件甚至是收费翻墙软件可能存在的安全风险及个人隐私泄漏可能,本站提醒各位网友做好各方面的安全防护措施!本站无法对推荐的翻墙软件、应用或服务等进行全面而严格的安全测试,因此无法对其安全性做保证,无法对您因为安全问题或隐私泄漏等问题造成的任何损失承担任何责任!

S. Grand Ave.,Suite 3910,Los Angeles,CA 90071

知识共享许可协议
本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。