? Editing: Post:21.body Save Delete Cancel
Content changed Sign & Publish new content

中囯网絡審查技術評論

總結:网絡審查主要是為了維穩(混淆視聽、拆散人心),而不是宣傳(臉上貼金)

Follow in NewsfeedFollowing

Latest comments:

Add new post

Title

21 hours ago · 2 min read·
3 comments
Body
Read more

Not found

深入理解 GFW:内部结构

on Jun 03, 1989 · 6 min read

之前我们对 GFW 进行了大量的黑箱测试,尽管大多数实验数据都得到了良好的解释,但是还是有些数据或者体现出的规律性(不规律性)没有得到合理的解释。比如 TCP 连接的各项超时时间,比如 Google 的 443 端口被无状态阻断时,继发状态的持续跟源 IP 相关的问题。比如一般 TCP 连接的继发阻断时,窗口尺寸和 TTL 的连续变化特性。这些问题已经超出纯协议的范畴,需要对 GFW 的内部结构进行进一步了解才能明白其原因。所以在这一章介绍 GFW 的实现和内部结构。


总的来说,GFW 是一个建立在高性能计算集群上规模庞大的分布式入侵检测系统。其分布式架构带来了很高的可伸缩性,对骨干网一点上庞大流量的处理问题被成功转换成购买超级计算机堆砌处理能力的问题。它目前有能力对中国大陆全部国际网络流量进行复杂和深度的检测,而且处理能力「还有很大潜力」(2009 年 8 月)[null]

线路接入

典型意义下GFW线路拓扑

svg

对于 GFW 在网络上的位置,有很模糊的认知:「在三个国际出口作旁路监听」。然而还希望对在出国之前最后一跳之前发生了什么有详细了解。
GFW 希望对不同线路的链路异构性进行耦合,并研究了快速以太网、低速 WAN、光纤、专用信号多种类型链路的耦合技术。[03b] 而根据《国际通信出入口局管理办法》,几大 ISP 有自己的国际出入口局,最后在公用国际光缆处汇合,比如在海缆登陆站之前汇合。据已有的资料,安管中心(CNNISC)有独立的交换中心,而且有报道说各个 ISP 是分别接入其交换中心。这样几个材料就可以形成一致的解释:为了适应不同 ISP 不同的链路规格,GFW 自己的交换中心需要对不同的链路进行整合,不同的 ISP 分别引出旁路接入 GFW。而没有接入 GFW 的线路则被称为「防外线」[来源不可靠],不受 GFW 影响。接入的线路类型应该主要是光纤线路,因此通常称此接入方式为分光。这就是「旁路分光」。另外实验发现,GFW 的接入地点并不一定紧靠最后一跳,因此图中以虚线表示。需要注意 GFW 的响应流量重新接回网络的地点难以确认,这里只是假设是与接出的地点相同。

负载平衡

面对多条骨干监测线路接入产生的巨大不均匀流量,不能直接接到处理集群,而是要先进行汇聚然后再负载均衡分流成均匀的小流量,分别送给处理集群并行处理。首先需要将网络设备通信接口(Pos、ATM、E1 等)转换成节点可用的主机通信接口(FE、GE 等)。处理负载均衡的算法经过仔细考虑,希望实现:流量均匀分布、对于有连接协议保持连接约束、算法简单。连接约束是指:一对地址端口对之间的一个连接全部通信都要保证调度到同一个节点。[03b][03a][05a]
GFW 关于负载平衡的文章中主要提出两种算法。一种是轮转调度,对于 TCP,当 SYN 到达时,以最近分配的节点号取模再加 1,并将连接存入 hash 表,当后继流量到达时就能查询 hash 表获得目标节点号。[03a] 另一种是基于连接参数的散列,对于 N 个输出端口调度输出端口号是H(源地址, 目标地址, 源端口, 目标端口) mod N[03b],这个 H 函数可以是 xor[05a]
而之前的某个实验中我们碰到一种特殊的模式,负载平衡在解释其现象中起到了重要作用,下面专门分出一节详细说明。

一个关于窗口值的实验

