从谷歌宕机事件认识互联网工作原理,网络封锁

日期:2019-11-22编辑作者:明仕ms57服务器&运维

译者注:本文中提到CloudFlare是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由Project Honey Pot项目的三位前开发人员成立于2009年。2011年10月被华尔街日报评为最具创新精神的网络科技公司。

1.21那天发生了什么,由1.21联想补充……
  很多网站都上不去,域名解析都到了65.49.2.178这个IP地址 

今天,谷歌服务器经历了短暂的宕机事件,持续大概27分钟,对部分地区的互联网用户造成了影响。此次事件的原因深究起来需要进入互联网络那深邃的、黑暗的角落。我是CloudFlare公司的一名网络工程师,在帮助谷歌从此次宕机中恢复回来提供了一臂之力。下面就是事情发生的过程。

 先科普,再深挖
  dns查询类型 递归查询,迭代查询 
  DNS解析过程,这里使用linux的dig命令 详细显示 

大约在太平洋标准时间2012年11月5号下午6:24分/时间标准时间2012年11月6号凌晨2:24分,CloudFlare的员工发现谷歌的服务中断了。我们使用谷歌的电子邮件等服务,所以,当它的服务不正常时,办公室的人会很快发现。我在网络技术小组工作,因此我立刻接上网络查看是什么情况——是局部区域问题还是全球问题。

 pc与8.8.8.8的过程为递归查询
8.8.8.8与各个服务器之间为迭代  
  8.8.8.8缓存 不存在记录则向   全球根域名服务器查询 总共13个根域名服务器 a~m  (负责记录各后缀所对应的TOPLEVEL Domain Server[顶级域名根服务器]).                    

问题排查

16318   IN      NS      m.root-servers.net..                       16318   IN      NS      d.root-servers.net..                   16318   IN      NS      g.root-servers.net..                       16318   IN      NS      j.root-servers.net..                   16318   IN      NS      c.root-servers.net..                       16318   IN      NS      h.root-servers.net..                   16318   IN      NS      i.root-servers.net. 根域名.             16318   IN      NS      a.root-servers.net..          
16318   IN      NS      b.root-servers.net..                       16318   IN      NS      l.root-servers.net..                     16318   IN      NS      f.root-servers.net..                       16318   IN      NS      e.root-servers.net..                     16318   IN      NS      k.root-servers.net.          ;;

我很快就意识到,所有谷歌的服务我们都不能连接上——甚至包括连接 8.8.8.8,谷歌的公共DNS服务器——于是,我从追查DNS开始。

Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 250 ms 

dig +trace google.com

根域服务器向8.8.8.8 返回 .com[顶级域名根服务器]地址  8.8.8.8再向顶级域查询  (顶级域名根服务器中存储着[权威DNS服务器]) 
com.                    172800  IN      NS      f.gtld-servers.net.com.                  

下面是我在探测Google.com的域名服务器时得到的回复:

 172800  IN      NS      m.gtld-servers.net.com.                     172800  IN      NS      e.gtld-servers.net.com.            172800  IN      NS      a.gtld-servers.net.com.                    172800  IN      NS      d.gtld-servers.net.com.            172800  IN      NS      l.gtld-servers.net.com.                     172800  IN      NS      c.gtld-servers.net.com.            172800  IN      NS      b.gtld-servers.net.  顶级域com.         172800  IN      NS      i.gtld-servers.net.com.              172800  IN      NS      j.gtld-servers.net.com.                    172800  IN      NS      k.gtld-servers.net.com.            172800  IN      NS      h.gtld-servers.net.com.                    172800  IN      NS      g.gtld-servers.net.;;
Received 503 bytes from 192.33.4.12#53(c.root-servers.net) in 328 ms 

google.com. 172800 IN NS ns2.google.com.

顶级域向8.8.8.8返回 权威dns服务器、域名注册地的dns 
baidu.com.              172800  IN      NS      dns.baidu.com.baidu.com.              

google.com. 172800 IN NS ns1.google.com.

172800  IN      NS      ns2.baidu.com.baidu.com.         
172800  IN      NS      ns3.baidu.com. 权威dnsbaidu.com.              
172800  IN      NS      ns4.baidu.com.baidu.com.              
172800  IN      NS      ns7.baidu.com.;;
Received 201 bytes from 192.54.112.30#53(h.gtld-servers.net) in 406 ms

google.com. 172800 IN NS ns3.google.com.

8.8.8.8再向权威dns查询 
www.baidu.com.         
 1200    IN      CNAME   www.a.shifen.com.a.shifen.com.           
1200    IN      NS      ns1.a.shifen.com.a.shifen.com.           
1200    IN      NS      ns2.a.shifen.com.a.shifen.com.           
1200    IN      NS      ns3.a.shifen.com.a.shifen.com.         
  1200    IN      NS      ns5.a.shifen.com.a.shifen.com.          
