翻牆網 ATGFW.ORG
Across The Great FireWall, We Can Reach Every Corner In The World.
Latest Post

最新版赛风三使用教程

Written By Ghost Assassin on 2015/04/19 | 19.4.15

赛风三这个多伦多大学公民实验室出品的老牌开源翻墙软件相信很多人都已经非常熟悉了,最近GFW对shadowsocks也加强了干扰(可能是找到了shadowsocks的流量特征,再结合相对固定的VPS IP段进行干扰),我亲自测试发现赛风三表现不错,而且有了重大更新,就特此写一篇教程给大家。

赛风三官网网址: https://s3.amazonaws.com/57wj-4j1q-wa7e/zh/index.html
可以在这里看到赛风所使用的源码和组件,最新版赛风三使用了meek插件(就是Tor团队开发的那个meek插件)和自行开发的ssh混淆插件。

这里可以下载赛风三(美国之音德国之声也提供赛风三下载链接和邮件获取渠道),目前只有win版和android版,下载之后可以右键校验数字签名,如图所示 :
 
这样就表示下载下来的赛风三没有问题

然后打开赛风三,就会自动开始连接服务器,很快就能连接完成,如图所示:
 点击左上角的绿勾按钮就能断开连接,再次点击就能重新连接。连接成功之后,赛风三就会自动在默认浏览器中打开官网(或者是美国之音,德国之声等网页,如果你的赛风三是通过他们的邮箱获取的)。

原先赛风三是固定代理1080SOCKS端口和8080HTTP端口,在运行界面上切换SSH模式和VPN模式以及SSH+模式的,现在赛风三每次启动时都默认选择随机端口,如果要让赛风三作为Tor Browser的前置代理就必须手动指定端口,如图所示(点击运行界面右上方的齿轮按钮,就能看到赛风三的设置):
 
注意看“Local Proxy Ports”一栏,诸位需要手动填写端口号,为了防止端口冲突请不要填<1000的数字(绝大部分协议的默认端口号都小于1000,端口号过小容易发生冲突)。 

还有就是最新版赛风三可以手动选择使用哪个国家的服务器了,如图所示:
 
勾选下方的“Use VPN Mode”可以切换到VPN模式,默认启动的是ssh+模式,最新版没有ssh模式了。

最新版赛风三可以设置前置代理,见图:
 
 注意只能设置支持HTTPS的HTTP代理

最新版赛风三依旧可以实现智能分流(VPN模式不行),看图:
 
勾选之后就能实现智能分流,不代理墙内网站。

右上角的对话按钮点击之后可以反馈信息:

China’s Great Cannon 中国的巨炮(1)

Written By Ghost Assassin on 2015/04/16 | 16.4.15

分类:Bill Marczak, John Scott-Railton, Reports and Briefings

This post describes our analysis of China’s “Great Cannon,” our term for an attack tool that we identify as separate from, but co-located with, the Great Firewall of China. The first known usage of the Great Cannon is in the recent large-scale novel DDoS attack on both GitHub and servers used by GreatFire.org.
这篇论文描述了我们对中国的“巨型加农炮”的分析,我们确认了巨炮是和GFW功能上分离但是分布在同一位置的设备。巨炮的第一次被广为人知的使用是在最近对github和greatfire所使用的服务器的大型DDOS攻击上。

作者:Bill Marczak1,2,3 (Lead), Nicholas Weaver2,3 (Lead), Jakub Dalek,1 Roya Ensafi,4 David Fifield,2 Sarah McKune,1 Arn Rey, John Scott-Railton,1 Ronald Deibert,1 Vern Paxson.2,3

参与者:(1) Citizen Lab, Munk School of Global Affairs, University of Toronto; (2) International Computer Science Institute; (3) University of California, Berkeley; (4) Princeton University(1,公民实验室,多伦多大学;2,国际计算机科学研究所;3,加州伯克利大学;4,普林斯顿大学)

Section 1: Introduction, Key Findings
第一节:介绍,关键发现