实验步骤:发送含有关键词的特制包通过 GFW,并接收 GFW 返回的阻断响应包。因为触发阻断之后,同地址对和同目标端口的连接都会受到继发阻断,为了消除这种干扰,一般采取顺序改变目标端口的扫描式方法。通过前期一些实验,我们已经发现和确认某类(二型)阻断响应包中的 TTL 和 id 都跟窗口大小有线性关系,我们认为窗口是基本量(二型窗口为 5042 时 id 发生了溢出,只有在 id 根据窗口算出时才会发生此种情况)。
然而在顺序扫描中有一种特殊的模式无法用现有证据解释。进一步的实验步骤是:在源、目标地址不变的情况下,顺序扫描目标端口,记录返回的阻断响应包的窗口。数据如下图,横轴是时间(秒),纵轴是端口号,每个点代表一次阻断触发事件中观测者收到的阻断包的窗口值。

可以明显看出一种线性增加的趋势。图像取局部放大看:

可以看出,在同一时间有 13 根较连续的线。这样产生了几个问题:为什么有独立可区分的不同的线?这些线表示了什么?为什么有 13 根?为什么每根线是递增的?

  • 为什么有独立可区分的不同的线?现象具有明显的可以继续划分的子模式,而不是一个整体的随机量,并且每个子模式都有良好的连续增加的性质。因此可以推测产生此现象的内在机制不是一块铁板,而是多个独立的实体。进一步的实验事实是,如果顺序扫描端口每次增加 13,那么只会产生一条较连续的线而排除其他的线。这直接证明了模 13 同余端口产生结果的不可分性、实体性,以及同余类间的独立性。

  • 这些线表示了什么?我们猜想,这 13 根线就表征了背后有 13 个独立实体分别根据某个内在的状态产生阻断响应,窗口值就是其内在状态的直接表现。

  • 为什么有 13 个?而不是 1 个 2 个?这个时候,负载平衡就是对此事实的一种解释良好的模型。如果 GFW 有 13 个节点在线,由于希望将流量平均分配到每个节点,那么根据前面论文所述,便采用模的方式,在源、目标地址不变时,根据目标端口模 13 分配流量,目标端口模 13 同余的包会进入同一个节点。实际上更早的时候的一次实验是发现有 15 根线,同理可以猜测有 15 个节点在线。

  • 为什么每根线是递增的?实验中发现,每次阻断 GFW 会分别向连接双方发送窗口值依次增加的两组阻断包,这样对于每方来说,每次阻断就会使窗口值增加 2。每根线会递增正是说明节点在不断产生阻断包增加窗口值,一部分是实验观察者的观测行为触发的,另一部分则是普通网络流量造成的。如果对数据做差分并扣除观测造成的影响,甚至还可以对每节点产生阻断的速率有所估计。

  • 但是为什么要让窗口递增?这背后的动机难以找到很合理的解释,可能这个窗口值有计数器的作用,也可能是为了在 ip.id 上对不同节点产生的包进行区分。事实上,一型的窗口值就是几乎随机但 ip.id 固定,窗口递增并非是必须的。

然而进一步的实验发现,如果目标端口、源地址不变,而目标地址顺序变化,图像就显得比较紊乱,找不出规律。虽然如此,仍然在局部可以识别出同时存在 13 根线的情况,进一步证实「13 个节点在线」的猜测。这个实验的意义在于,通过对现象的分解约化,分离出 GFW 内部的某种独立实体结构,对论文中主张的负载平衡算法有进一步的实践证实,对 GFW 的内部结构得到进一步的认识。[A]

数据处理