1200    IN      NS      ns4.a.shifen.com.;; 
Received 228 bytes from 220.181.38.10#53(ns4.baidu.com) in 15 ms 
一直迭代查询,直到有一台DNS服务器可以顺利解析出这个地址为止。直到返回结果,或者失败8.8.8.8将这个结果发送给pc客户端。在这个过程中,客户端一直处理等待状态, 

google.com. 172800 IN NS ns4.google.com.

这是dns的一般过程

;; Received 164 bytes from 192.12.94.30#53(e.gtld-servers.net) in 152 ms

下面说下网站服务器使用双线接入技术,
一根联通线
一根电信线
为了给用户更快更好的浏览体验
当用户在浏览器地址栏上输入,网站域名时(例如www.hehe.com)回车时
如何鉴别用户线路?????走联通ip???还是走电信ip????

;; connection timed out; no servers could be reached

有几种技术   1 .自建BGP机房   2.智能DNS解析 3.网站双镜像  

无法探测到任何服务器的结果证明确实有什么地方出了问题。尤其是,这意味着从我们的办公室将连接不到任何的谷歌DNS服务器。

1.自建BGP机房
BGP(边界网关协议)主要用于互联网AS(自治系统)之间的互联,BGP的最主要功能在于控制路由的传播和选择最好的路由。
通过BGP协议将此段IP地址广播到其它的网络运营商的网络中。使用BGP协议互联后,网络运营商的所有骨干路由设备将会判断到IDC机房IP段的最佳路由,以保证不同网络运营商用户的高速访问。  
服务器只需要设置一个IP地址,最佳访问路由是由网络上的骨干路由器根据路由跳数与其它技术指标来确定的,不会占用服务器的任何系统资源。服务器的上行路由与下行路由都能选择最优的路径,所以能真正实现高速的单IP高速访问。 
用BGP协议还可以使网络具有很强的扩展性可以将IDC网络与其他运营商互联,轻松实现单IP多线路,做到所有互联运营商的用户访问都很快。这个是双IP双线无法比拟的。 
成本较大  

我开始网络层查找问题,看看是否是在这个通信层出了问题。

2.智能DNS解析 
把自己的域名DNS服务器选为可以提供 智能DNS解析 的运营商,比如dnspod,等等
*去dnspod申请一个账号,在这个账号里会给你dnspod官方域名解析服务器的地址(比如  f1g1ns1.dnspod.net) 
*去自己注册域名的域名服务商那里 把自己的域名解析地址设置为 dnspod的服务器比如 ( f1g1ns1.dnspod.net)这样当网站使用电信 联通 双ip接入时 。网站浏览用户在浏览器地址栏输入网站域名,回车时,请求传递到dnspod智能DNS解析服务器,其根据用户的因素及相关算法 返回给用户 联通或者电信 ip地址。
成本低,设置较快。 

PING 216.239.32.10 (216.239.32.10): 56 data bytes

3. 网站镜像
这种越来越少了 ,在用户进入网站首页时让用户自己选择访问线路,联通or电信     

Request timeout for icmp_seq 0

能看到这里的应该是专业人员或者网络爱好者,2.14.1.21 dns大事故,个人联想 
很多网站都上不去,域名解析都到了65.49.2.178这个IP地址
谁攻击的dns服务器?能导致这么多网站被错误解析?谁有这样的实力和胆量呢?
被攻击的是 com通用顶级域的根    国内大面积(有数据称达2/3) 
外国灰客?网络雇佣兵?蓝翔技校寒假作业?
再次联想

92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217): Time to live exceeded

补充下dns另类知识

这里出现了奇怪的信息。通常,我们不应该在谷歌的路由信息中看到一个印度尼西亚的网络服务提供商(Moratel)的名字。我立即进入一个CloudFlare的路由器中查看发生了什么事。与此同时,Twitter上世界其它地方的报告显示了我们并不是唯一遇到问题的地方。

1.dns劫持: 
   通过劫持了DNS服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析结果,导致对该域名的访问由原IP地址转入到修改后的指定IP

互联网路由

2.DNS污染 : 
       通常的DNS查询没有任何认证机制,而且DNS查询通常基于的UDP是无连接不可靠的协议,因此DNS的查询非常容易被篡改,
 DNS污染的数据包并不是在网络数据包经过的路由器上,而是在其旁路产生的。所以DNS污染并无法阻止正确的DNS解析结果返回,但由于旁路产生的错误数据包发回的速度较国外DNS服务器发回的快,操作系统认为第一个收到的数据包就是返回结果,从而忽略其后收到的数据包,从而使得DNS污染得逞。

为了理解是出了什么问题,你需要知道一些互联网是如何工作的基础知识。整个互联网是由很多的网络组成,这些网络被称为是“自治系统(AS)”。每个网络都有一个唯一的数字来标志自己,被称为AS号。CloudFlare的AS号是13335,谷歌的AS号是15169。各个网络通过一种叫做边缘网关协议(BGP)的技术互相连接。边缘网关协议被称为是互联网的粘合剂——由它来声明哪个IP地址属于哪个网络,由它来建立从某个自治网络到另外一个自治网络的路由。一个互联网“路由”跟这个词的表意完全一样:由一个自治网络里的IP地址到另外一个自治网络里的另一个IP地址的路径。

所以有很多“危险网站",为了防止网友访问,对社会造成危害,xx就采用dns污染的方法。
你输入域名回车进行dns解析时,污染就生效了,一个假的dns数据回复包迅速发到你的电脑,告你你一个错误的ip地址或者一个路由黑洞,让你无法访问, 

边缘网关协议是基于一个相互信任的体制。各个网络基于信任的原则告诉其它网络哪个IP地址属于哪个网络。当你发送一个数据包,或发送一个穿越网络的请求,你的网络服务提供商会联系它的上游提供商或对等提供商,询问它们从你的网络服务提供商到网络目的地,哪条路线最近。

有些人会采用直接输入ip地址(a.b.c.d)的方法来访问“非法网站”,以此来躲避dns污染,长_.城采用以下措施进行屏蔽
*路由扩散技术 
     使用的静态路由其实是一条错误的路由,而且是有意配置错误的,其目的就是为了把本来是发往某个IP地址的数据包统统引导 到      一个“黑洞服务器”上,而不是把它们转发到正确目的地。这个黑洞服务器上可以什么也不做,这样数据包就被无声无息地丢掉了       更多地,可以在服务器上对这些数据包进行分析和统计,获取更多的信息,甚至可以做一个虚假的回应。 
    通过这种方法封锁特定IP地址需要修改路由表

不幸的是,如果当一个网络发出声明说某个IP地址或某个网络在它的内部,而事实不是这样,如果它的上游网络或对等网络信任了它,那么,这个数据包最终将会迷路丢失。这里发生的就是这个问题。

*ACL 访问控制列表 
   很简单,很容易理解
   在出口处作如下配置 
举例:
access-list 101 deny tcp any host a.b.c.d eq www
其实还可以再简单些 在入口方向
access-list 1 deny udp host a.b.c.d  谁都进不来

我查看了边缘网关协议传递的谷歌IP的路由地址,路由指向了Moratel (23947),一个印度尼西亚的网络服务提供商。我们的办公室在加利福尼亚,离谷歌的数据中心并不远,数据包绝不应该经过印度尼西亚。很有可能是,Moratel声明了一个错误的网络路由。

*IP地址特定端口封锁 

当时我看到的边缘网关协议发来的路由是:

火长城配合上文中特定IP地址封锁里路由扩散技术封锁的方法进一步精确到端口,从而使发往特定IP地址上特定端口的数据包全部被丢弃而达到封锁目的,使该IP地址上服务器的部分功能无法在中国大陆境内正常使用。

p>[email protected]> show route 216.239.34.10

经常会被防火长城封锁的端口:

inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden)

SSH的TCP协议22端口PPTP类型VPN使用的TCP协议1723端口,L2TP类型VPN使用的UDP协议1701端口,IPSec类型VPN使用的UDP协议500端口和4500端口,OpenVPN默认使用的TCP协议和UDP协议的1194端口TLS/SSL/HTTPS的TCP协议443端口Squid Cache的TCP协议3128端口

+ = Active Route, - = Last Active, * = Both

在中国移动、中国联通等部分ISP的手机IP段,所有的PPTP类型的VPN都遭到封锁。

216.239.34.0/24 *[BGP/170] 00:15:47, MED 18, localpref 100

2011年3月起,防火长城开始对Google部分服务器的IP地址实施自动封锁(按时间段)某些端口,按时段对www.google.com(用户登录所有Google服务时需此域名加密验证)和mail.google.com的几十个IP地址的443端口实施自动封锁,具体是每10或15分钟可以连通,接着断开,10或15分钟后再连通,再断开,如此循环,使中国大陆用户和Google主机之间的连接出现间歇性中断,使其各项加密服务出现问题。[19]Google指中国这样的封锁手法高明,因为Gmail并非被完全阻断,营造出Google服务“不稳定”的假象,表面上看上去好像出自Google本身。[20]

AS path: 4436 3491 23947 15169 I

*无状态tcp协议重置      

> to 69.22.153.1 via ge-1/0/9.0