On March 16, GreatFire.org observed that servers they had rented to make blocked websites accessible in China were being targeted by a Distributed Denial of Service (DDoS) attack.  On March 26, two GitHub pages run by GreatFire.org also came under the same type of attack.  Both attacks appear targeted at services designed to circumvent Chinese censorship.  A report released by GreatFire.org fingered malicious Javascript returned by Baidu servers as the source of the attack.1  Baidu denied that their servers were compromised.2
在3月16日,greatfire.org观察到他们租用的用来使得被封锁的网页能在中国访问的服务器遭受到了DDOS攻击。在3月26日,两个由greatfire.org运行维护的github页面也遭受了相同类型的攻击。两次攻击都显示出目标是设计目的为规避中国网络审查的服务。一份由greatfire.org发布的报告[1]指出从百度服务器返回的恶意JavaScript脚本是攻击来源。百度否认是服务器的问题[2]。

Several previous technical reports3 have suggested that the Great Firewall of China orchestrated these attacks by injecting malicious Javascript into Baidu connections.  This post describes our analysis of the attack, which we were able to observe until April 8, 2015.
此前有几份报告[3]指出GFW通过向用户与百度建立的连接内注入恶意JS代码以进行攻击。这篇报告描述了我们对于攻击的分析,直到2015年4月8日我们才观察到了这种攻击。

We show that, while the attack infrastructure is co-located with the Great Firewall, the attack was carried out by a separate offensive system, with different capabilities and design, that we term the “Great Cannon.”  The Great Cannon is not simply an extension of the Great Firewall, but a distinct attack tool that hijacks traffic to (or presumably from) individual IP addresses, and can arbitrarily replace unencrypted content as a man-in-the-middle.
我们展示了这样一个事实:进行攻击的设备基础架构是和GFW部署在一起的,但是攻击是由分离的攻击系统实现的,这一系统拥有与GFW不同的设计和能力,我们将之称为“巨型加农炮”。巨炮并不是一个对于GFW的简单扩展,而是一个绑架通向(或来自于)个体IP地址流量的工具,还能够以中间人的身份任意替换未加密的通信内容。

The operational deployment of the Great Cannon represents a significant escalation in state-level information control: the normalization of widespread use of an attack tool to enforce censorship by weaponizing users. Specifically, the Cannon manipulates the traffic of “bystander” systems outside China, silently programming their browsers to create a massive DDoS attack.  While employed for a highly visible attack in this case, the Great Cannon clearly has the capability for use in a manner similar to the NSA’s QUANTUM system,4 affording China the opportunity to deliver exploits targeting any foreign computer that communicates with any China-based website not fully utilizing HTTPS.
巨炮的部署和操作意味着国家级信息控制系统的显著升级:通过武器化用户来强化审查这一攻击工具的攻击手段会逐渐变得普遍和正常化。
特别之处在于巨炮通过旁观者系统操纵中国以外的流量,静静的通过程序使得用户们的浏览器制造大量的DDOS攻击。在这一事件中,被用于发起一个高可见性攻击的巨炮很明显拥有和NSA的量子系统[4]类似的能力,这一能力给了中国对任何与服务器在中国的网站进行非完全HTTPS通信的外国计算机进行操纵的机会。

Report Structure
报告结构:

We organize our Report as follows:
我们这样组织报告:

Section 2 locates and characterizes the Great Cannon as a separate system;
第二节:定位并指出巨炮是一个分离的系统这一特征
Section 3 analyzes DDoS logs and characterizes the distribution of affected systems;
第三节:分析DDOS记录并找出被影响的系统的分布特征
Section 4 presents our attribution of the Great Cannon to the Government of China;
第四节:介绍我们对于巨炮与中国政府之间关系的分析
Section 5 addresses the policy context and implications;
第五节:指出攻击策略背景和实现
Section 6 addresses the possibility of using the Great Cannon for targeted exploitation of individual users.
第六节:指出巨炮针对并操纵个体用户的可能性

Section 2: The Firewall & The Cannon: Separate Systems, Significant Similarities
第二节:防火墙和加农炮:分开的系统,显著的相似

Figure 1. Simplified logical topology of the Great Cannon and Great Firewall
(图1:简化的巨炮和GFW的逻辑拓扑)