当数据流通过当数据总线到达终端节点之后,需要将其从物理层提取出来供上层进一步分析,这个部分称为报文捕获。普通的做法,先网卡中断一次通知内核来取,然后控制 DMA 传到内核空间,然后用户用read(),让内核copy_to_user()将 sk_buff 的数据复制到用户空间,但是这样复制一次就带来了无谓开销。因此 GFW 设计环状队列缓存,以半轮询半中断机制减少频繁中断的系统调用开销,用 mmap 实现 zero-copy,把数据直接从网卡 DMA 到用户空间。这样性能提高很多(耦合也提高很多)。[B]
链路层数据到怀里了,接下来要将数据上交给 TCP/IP 栈。论文中多次提到 libnids(这个库我们也是第一眼就瞟到了,后来发现对诊断没什么用),将其作为基准,(甚至可能符合国情地)以其为蓝本改进,开发出了一种多线程的 TCP/IP(自动机)。后面又在考虑对其进一步做自动机分解优化。后来又再次提出一种两级连接状态记录表,一级轻量级环状 hash 表可以缓解大量无效连接和 SYN Flood 的情况,二级表才真正存储连接的信息。实验结果与此相符:发送 SYN 之后的超时时间要比发送第一个 ACK 之后的超时时间短得多。文献中还提到 libnids 的 half_stream,从实际的情况上看,GFW 的 TCP 栈的确具有鲜明的半连接特性,也就是说:一个方向的 TCP 栈只检测客户端到服务端的数据,或者反之。这样一个直接的后果就是,即使服务端根本不在线没响应,客户端照样可以假装三次握手然后触发一堆 RST。往好的方向看,也许是因为多线程 TCP 栈还原全连接时不想处理数据共享控制的问题。总而言之,GFW 有一种非常轻量级的 TCP/IP 栈,刚好能够处理大多数遵守 RFC 的连接。如果用户稍微精明一点就能穿过去,GFW 要么坐视不管,要么重写 TCP 栈。[C]
TCP/IP 栈将数据分片重组,流重组之后交给应用层解析。应用层由很多插件模块组成,耦合松,部署易。其应用层插件包括「HTTP、TELNET、FTP、SMTP、POP3、FREENET、IMAP、FREEGATE、TRIBOY」。[05a] 有意思的是,这是首次官方确认 GFW 与 Freegate、Freenet、Triboy 的敌对关系。应用层的协议大家都很熟悉不用多解释,不过应用层问题比传输层更多了。好几个模块都有一些小毛病,比如某类 HTTP 模块只认得 CRLF 作为 EOL,换作 LF 便呆了。再比如某类 DNS 模块,发的 DNS 干扰包,十有五六都校验和错误,查询 AAAA 也返回 A,还不如关掉。多数模块都是得过且过,刚好可以工作,一点都不完善。这里列出的、发现的问题按照软件设计一般规律也只是冰山一角。由此推断,GFW 的设计哲学是:better is worse
不过在可以生产论文的话题上,GFW 绝不含糊,就是模式匹配。应用层模块把应用层协议解析好了,然后就要看是不是哪里有关键词,字符串匹配。搞了一堆论文出来,改进 AC 算法和 BM 算法,就差汇编的干活了,得出某种基于有限状态自动机的多模式匹配算法,特别适合 GFW 这种预定义关键词的需求。总之复杂度是线性的,攻击匹配算法消耗 CPU 什么的就不要想了。

响应机制

如果匹配到一个关键词了,要积极响应阻断之。响应的手段其他地方已经说得太多,手懒,特此剽窃一段,欢迎举报学术不正之风:

响应机制的发展已经经历 IP 包过滤(静态 IP 包过滤、动态 IP 包过滤)、连接欺骗(传输层连接欺骗、应用层连接欺骗)两个阶段,并且形成了针对不同的应用多种方式共存的现状。
静态 IP 包过滤是 IDS 通过和被保护网络与外部网络之间的连通边的端点网络层设备(路由器、三层交换机等)进行联动,在其上设置访问控制列表(ACL)或静态路由表来实现对指定 IP 地址的过滤。由于需要过滤的 IP 地址数量很大,大多数的网络层设备上对 ACL 大小和性能的支持不能满足要求,因此,实际工作中大多采用静态路由的方式。使用该种方式,信息入侵检测系统只能通过专用客户端程序静态写入的方式进行访问控制,粒度大(IP 地址级),响应时间慢,容量较小,但是可以静态写入路由设备的配置文件中,是非易失的。
动态 IP 包过滤是指入侵检测系统采用动态路由协议(BGP,OSPF 等)和关键路由设备进行路由扩散,将需要过滤的 IP 地址扩散到路由设备中的路由表中,特点是响应时间快、容量大,但是只能动态地写入路由设备内存(RAM)中的路由表中,是易失的,同样粒度大。
连接欺骗指信息入侵检测系统在敏感连接传输过程中伪造连接结束信令(RST,FIN)发送给连接的源和目的地址,以中断该连接。特点是实时性强、粒度小(连接级),可以针对某一次敏感连接进行阻断。缺点是对分析系统工作状态依赖较强,需要向业务网上发送数据包,易受 DoS 攻击。
通过和连接级防火墙设备进行联动,可以针对连接五元组(传输协议类型、源地址、源端口、目的地址、目的端口)对数据流进行过滤。可以针对指定的任意五元以内的组合条件进行过滤,实时性强、粒度小。

