Dyn事件还将重演 大规模DDoS断网正在袭来
作者: 日期:2018年03月02日 阅:3,894

检查你的DNS和人员准备,另外,千万做好冗余备份。

一项新研究提示,虽然应对措施成本相对低廉,但类似2016年Dyn公司DNS拒绝服务所致大规模断网事件仍有可能再次发生。

Dyn公司遭受的DDoS攻击让很多主流网站掉线近一天之久,推特、PayPal、Reddit、亚马逊和Netflix都遭到了连带伤害。这次攻击利用了百万台Mirai僵尸网络控制下的IoT设备,以高达1.2TBps的峰值流量淹没了Dyn公司的DNS服务,令其无法响应对客户网站的DNS请求。

对Dyn公司的攻击并没有以任何方式影响到PayPal或推特服务器,但平时懒得记网站IP而只记域名的普通用户还是无法访问这些网站,因为负责解析这些域名的DNS服务无法响应了。

攻击者并非国家支持的黑客,不过是别有用心的普通罪犯。安全大师布鲁斯·施奈尔当时曾写道:“罪魁祸首很可能是不满Dyn帮助布莱恩·克雷布斯指认两名以色列黑客运营DDoS租赁服务,并导致FBI对这两名黑客实施了抓捕。”

IoT设备很多都是出厂时就缺乏安全防护的,而且往往没有后续升级修复措施。随着此类设备的飞速增多,下一场针对DNS的DDoS攻击有可能规模更大,后果更严重。DNS提供商的集中化难辞其咎。

单点故障

DNS应该是分散的,但DNS的越来越集中化产生了单点故障。Dyn攻击的超级成功显露出DNS提供商过少,DNS服务过度集中,甚至能让大公司也面临服务中断的风险。

云计算服务面世以来,互联网基础设施越来越集中到少数提供商手上,这种情况是DNS的设计者们从未预想过的。回想当年,公司企业都是自己管理自己的DNS,管理员必须坐在办公室里管理一台台电脑,无论他是不是下一波商业革新的引领者,比如Uber。

虽然老牌公司依然倾向于自有DNS,但云即基础设施的兴起让新公司纷纷将一切事务外包到云端,包括DNS。

研究报告的作者之一约翰·鲍尔斯称:“DNS服务集中到少数公司手上会暴露出以往更分散的DNS模式所未见的单点故障问题。“Dyn攻击完美呈现了集中化的风险——对托管几十家主流网站和内容分发网络(CDN)的DNS提供商进行DDoS攻击,就能一次性搞摊一大部分的互联网。”

此研究报告中比较骇人的部分是,尽管DNS集中化的危险如此明显,却少有公司愿意拨冗实现备份DNS。

不汲取经验教训势必会重蹈覆辙

媒体对Dyn攻击的报道不可谓不多,预言家们也在宣传多样化DNS的必要性,但似乎并没有多少人听进去了。只有直接被DDoS攻击伤害到的那些才真正吸取了Dyn攻击的教训。

2016年底Dyn攻击发生前,超过90%的网站只使用一家提供商托管的域名服务器。攻击发生半年之后的2017年5月,还这么做的网站从92.2%降到了87.3%。吸取教训的网站并不多,且增加了备份DNS的那些主要还是直接经历掉线切肤之痛的Dyn客户。

就连如今已被Oracle收购的Dyn自身,也提供备份DNS服务,并鼓励其客户采用这项服务。Dyn架构总监安德鲁·沙利文称:“网站运营者的技术栈需要多样化,要选择支持多样化的各类组件,比如DNS服务、Web防火墙和DDoS防护。”

多样化外部DNS提供商的一大难点在于外部DNS通常捆绑搭售其他服务,比如CDN和DDoS防护等。举个例子,CloudFlare占据了被调查域名15%的DNS提供商市场份额,但该公司的DDoS防护服务却阻止了网站注册其他提供商管理的DNS。

该研究报告还揭示了一个趋势:新网站喜欢采用将DNS纳入服务产品套装的云平台。你可能会觉得亚马逊AWS能抵御任何DDoS攻击,但别忘了,曾经也是发生过亚马逊雇员一个手误就让S3简单存储服务掉线的事故的。只用一家提供商,那无论是事故还是攻击,都容易导致单点故障。

造桥的时候都知道要做冗余保护,怎么在建DNS基础设施的时候就忘了冗余备份呢?

怎样做DNS冗余备份

第一件事就是查清当前DNS设置。可以在域名服务器上执行以下命令:

  dig +ns ourdomain.com

如果返回的名字在你自己的域中,那就说明你是自己托管着DNS,可以考虑一下这是否符合自家公司的需求——对大多数公司而言这并非正确选择。如果你已经有了CDN提供商,那很有可能要么现有合同中已经包含了DNS服务,要么DNS作为附加服务提供;这种方式可以快速切换或添加提供商。

虽然低流量站点通常只列出2个域名服务器,但DNS是可以有8个的。最好全都用上,主DNS和备份DNS按6:2设置。希望有更多冗余的公司可按5:2:1的配置自托管。

DNS问题上令人惊讶的一点是,冗余备份根本不是什么新操作。早在1997年的 RFC 2182 中就立下了备份DNS最佳操作的规矩。RFC 2182 中写道:“每个域采用多个域名服务器的主要原因,是要让该域的信息能够在互联网上广泛而可靠地访问,即便其中一台域名服务器宕机了。”

虽然该RFC建议中有些内容已经过时,比如与另一家公司交换备份域的做法就太古早了,但避免中央故障点和确保冗余备份的基本原则还是没变的。提供商冗余不仅赋予了公司灵活扩展的能力,还能确保一家提供商出问题时公司的业务不掉线。

多样化,多样化,多样化

互联网上不能出现中央故障点,尤其是在租用僵尸网络的蠢货都能让主流网站掉线的时代。通过多样化DNS缓解该风险已成当今掉线威胁横行时代的规定动作。

这并不是什么很难完成的工作,也花不了多少钱,但却是个非常好的操作。对非常大的公司来说可能会有些困扰,但这不是借口。所有网络安全工作都比较麻烦,与其他预防性操作相比,弄个DNS冗余备份已经算是非常容易的了。

 

申明:本文系厂商投稿收录,所涉观点不代表安全牛立场!


相关文章