In general, a firewall serves as an in-path barrier between two networks: all traffic between the networks must flow through the firewall.  In contrast, an on-path system like the Chinese “Great Firewall” (GFW) sits off to the side: it eavesdrops on traffic between China and the rest of the world (TAP in Figure 1), and terminates requests for banned content (for example, upon seeing a request for “http://www.google.com/?falun”,5 regardless of actual destination server) by injecting a series of forged TCP Reset (RST) packets that tell both the requester and the destination to stop communicating (INJECT RST in Figure 1).6  On-path systems have architectural advantages for censorship, but are less flexible and stealthy than in-path systems as attack tools, because while they can inject additional packets, they cannot prevent in-flight packets (packets that have already been sent) from reaching their destination.7  Thus, one generally can identify the presence of an on-path system by observing anomalies resulting from the presence of both injected and legitimate traffic.8
通常来说,防火墙是设置在两个网络之间的联通路上的屏障:所有网络之间的流量必须经过防火墙。而像中国GFW这样的旁路系统则与之相反:它监听中国和世界其他地区之间的通信(图1中的TAP),然后通过注入伪造的TCP RST包阻止对被禁止的内容的请求(举个例子,请求“http://www.google.com/?falun”[5],不管终点服务器在哪里),TCP RST包的作用是告诉请求来源和终点停止通信(图1中的INJECT RST)[6]。旁路系统在架构上利于审查,但是如果作为攻击工具,相比在路径上的系统(例如防火墙)更不稳定和容易暴露。因为当旁路系统能够向流量中注入额外数据包时,系统无法阻止已经被送出去的包到达目的地。[7]因此,一个人可以通过观察合法流量与被注入的流量之间的区别从而判断出旁路系统的存在。[8]

The GFW keeps track of connections and reassembles the packets (“TCP bytestream reassembly”)  to determine if it should block traffic.  This reassembly process requires additional computational resources, as opposed to considering each packet in isolation, but allows better accuracy in blocking.  While a web request often fits within a single packet, web replies may be split across several packets, and the GFW needs to reassemble these packets to understand whether a web reply contains banned content.
GFW通过持续追踪和重组包(“TCP字节流重组”)去决定是否应该阻止当前通信。重组进程要求额外的计算资源,不仅要将每个包隔离开来考虑,而且增加了切断连接的精准度。一个网页请求通常只需要一个包,但对应的回应可能会被分成几个包,GFW需要重组这些包去判断一个网页回应是否含有被禁止的内容。

On any given physical link (e.g., a fiber optic cable), the GFW runs its reassembly and censorship logic in multiple parallel processes9 (perhaps running on a cluster of many different computers).  Each process handles a subset of the link’s connections, with all packets on a connection going to the same process.  This load-balanced architecture reflects a common design decision when a physical link carries more traffic than a single computer can track.  Each GFW process also exhibits a highly distinctive side-channel — it maintains a counter, and numbers the forged TCP Reset packets it injects (via the value of the IP TTL field).
对于任意的物理链路(比如说光缆),GFW通过多条并行进程[9]去进行重组和审查(也许是由很多计算机组成的簇)。每个进程负责处理链路上连接的子集,同一连接上所有的数据包都是由同一个进程处理的。这个负载均衡结构的设计依据是:一条物理链路上的流量超越了一台计算机的追踪能力。每个GFW进程也展示了一个独特性很高的旁路信道——它维护着一个计数器,从而为注入的伪造TCP RST包标号(来自于IP包TTL域的值)。

The Great Cannon (GC) differs from the GFW: as we will show, the GC is an in-path system, capable of not only injecting traffic but also directly suppressing traffic, acting as a full “man-in-the-middle” for targeted flows.  The GC does not actively examine all traffic on the link, but only intercepts traffic to (or presumably from) a set of targeted addresses.  It is plausible that this reduction of the full traffic stream to just a (likely small) set of addresses significantly aids with enabling the system to keep up with the very high volume of traffic: the GC’s full processing pipeline only has to operate on the much smaller stream of traffic to or from the targeted addresses.  In addition, in contrast to the GFW, the GC only examines individual packets in determining whether to take action, which avoids the computational costs of TCP bytestream reassembly.  The GC also maintains a flow cache of connections that it uses to ignore recent connections it has deemed no longer requiring examination.
巨炮和GFW是不同的设备:就像我们后面会展示的,巨炮是在路径上的系统,不仅能干扰通信还能掐断通信,对于目标通信来说巨炮就像个中间人一样。巨炮并不主动检查链路上的所有通信,只是拦截目的地是(或来自于)目标集合的地址的通信。将全部通信流减少为(似乎很小)的地址集合可能会显著提升系统对于非常大量流量的追踪能力:巨炮的完全进程管道只需要操作大大减少的目的地是或者来自于目标地址的通信流。补充一点,与GFW相反,巨炮对数据包进行检查的时候只决定是否行动,避免在TCP字节流重组上消耗计算资源。巨炮也维护着一个连接流缓存,用来忽略被认为不需要进行检查的连接。

The GC however also shares several features with the GFW.  Like the GFW, the GC is also a multi-process cluster, with different source IP addresses handled by distinct processes.  The packets injected by the GC also have the same peculiar TTL side-channel as those injected by the GFW, suggesting that both the GFW and the GC likely share some common code.  Taken together, this suggests that although the GC and GFW are independent systems with different functionality, there are significant structural relationships between the two.
然而巨炮和GFW有相似之处。就像GFW,巨炮也是多进程簇,不同的进程处理来自不同IP地址的连接。巨炮在旁路信道注入的数据包和GFW注入的数据包有着相同的异乎寻常的TTL值,证明GFW和巨炮很可能分享相同的代码。把这些放在一起就能看出来虽然巨炮和GFW是不同功能的独立系统,但是他们两个有显著的结构上的联系。

In the attack on GitHub and GreatFire.org, the GC intercepted traffic sent to Baidu infrastructure servers that host commonly used analytics, social, or advertising scripts.  If the GC saw a request for certain Javascript files on one of these servers, it appeared to probabilistically take one of two actions: it either passed the request onto Baidu’s servers unmolested (roughly 98.25% of the time), or it dropped the request before it reached Baidu and instead sent a malicious script back to the requesting user (roughly 1.75% of the time).  In this case, the requesting user is an individual outside China browsing a website making use of a Baidu infrastructure server (e.g., a website with ads served by Baidu’s ad network).  The malicious script enlisted the requesting user as an unwitting participant in the DDoS attack against GreatFire.org and GitHub.
在对github和greatfire.org的攻击中,巨炮截留了通往托管了常用的分析和社会性或广告性质的脚本的百度服务器的流量。巨炮如果看见了目标是其中某个百度服务器的请求,就可能执行以下两种行动之一:要么让请求不受干扰的到达百度服务器(98.25%的情况是这样),要么在请求到达百度服务器之前就丢弃请求并且向发出请求的用户发送回恶意脚本(1.75的情况是这样)。在这一事件中,发出请求的用户是一个在中国之外浏览使用了百度服务器的网站(例如一个挂有百度广告联盟广告的网站)的个体。恶意脚本把发出请求的用户变成了参与针对greatfire.org和github的DDOS攻击的攻击者。

Localizing the Cannon
定位巨炮

The GFW continues to operate as normal: on-path and statefully
GFW始终正常工作:旁路和满状态

We began our investigation by confirming the continued normal operation of the GFW’s censorship features.  We did so employing measurements between our test system outside of China and a Baidu server that we observed returning the malicious Javascript.  We sent the Baidu server a request that the GFW would process as a query for “http://www.google.com/?falun”, a URL long known10 to trigger the GFW to inject forged TCP Resets to terminate the connection.  This packet capture shows the results of our experiment, which confirmed that the normal, well-understood operation of the GFW continues.  Note that the capture includes both the injected TCP Reset and, later, the legitimate response (an HTTP 403 reply) from the Baidu server.  This occurs because the GFW operates as an on-path system, and, as discussed earlier, on-path systems cannot prevent in-flight packets from reaching their destination.
我们通过持续性的正常操作来确认GFW的审查特征,从而开始我们的调查。我们在处于中国之外的测试系统和百度服务器之间进行了测量,观察到返回了恶意JS脚本。我们向百度服务器发送了一个请求:“http://www.google.com/?falun”,一个会触发GFW注入伪造的TCP Reset包从而终结连接的审查过程的URL[10]。抓包结果显示了我们的实验结果,从而确认了GFW的正常审查还在继续。注意抓包结果包括了被注入的TCP Reset包和迟些到达的百度服务器的合法响应(一个HTTP 403 回复)。发生这些的原因是GFW是一个旁路系统,早先的讨论说明了旁路系统无法阻止在路上的包到达目的地。

Figure 2. How the Great Cannon was deployed in the GitHub and GreatFire.org attacks
(图2:现在巨炮被部署用于对github和greatfire.org的攻击)

Localizing the GFW
定位GFW:

We then localized where (with respect to our measurement system) in the network topology the GFW operates, as follows.  For a given measurement packet, we can control how far into the network it transits from our measurement system to its destination by controlling the packet’s TTL value.  The TTL value determines after how many intermediate hops a packet will be discarded by the Internet’s internal routers.  We sent the “Falun” queries from our test system to the Baidu server with TTL values increasing from 1 on up.  We observed that the GFW’s TCP Reset injection only occurred when we sent packets with TTL values >= 18, suggesting that the GFW acts on traffic flowing between the 17th and 18th hop along the path from our test system to the Baidu server (which was itself 24 hops away from our test system).  This packet capture shows our localization results.11
接下来我们定位了GFW在网络拓扑上的位置(向我们的测量系统表示尊敬),接下来开始说明:对于一个给出的用于测量的包,我们可以通过控制包的TTL(Time To Live,存活时间或跳步数)值来控制包能深入网络的最远距离。TTL值决定了经过多少中间跳板后一个包会被互联网内部的路由器丢弃。我们从测试系统发送了“Falun”查询请求,目标是百度服务器,TTL值则从1开始逐渐增加。我们观察到GFW的TCP Reset包注入只发生在包的TTL值>=18时,这表明对于我们的测试系统和百度服务器(和测试系统之间有24跳的距离)之间的通信,GFW在第17跳和第18跳之间对通信流进行了处理。这个抓包结果显示了我们的定位结果。[11]

The GC operates as a separate, in-path system
巨炮是一个分离的,在路上的系统

As noted previously, our traces of GFW operation showed both the injected TCP Reset, as well as the legitimate server reply.  In contrast, no legitimate server reply accompanied the injected malicious reply from the GC.  We ran further testing, where we retransmitted our request to Baidu over the same connection, and with the same sequence numbers, after we received a malicious response.  We observed Baidu responding as normal to the retransmitted request.  Thus, we conclude12 that the GC dropped our request before it reached Baidu, a capability not present in the GFW.13
之前我们提到,对于GFW行为的追踪显示了注入的TCP Reset包和合法服务器回应是同时存在的。与之相反,来自巨炮的被注入的恶意回复就没有合法服务器回复伴随出现。我们继续深入测试,在收到恶意响应之后再在同一连接上重传对百度的请求,序列号与之前的请求相同。我们观察到百度对于重传请求的响应很正常。因此,我们得出这样的结论[12]:巨炮在我们的请求到达百度服务器之前把它丢弃了,这是一个和GFW不同的能力[13]。

We also checked whether the GFW and GC might share the same injector device,14 but found no evidence that they do.  In particular, from a given TCP source port, we sent one request designed to trigger GC injection, followed by a request designed to trigger GFW injection.  We repeated the experiment from a number of source ports.  While packets injected by both the GFW and GC exhibited a similar (peculiar) TTL side-channel indicative of shared code between the two systems, we found no apparent correlation between the GFW and GC TTL values themselves.
我们也检查了GFW和巨炮是否可能共享相同的注入设备[14],但是没有找到证明这一点的证据。
特别是,我们从一个给定的TCP源端口发送被设计为会触发巨炮注入行为的请求,后面跟上一个被设计为会触发GFW注入行为的请求。我们在几个源端口上重复实验,结果发现GFW和巨炮注入的包都展示出了相似的奇特TTL旁路信道,这表示两个系统之间共享代码,但我们没有发现GFW和巨炮(注入的数据包)的TTL值之间有明显的关联。

The GC appears to be co-located with the GFW
巨炮明显和GFW的物理位置一致

We used the same TTL technique to localize the GC on the path between our test system and the Baidu server.  We found that for our path, the GC acted on traffic between hop 17 and hop 18, the same link we observed as responsible for the GFW.  We also observed that unlike the GFW, we could trigger the GC using “naked” requests (i.e., requests sent in isolation, with no previous TCP SYN as required for standard communication).  Acting on “naked” requests implies that the GC’s content analysis is more primitive (and easily manipulated), but does offer significant performance advantages, as the GC no longer needs to maintain complex state concerning connection status and TCP bytestream reassembly.
我们使用了和之前一样的TTL技术来定位巨炮在我们的测试系统和百度服务器之间的位置。我们发现对于我们的路径,巨炮在第17跳和第18跳之间行动了,这和我们观察到的GFW行动在同一条链路上。我们也观察到不同于GFW,我们可以用“裸”的请求(例如隔离状态下的请求,之前没有标准通信要求的TCP SYN包发送)来触发巨炮。对于“裸”请求的反应意味着巨炮的内容分析功能更为原始(以及更容易被操纵),但是这使得巨炮的表现显著得到了提升,因为巨炮不再需要维持复杂状态来考虑连接状态和进行TCP字节流重组了。

We also checked two separate servers in China whose traffic the GC targets to observe whether the GC existed along with the Great Firewall on multiple network paths.  From our measurement system outside of China, we examined the path to both 115.239.210.141 and 123.125.65.120.  For 115.239.210.141, the GFW and the GC both exist between hop 12 and 13, on the link between 144.232.12.211 and 202.97.33.37, as the traffic enters China Telecom.  For 123.125.65.120, the GFW and GC both exist between hop 17 and 18, on the link between 219.158.101.61 and 219.158.101.49, belonging to China Unicom.  A previous report by Robert Graham used the same TTL technique to conclude that on one link, the GC was located “inside China Unicom infrastructure.”15
我们也检查了两个在中国的分开的服务器,他们的通信是针对巨炮的,用于观察在多网络路径上巨炮是否和GFW一起存在。我们利用在中国之外的测量系统检查了通向115.239.210.141和123.125.65.120的路径。对于115.239.210.141,GFW和巨炮都存在于第12跳和第13跳之间,这结果在144.232.12.211和202.97.33.37之间的链路
上被观察到,这些通信进入了中国电信网中。对于123.125.65.120,GFW和巨炮都在第17跳和第18跳之间存在,这结果在219.168.101.61和219.158.101.49之间的链路上被观察到,这些链路属于中国联通。之前一份来自于Robert Graham的报告使用了相同的TTL技术,结论是对于一个链路,巨炮位于“中国联通的基础架构之内”[15]

The GC is currently aimed only at specific destination IP addresses
巨炮只针对特定目的地的IP地址

When we probed an IP address adjacent to the Baidu server (123.125.65.121), the GC ignored the requests completely, although the GFW acted on censorable requests to this host.
当我们探测一个与百度服务器邻近的IP地址时(123.125.65.121),巨炮完全忽略了请求,虽然GFW对请求进行了审查。

Unlike the GFW, the GC only acts on the first data packet of a connection
不同于GFW,巨炮只对连接的第一个数据包采取行动

For a given source IP address and port, the GC only examines the first data packet sent when deciding whether to inject a reply.  To avoid examining subsequent packets requires remembering which connections it has examined in a flow cache.  Unlike the GFW, the GC does not reassemble packets, a significant implementation difference.  In addition, the GC will process invalid HTTP requests, while the GFW will not, also indicating differing implementations.
对于一个给定的源IP地址和端口,巨炮只检查第一个发送的数据包以决定是否注入一个回复。这是为了避免在检查按顺序发送的包时不得不记忆哪些连接是已经检查过的(也就是在流缓存里的)。不同于GFW,巨炮不重组包,这是一个显著的实现差异。补充说明,巨炮会处理无效HTTP请求,而GFW不会,这也意味着不同的实现。

We confirmed these behaviors by sending a number of probes to the Baidu server, requesting resources that trigger the GC’s injection.  Each probe had a different source port.  We sent 500 probes, each with the request split across three packets (so 1,500 packets total).  The GC ignored each probe.  We then sent 500 probes where the first packet’s data is an invalid HTTP request, and the second packet’s data is a complete, valid request for a targeted resource.  The GC ignored each probe.  We then sent a final 500 single-packet probes, each containing a complete, valid request for a targeted resource, to confirm normal GC operation.  As expected, the GC injected malicious content in some cases, seemingly based on its probabilistic decision-making process.
我们通过向百度服务器发送一些探测器,请求资源来触发巨炮的注入从而确认这些行为。每一个探测器都有不同的源端口。我们发送了500个探测器,每一个的请求都分裂在三个包中(所以总共有1500个包)。巨炮忽略了每个探测器。接下来我们发送了500个探测器,第一个包的数据是无效的HTTP请求,第二个包的数据是一个针对目标资源的完整有效的请求。巨炮忽略了每个探测器。接下来我们发送了最后500个单包探测器,每一个都包括了一个针对目标资源的完整有效的请求,以确认正常的巨炮反应。就像期待的那样,巨炮在一些情形下注入了恶意内容,似乎是基于它的基于概率的做决定进程。

How big is the GC flow cache?
巨炮的流缓存有多大?

We attempted to completely fill the GC flow cache by sending packets to the Baidu server with different source IP addresses and ports, while probing to see whether the entries that we previously added had now expired.  Our attempt suggests that at least in some cases, the GC flow cache between our test system and the Baidu server supports up to around 16,000 entries for a single sending IP address.
我们试图通过向百度服务器发送不同源IP地址和端口的包(同时探测之前加入的实体是否过期了)来塞满巨炮的流缓存。我们的努力显示至少在一些情形下,巨炮在我们的测试系统和百度服务器之间的流缓存支持最高16000左右实体,这是对于一个单独IP地址而言。

Unlike the GFW, the GC appears to act probabilistically
不同于GFW,巨炮的行动是概率性的

Censorship systems generally operate in a deterministic fashion: they aim to block all content that matches the target criteria.  The GC, on the other hand — at least for this particular attack — appears to act probabilistically, and ignores most of the traffic it could act on.  In one test, it completely ignored all traffic from one of four measurement IP addresses, and on the three other measurement IP addresses it only responded to 526 requests out of an initial 30,000 from the three (1.75%).
审查系统通常是决定性的风格:他们的目标是阻挡所有匹配上目标标准的内容。巨炮,另一方面——至少是对于这个特别的攻击而言——表现出了概率性的行动,忽略了绝大部分可以展开行动的流量。在一次测试中,巨炮完全忽略了所有从四个测量IP地址中的一个中发出的通信,对于其他三个测量IP地址,巨炮只响应了初始30000个请求中的526个请求(1.75%)。

The cache capacity test also provides evidence that the GC’s probabilistic choice occurs on the decision to act on a particular flow, and not as some sort of pre-filter for reducing analysis load.  When we succeeded in completely filling the flow cache, subsequently injected packets occurred for different source ports than in the initial test.  If the GC only intercepted a subset of flows to the target IP address, we would expect subsequent injections to appear for the same flows, since most schemes to probabilistically select flows for interception (such as hashing the connection 4-tuple) would select the same set of flows the second time around.
缓存能力测试也提供了关于巨炮在决定对一个特别的流行动时的概率化选择的证据,测试过程中并没有为了降低分析负担的预先过滤。当我们成功塞满了流缓存时,有序的注入的包出现了,针对不同的源端口,这点和初始测试不同。
如果巨炮只截取通往目标IP地址流量的子集,我们可以期待对于同一个流会出现序列化的注入,因为大部分概率化选择截取流(比如对连接4元组进行hash)的方式在第二次都会选择同一个流。

Does the GC have a load-balanced architecture?
巨炮有负载均衡系统吗?

We determined that the GC uses a separate flow cache for different source IP addresses, and that packets injected from different source IP addresses have distinct TTL side-channels.  This finding suggests a load-balanced architecture similar to the GFW, where packets are routed to GC nodes based on source IP address.  We then sent traffic alternating from four measurement IP addresses in an attempt to fill a 16,000 entry cache.  This attempt did not manage to fill the cache, suggesting that the GC not only processed the different source IP addresses with different injection elements, but did so using different flow caches.  As stated before, one of the four source IP addresses never received any injected replies.
我们认定了巨炮对于不同的源IP地址使用了分离的流缓存,被注入从不同源IP地址来的流的包有不同的TTL旁路信道。这一发现显示存在一个和GFW类似结构的负载均衡系统,包根据源IP地址被路由到不同的巨炮节点上。接下来我们轮流发送来自四个测量IP地址的流量来试图填满一个能容纳16000个实体的缓存。这个努力并没有成功塞满缓存,表明巨炮不仅在处理来自不同源IP地址流量的时候用不同的注入元素进行处理,而且也是这么使用不同的流缓存的。就像之前所提到的,四个源IP地址中的一个没有收到任何注入的回复。

待续......

源地址:https://citizenlab.org/2015/04/chinas-great-cannon/
 
Creative Commons License
翻牆網 ATGFW.ORG 收集整理。