后来又加上了 DNS 劫持 / 污染,不过这个手动设置的机制已经不能算一个入侵检测系统的响应了。

日志记录

GFW 有日志。这意味着什么?这就意味着当你芬兰国的时候,你的所作所为都记录在案。不光是你一个人,其他所有人都经常芬兰国。但据统计 87.53% 的人(361 之 316)都是无意之中芬兰国,从统计理论上看,记录在案的无效信息过多会造成信息难以利用。因此 GFW 后期一直在做「数据融合、聚类、分类的研究」,鸭子硬上弓,各种神经网络、概率模型、人工智能的论文整了一大堆,效果如何呢?
GFW 的日志应该会记录这样一些事件信息:起始时间、结束时间、源地址、目标地址、目标端口、服务类型、敏感类型。[null] 信息难以利用不等于不能利用,如果日志被翻出来了而且用户没有用代理,那么根据常识,从 IP 地址对应到人也只是时间问题。这就是说,GFW 即使不能阻断,最差也是一个巨型监听设备。

规模估计

问题:GFW 的软硬件配置?

事实:「虚拟计算环境实验床」是由国家计算机网络应急技术处理协调中心(CNCERT/CC)和哈尔滨工业大学(HIT)协作建设,以国家计算机网络应急技术处理协调中心遍布全国 31 个省份的网络基础设施及计算资源为基础,对分布自治资源进行集成和综合利用,构建起的一个开放、安全、动态、可控的大规模虚拟计算环境实验平台,研究并验证虚拟计算环境聚合与协同机理。2005 年此平台配置如下:[05b]

|
|
|
|
|
|
|
| --- | --- | --- | --- | --- | --- |
| CNCERT/CC | 北京 | 曙光 4000L | 128 节点 | 2Xeon 2.4G | RAM2G |
| HIT | 哈尔滨 | 曙光服务器 | 32 节点 | 2_Xeon 2.4G | RAM2G |
| CNCERT/CC | 上海 | Beowulf 集群 | 64 节点 | 2_AMD Athlon 1.5G | RAM2G |

_结论:GFW(北京)使用曙光 4000L 机群,操作系统 Red Hat 系列(从 7.2[03a] 到 7.3[05a] 到 AS 4),周边软件见曙光 4000L 一般配置;GFW 实验室(哈工大)使用曙光服务器 [05b],Red Hat 系列;GFW(上海)使用 Beowulf 集群(攒的?)。


问题:GFW 与曙光是什么关系?

事实:换句话说,是先有了用户的应用需求(蛋),才有了曙光 4000L 的研制(鸡)。这其实不难想像,一套价值几千万元的系统,如果纯是为了填补科学空白,将会延长产品市场化的时间。曙光 4000L 充分体现了中科院计算所在科研成果市场化方面的运作能力。...... 而曙光 4000L 这套系统就是针对国家信息化的实际应用而设计的。 曙光 4000L 的研制...... 曙光公司从事了工程任务和产品化工作,国防科技大学从事了机群数据库中间件的开发工作,哈尔滨工业大学开发了应用软件。 哈尔滨工业大学(威海)网络与信息安全技术研究中心日前成立,...... 方滨兴...... 揭牌。...... 曙光...... 向研究中心赠送了一套价值 40 万元的刀片服务器。

结论:GFW 是曙光 4000L 的主要需求来源、研究发起者、客户、股东、共同开发者。是不是应该打一点折?(曙光公司 = 中科院计算所)


问题:GFW 计算规模有多大?_

