關於GFW是如何封翻牆服務器的猜想

http://fqrouter.tumblr.com/post/45969604783/gfw

 

不少朋友的SSH/OPENVPN服务器都中招了。观察到两个案例都是被GFW封端口了。具体是怎么被GFW发现,怎么被封的。我有以下一些猜想。

假设client代表国内的机器。server代表国外的翻墙服务器。

封的方式不是

client => server (ip)

客户端是可以往服务器的ip发包的,服务器可以收到。也不是

client => server (ip+port)

即便是往服务器被封的端口发包,服务器也是可以收到的。也不是

server(ip) => client

服务器的ip是可以往客户端发包的,客户端可以收到。

server(ip+port) => client

这个时候,服务器以特定端口发的包会被GFW的路由器给丢掉,客户端收不到。

最容易重现的方法是把那个被封的端口先空出来。然后在服务器上执行

traceroute -T —sport=[blocked_port] baidu.com -n

可以看到中间有路由器在丢包。

也就是针对服务器向客户端的下行流量,做针对src+sport的丢包。

为什么什么是针对下行流量的?为什么src+sport?我的猜想是这样的。

GFW需要找出哪些国外的服务器是翻墙服务器。有两个路径可以观察到双方的通信,一个方向是上行流量,国内的客户端往国外的服务器发的包。另外一个 方向是下行流量,国外的服务器往国内的客户端发的包。特别注意的是,无论是GFW的分析设备,还是骨干路由器本身都不能保证在一个点完整地监听到双向的流 量,因为从a=>b和从b=>a的IP包经过的路径一般是不一样的。除非这个监听的设备非常靠近你的出口网管,比如第一跳,第二跳这样的情 况。

GFW要发现翻墙服务器的第一步是找出一个短名单。根据方校长的论文我们知道,现在的机器识别算法没有牛叉到可以处理所有的国际出口的上下行流量的 分析。而且,根据80/20原则,如果有100个翻墙服务器,其中只有20个使用最频繁,GFW肯定希望投入精力去封使用最频繁的翻墙服务器。达到这两个 目的,就是根据主机行为。其实就是从cisoco的路由器上提取netflow的聚合数据,得到国内ip与国外ip的通信模式。因为国内的ip很多,国外 的ip也很多,所以直接提取所有的聚合数据肯定非常多,自然会做一个最小通信数据量的过滤。

那么GFW是利用了cisco的哪个netflow聚合scheme呢?在分析了cisco路由器所有的聚合scheme之后,我觉得Prefix-port aggregation scheme是最又可能的(http://www.cisco.com/en/US/docs/ios-xml/ios/netflow/configuration/15-mt/cfg-nflow-aggr-cache.html#GUID-500A6933-EE5E-4830-B01C-50031E7EA82C)。在导出的数据基础上,可以进一步聚合为如下形式:

src, dst, sport => bytes

因为翻墙大部分的流量都是从服务器发往客户端的,所以使用下行流量会具有更加明显的流量特征。所以如果是下行流量,src就是服务器ip。dst就 是客户端ip,sport就是服务器的端口。根据一定的阀值,可以把数据量小于一定值的聚合信息排除。这样在剩下的数据中,找出给定src,dst与 sport的组合最小的src。这样的通信模式不同于:

  • 普通的国外HTTP服务器不会有集中的几个国内的客户端ip去访问,大部分的时候客户端的ip应该是分散的
  • 普通的国外客户端(比如google的爬虫去爬国内网站),因为其为客户端,所以sport不会特别集中,使得几个特定的sport流量特别大

那剩下的国外的服务器就非常有提供翻墙服务的嫌疑。

那为什么不把这个src和sport翻译为dst和dport的ACL规则部署到路由器上呢,而要部署成这么别扭的针对下行的src和sport过滤的方式。其实这有几个好处:

  • 写GFW的人懒,不需要做这个翻译
  • 从客户端很难观察到问题,因为针对那个端口的traceroute都是通,只有从服务器端traceroute才可以观察到问题,客户会怀疑是服务器挂了。这个比封dst更加隐蔽
  • 不依赖于全局同步的可靠性。GFW有一个规则的全局同步机制,一个路由器部署了这个规则,会很快同步到全国的其他路由器上。如果翻译成dst和 dport部署,则要求客户端向服务器发的包必须经过这个部署了规则的路由器。因为抓到下行流量的路由器不一定在上行流量的路径上,所以部署成dst和 dport的形式则要求全局同步的实现要有高可靠性。

基于这样的猜想。私有实现的协议虽然可以在进了短名单之后不被立马发现。但是并不能避免进入这个短名单。所以哪怕是私有协议,只要流量过大在短名单上太招摇了,肯定会导致人工介入的。

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

%d 位部落客按了讚: