Azure中断3小时还被劫持，AWS被2.3TbDDos攻击，IBM云中断5小时：云巨头的冰与火

    
    无论一线二线，无论巨头还是小霸王，云市场的玩家们，都不容易。

01

—

    

    今天，Office 365 and Azure Active Directory在澳大利亚和新西兰，均不能访问。

    Office 365状态页上是一则不痛不痒的信息：

    Azure的状态页上则显示一切正常。

    这让用户很愤怒。

    不过一段时间后，还是有了个回应：

We understand the urgency of getting this resolved and thank you for your patience so far. While we currently don't have an ETA on when this will be resolved, we will be sure to update you as well as the status page as we continue investigating. ^TN

— Azure Support (@AzureSupport) June 15, 2020

    Office365在2019年11月也发生宕机，当时微软CEO纳德拉正在台上对着观众演讲。

    这是最新的微软官方更新：

Updated to add at 0110 UTC, June 15

Microsoft's Office 365 status page now says: "We're investigating a potential token issue that may be preventing users from authenticating to multiple Microsoft 365 services or features."

Final update at 0255 UTC, June 15

At around 02:00 UTC on the 15th Microsoft said it "redistributed traffic in the affected infrastructure and have confirmed that service has been restored." The Office 365 Status page currently reads: "There are currently no known issues preventing you from signing in to your Office 365 service health dashboard."

    附带一个用云挖矿的事儿。

    

    大家对挖矿都不陌生，挖矿公司上市的都有，前段时间更有挖矿公司内部抢班夺权的狗血剧。

    服务器被劫持免费支持别人挖矿的新闻，估计大家也偶尔耳闻。

    只是这回的动作大了点，目标是微软的Azure云。

    6月13日，微软警告说，黑客们正在劫持Kubeflow。Kubeflow是一个用于Kubernetes的机器学习（ML）工具包，并利用Microsoft Azure中运行的云计算资源来挖掘加密货币。

    Kubeflow是一个开源项目，它支持Kubernetes上的机器学习堆栈。Azure安全中心的安全研究软件工程师Yossi Weizman在博客中写道：“用于ML任务的节点通常相对强大，在某些情况下还包括GPU”。“这一事实使用于ML任务的Kubernetes群集成为挖掘加密货币活动的完美目标，而这正是这次攻击的目标。”

    因为Kubeflow是一个容器化服务，其中各种任务作为集群中的容器运行，如果黑客能够[获得]对Kubeflow的访问，他们有多种方式在集群中运行恶意代码，”Weizman解释说。


    此外，Kubeflow通过部署在集群中的仪表板公开其用户功能界面。仪表板由Istio入口网关公开，该网关应只能在内部访问。但是，有些用户将Istio服务的设置修改为负载平衡器，这会将其公开到公共internet。

    魏茨曼写道：“通过向互联网公开该服务，用户可以直接（获得）访问仪表板的权限。”。但是，此操作允许不安全地访问Kubeflow仪表板，这允许任何人在Kubeflow中执行操作，包括在群集中部署新容器。

    一旦攻击者有权访问仪表板，他们就有多种方法在集群中部署后门容器，当然他们可以使用这种访问来运行加密货币矿工。

02

—

    最近AWS有半炫耀的成分，公开了其受攻击的一些情况。你可以在这里下载这份报告：https://aws-shield-tlr.s3.amazonaws.com/2020-Q1_AWS_Shield_TLR.pdf。

    AWS报告说2020年2月检测到2.3Tb的DDos攻击，持续了三天，意图瘫痪AWS，但没有成功。
    

    对AWS的攻击是基于CLDAP反射的攻击，比AWS之前看到的任何攻击都要大44%。

    就这次尝试的规模而言，它几乎是2018年瘫痪GitHub的1.3 Tbps攻击的两倍，或者是2016年著名的瘫痪Dyn的约1 Tbps 僵尸网络DDoS。

    反射攻击滥用合法协议，通过使用伪造的IP地址向第三方服务器发送请求。
响应的内容则要大得多，并返回到不知情的受害者的欺骗IP地址。（CDN公司Akamai在2017年发现，78071台主机对最初的52字节查询响应了1500多字节的数据）。LDAP反射攻击滥用轻量级目录访问协议（LDAP）的无连接版本。

    AWS的威胁报告显示，AWS经受住了这次攻击，但此前，这家公共云巨头的在2019年10月因遭受DDoS攻击而下线。

    AWS指出四种占比较高的攻击方式：
    •Docker unauthenticated RCE，未经授权试图利用Docker引擎API构建容器。
    •SSH入侵尝试，使用常用的凭据或其他攻击手段寻找获得对应用程序未经授权的访问。
    •未经验证的Redis RCE，嫌疑人试图利用Redis数据库的API远程访问应用程序，访问数据库内容，或使最终用户无法访问。
    •Apache Hadoop YARN RCE，未经授权，试图利用Hadoop集群资源管理系统的API并执行代码。

    供给的动机主要是加密货币挖掘、用以DDoS攻击或数据渗漏。

    

03