监控特定IP地址的所有数据包,若发现匹配的黑名单动作(例如TLS加密连接的握手),其会直接在TCP连接握手的第二步即SYN-ACK之后伪装成对方向连接两端的计算机发送RST数据包(RESET)重置连接,使用户无法正常连接至服务器。

我查看了其它路由,比如谷歌的公共DNS,它同样被劫持到了相同的(不正确的)路径:

这种方法和特定IP地址端口封锁时直接丢弃数据包不一样,因为是直接切断双方连接因此封锁成本很低,故对于Google的多项(强制)加密服务例如Google文件、Google网上论坛、Google+和Google个人资料等的TLS加密连接都是采取这种方法予以封锁。

inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden)

        

+ = Active Route, - = Last Active, * = Both

外国网络安全专家都认为,这次DNS污染事件影响之广、范围之大在国内尚属首例,远远超出一般黑客的能力范围。“很可能与主干网络的设置调整有关。” 
极有可能是国家工作人员手残,在设置参数时将封锁特定ip设置为导向特定ip,so,所有网站dns解析全部流向此ip,原因在此。  

8.8.8.0/24 *[BGP/170] 00:27:02, MED 18, localpref 100

 

AS path: 4436 3491 23947 15169 I

> to 69.22.153.1 via ge-1/0/9.0

[email protected]> show route 8.8.8.8

路由泄漏

像这样的问题在行业内被认为是起源于“路由泄漏”,不是正常的,而是“泄漏”出来的路由。这种事情并不是没有先例。谷歌之前曾遭受过类似的宕机事件,当时推测是巴基斯坦为了禁止YouTube上的一个视频,巴基斯坦国家ISP删除了YouTube网站的路由信息。不幸的是,他们的这种做法被传递到了外部,巴基斯坦电信公司的上游提供商——电讯盈科(PCCW)信任了巴基斯坦电信公司的做法,把这种路由方式传递到了整个互联网。这个事件导致了YouTube网站大约2个小时不能访问。

图片 1

今天发生的事情属于类似情况。在Moratel公司的某个人很可能是“胖手指”,输错了互联网路由。而电讯盈科,Moratel公司的上游提供商,信任了Moratel公司传递给他们的路由。很快,这错误的路由就传到了整个互联网。在边缘网关协议这种信任模式中,与其说这是恶意的行为,不如说这是误操作或失误。

修复

解决方案就是让Moratel公司停止声明错误的路由。作为一个网络工程师,尤其是像CloudFlare这样的大网络公司里工作的工程师,很大一部分工作就是和其它世界各地的网络工程师保持联络。当探明问题后,我联系到了Moratel公司的一位同事,告诉他发生了什么事。他大概在太平洋标准时间下午6:50分/世界标准时间凌晨2:50分修复了这个问题。3分钟后,路由恢复了正常,谷歌的服务重新可以工作了。

从网络传输图上观察,我估计全球整个互联网用户的3-5%收到了此次宕机事故的影响。重灾区是香港,因为那是电讯盈科的总部。如果你所处的地区在当时无法访问谷歌的服务,你现在应该知道是什么原因了。

构建更好的互联网

我说这些就是想让大家知道我们的互联网上如何在一个相互信任的机制下建立起来的。今天的事故说明,即使你是一个像谷歌这样的大公司,外部你无法掌控的因素也会影响到你的用户,让他们无法访问你,所以,一个网络技术小组是非常必要的,由他们来监控路由,管理你与世界的联系。CloudFlare公司每天的工作就是确保客户得到最佳的路由。我们照看互联网上的所有网站,确保他们的以最快传输速度提供服务。今天的事情只是我们工作内容的一个小片段。

Honey Pot项目的三位前开发人员成立于2009年。...

本文由明仕ms577发布于明仕ms57服务器&运维,转载请注明出处:从谷歌宕机事件认识互联网工作原理,网络封锁

关键词:

选择服务器托管比起自建机房有什么优势,选择

服务器托管是指为了提高网站的访问速度,将您的服务器及相关设备托管到具有完善机房设施、高品质网络环境、丰...

详细>>

Web服务器保持安全的秘诀是什么,Web安全实践

ApacheHTTP服务器是世界上最常见的Web服务器软件,这点是明摆着的。据最近一项调查显示,全世界运行ApacheHTTP的网站数...

详细>>

搭建完美的媒体服务器

本教程介绍了如何安装Ubuntu 11.10OneiricOcelot)和必需的所有程序,以便完美的媒体服务器下载你的所有媒体,并流式传...

详细>>

ARM内核全解析,十问ARM处理器究竟强在哪

近日,ARM公司宣布推首款64位的ARMv8架构的处理器,这对于ARM公司是一个足以载入芯片发展史册的日子,其在全球三地...

详细>>