_事实:2007 年机群规模进一步扩大,北京增至 360 节点,上海增至 128 节点,哈尔滨增至 64 节点,共计 552 节点。机群间星型千兆互联。[null] 计划节点数上千。[null] 曙光 4000L...... 系统节点数为 322 节点,可扩展到 640 节点。根据功能的不同,曙光 4000L 可以分为服务节点、计算节点和数据库节点三类。每个计算节点 2 个 2.4GHZ 的 Intel Xeon CPU,内存 2GB。 2005 年国家计算机网络与信息安全管理中心(北京)就已经建立了一套 384_16 节点的集群用于网络内容过滤(005 工程)和短信过滤(016 工程)。[来源不可靠] 64 个节点、128 个处理器(主频为 2.8GHz)的曙光 4000L...... 包括系统软件、管理软件、输入输出设备和存储设备,采购金额近千万。 才有了曙光 4000L 的研制...... 一套价值几千万元的系统。 国家信息安全重大项目「国家信息安全管理系统」(005 工程)经费 4.9 亿。

猜测:GFW(北京)拥有 16 套曙光 4000L,每套 384 节点,其中 24 个服务和数据库节点,360 个计算节点。每套价格约两千万到三千万,占 005 工程经费的主要部分。有 3 套(将)用于虚拟计算环境实验床,计千余节点。13 套用于骨干网络过滤。总计 6144 节点,12288CPU,12288GB 内存,峰值计算速度 48 万亿次(定义不明,GFW 不做浮点运算,2003 年 top500 排名榜首地球模拟器 5120 个 CPU)。


问题:GFW 吞吐量有多大?

事实:2GHz CPU 的主机 Linux 操作系统下可达到 600Kpps 以上的捕包率。通过骨干网实验,配置 16 个数据流总线即可以线速处理八路 OC48 接口网络数据。[03b] 曙光 4000L 单结点的接入能力为每秒 65 万数据包,整个系统能够满足 32Gbp 的实时数据流的并发接入要求。

猜测:512Gbps(北京)

结论

噫吁嚱!危乎高哉!......

注释

  • null 引用有特殊含义。

  • [A] 因为性能要求,负载平衡的完整算法必然很简单,不过我们一下子也没有猜出来。由于这个算法是易变的,即使猜出来公布在这里就立刻失效了,因此也没有在这个方向再费精力。

  • [B] 顺便指出论文中存在的一种硬伤。论文中反复把 libpcap 当反面教材作为性能低下的代表,称其是「传统 TCP/IP 栈之上的用户层函数库」「基于传统 TCP/IP 栈的 libpcap」。可是人家 libpcap 从 2001 年 1 月的 0.6 版本就开始用 2.2 以上版本内核提供的 packet(7) socket,这个跟 TCP/IP 一点关系都没有。怪罪的对象错了,要怪的是 packet(7) 而不是 libpcap。后来 2004 年 PF_RING 出来,设计很相似,libpcap 用上一样 nb。不过这个时候 GFW 也已经研发完了。

  • [C] 如果将其视为 bug 而不是 feature 的话,漏洞实在太多,打一两个补丁不解决问题,非重做不可。另外 IP 碎片和 TCP 流重组没有做特别研究,即使有漏洞实用性也不会很高。

  • [03a] 杨武, 方滨兴, 云晓春, 张宏莉. 基于骨干网的并行集群入侵检测系统. 哈尔滨工业大学学报. 2003-5-15.

  • [03b] 陈训逊, 方滨兴, 李蕾. 高速网络环境下入侵检测系统结构研究. 计算机研究与发展. 2003-7-15.

  • [05a] 张兆心, 方滨兴, 胡铭曾. 支持 IDS 的高速网络信息获取体系结构. 北京邮电大学学报. 2005-2-25.

  • [05b] 张伟哲, 方滨兴, 胡铭曾, 刘欣然, 张宏莉, 高雷. 计算网格环境下基于多址协同的作业级任务调度算法. 中国科学 E 辑:信息科学. 2005-12-25.

  • 猜测之数字准确性无担保,请自行把握。

0 Comment:

user_name1 day ago
Reply
Body
本站唯一地址:12ddrrRKkABAWTU48ZL3THfypHtVJ3aVF5
域名短网址(可能會被篡改):ChineseCensorship.bit
This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More