—

    与上述攻击相比，IBM遭遇的情况则要严重得多：全部服务瘫痪。

    6月11日，IBM声明称，云业务宕机事件是由第三方网络提供商非预期地调整IBM对外网络路由，导致其全球流量一度严重受阻。声明中还提到，整个事件持续时间是从北京时间6月10日早上5：55到早上9：30。两个小时后该公司再次发推表示，所有的IBM云服务已重启。

    前不久的3月份，IBM在达拉斯的机房遭遇停电，随后在4月份发表了一篇关于保持“高可用性”和“零停机时间”的论文，他们的营销团队仍在进行这方面的公关工作。

    IBM宣布了这次事故归咎于“外部网络提供商用错误的路由瘫痪了IBM云网络”。然而，Techzim从一个技术来源处收到了一份信息，该技术来源自始至终都在监视停机情况，并显示了IBM云网络本身发生的问题。
    “我收到了一些IBM托管服务的故障警报，包括Softlayer的域名服务器，然后不久就看到Twitter爆炸了。追踪到IBM IP的流量显示，流量正常地到达本地PoP，但随后被路由到华盛顿特区，而不是预期的closer/local源。这让人想起去年谷歌的问题。责怪外部供应商是毫无道理的；如果是这样，IBM可能已经禁用这些路由规则，并解决了问题。”

    如果一家云公司一年没有几次大事故，那它就不能称之为云巨头。

    比如201年6月，谷歌遭受了一次巨大的中断，影响了其在美洲和欧洲部分地区的大部分服务。这次中断被解释为为“网络拥塞”，因为谷歌错误地将大量的的流量路由到其美国东部数据中心。

    但IBM的事故所展示出来的信息，显然复杂得多。
    
    首先，Google大故障后不到一年，IBM Cloud也几乎出现了同样的问题。他们将所有的数据发送到一个自己的一个机房，从而实现了对自己的攻击。顺便一句，微软今天的故障也是类似的原因。

    云提供商遭受中断和网络故障是很常见的，但这种严重性的问题被拖延如此长时间是不寻常的。IBM Cloud的Twitter 被大量的@淹没，但几个小时内保持完全沉默，这对一家规模庞大的公司来说并不是好兆头。更糟糕的是，他们的状态页面被托管在同一个网络上，并且在大部分云业务中断期间完全离线，这使得陷入困境的客户无法知道发生了什么。IBM Cloud拥有许多大客户，包括会计专家德勤（Deloitte）、技术巨头松下（Panasonic）、美国航空公司（American Airlines）、沃达丰（Vodafone）、比特力（Bitly）、安联（Allianz）等，因此这次中断无疑影响了全球数百万最终用户。该公司还服着几家美国政府部门，这些部门也都受到了影响。

    IBM Cloud源于2013年收购托管提供商Softlayer，这是其当前服务的基础。Softlayer是一家在美国和欧盟地区拥有数据中心的IDC，但由于2011年的云计算热潮，它开始走红。在2016年，Softlayer更名为IBM的名字，然后在2018年完全融入IBM云。
   
    一次这样的事故不会让IBM出局，但无数这样的大大小小事故，会让IBM云从云巨头的名单里出局。

04

     
    云巨头是可以犯错的，各种各样的事故都可以，当然，前提是你得是巨头，已经积累了足够的信用。

    如果像当时的盛大云，或者一些更小的创业公司，一两次，甚至一次大的事故，就可能造成几乎致命的打击。  因为这些公司的信用池太浅。

    这也是大公司与创业公司不一样的地方：大公司的品牌天然自带知名度、信任度。

    这是大公司从事新业务天然的优势。当然，如果加上大公司背后的软硬资源，这优势就更大了。

    唯一能跟这些优势比拟的，大概就是先发优势。

    这也是AWS在亚马逊的财力和品牌知名度并不明显优势的条件下，能持续领先，并经受住微软和谷歌的攻击的原因。

    而创业公司的先发优势，则容易被大公司的资源优势抵消。

    而第三个因素，则是执行力。这包括专注力、创新力、效率等。这是很多创业公司能在巨头打压下发展的原因。也就是说，有先发优势和执行力，小公司是能够抗衡大公司的资源优势的。

    AWS曾经有先发优势，有一定资源优势，有一定执行力，所以持续领先。
    微软丧失先机，但有资源优势，有一定执行力，所以能跟上节奏。
    谷歌丧失先机，但有资源优势，当然跟微软是不同的，也有执行力，所以也能尾随AWS和微软之后。
    IBM很显然，没有先机，有一定资源优势，相对于创业公司当然优势巨大，但相对于这些巨头只能说某些方面有一定优势，但执行力较差，所以跟得很吃力。
    Oracle当然也没有先机，也有一定资源优势，但并不明显，执行力还可以，所以也快要掉队的感觉。

    一个事故不足以影响大局面，但很多事故合在一起，或者事故背后的原因和反映的执行力，则可能影响公司的竞争力。

    从这些层面讲，巨头间的竞争，更激烈，无数的点才能汇聚成面上的竞争优势劣势；一旦形成一个局面，要想打破，则要付出巨大的持续的代价。


    比如第二名说我想个大招，翻身上马，就能干掉老大。这个可能性很小，几乎没有。实际情况是，你经常想招，不断上马，才可能维持住第二名。因为第一名也在想各种招干掉你，第三名也在想各种招挤掉你。

    所以，巨头之间的平台型业务的竞争，不要想着“一招制胜”。至于行业的中小公司，这就更不可能了。

    这让中小公司很无奈。

    常有中小公司，说我想个什么策略，搞个什么行业方案，抓个什么新兴热点，然后力压群马，跻身行业前三。

     这是不可能的。

    大公司之间的招，那也只适合大公司之间玩，小公司跟着玩，不但不能一招制胜，很有可能是翻身落马，被巨头无意间践踏而亡。

    

转载联系文末二维码授权，并采用转载文章格式（公众号平台首页“新建群发”->转载文章）转载，转载后文首应自动出现公众号链接，保留文末二维码。未经授权或未按格式转载一律视为侵权。