DigitalOcean对接管2万个DigitalOcean域的响应

编辑：DigitalOcean似乎从这篇文章中得到了很多支持，所以我想指出，我觉得DigitalOcean在这种情况下的反应是完全有道理的（他们看到了异常情况，并且制止了它）。我唯一希望做的事情与众不同，那就是在我被禁止后，域名从我的帐户中删除了。从测试到与他们联系有几个小时的延迟，理想情况下，我应该提前与他们联系。我没有接触理论而不是概念证明的主要原因是因为我认为由于缺乏证据，该理论将被忽略（我过去的经验也是如此）。总的来说，我对DigitalOcean的安全团队的印象非常积极，将来我肯定会更加主动地与他们联系。

DigitalOcean是类似于Amazon Web Services或Google Cloud的云服务提供商。他们提供云DNS托管作为其产品系列之一-有关如何设置您的域以使用其DNS的不错指南，请点击此处。花一点时间仔细阅读一下，看看您是否可以在其域名设置过程中发现任何潜在问题。

乍一看，它似乎是一个非常易于使用的系统。例如：无需进行讨厌的域验证即可阻止您向帐户添加任意​​域的能力，无需回忆域的WHOIS上的用户，也无需像Cloudflare这样的系统将域设置为特定的名称服务器。实际上，您要做的只是以下几点：

“在“网络”部分中，单击“添加域”，然后在下一页上填写您要连接到的服务器的域名字段和IP地址。”

因此，如果您愿意，可以立即将我的域名thehackerblog.com添加到您自己的DigitalOcean帐户中（假设其他人都没有这样做）。这就提出了一些有趣的问题，例如“人们可以阻止我将我的域名导入DigitalOcean吗？”并且，“当我从DigitalOcean删除域但忘记更改名称服务器时会发生什么？”。这些是很好的问题，但是在我们回答之前，我们将先绕道另一云提供商，看看它们的实现有何不同。

Amazon Web Services或AWS还以其产品系列Route53的形式提供云DNS托管。作为测试，我们将尝试设置域名thehackerblog.com的过程。如果您想自己尝试，可以在这里查看AWS的官方文档。第一步是单击Route53控制面板左上角的“创建托管区域”按钮。现在，我们将填写我们希望使用的域以及简短评论，以及是否希望将该DNS区域公开。最后，我们点击create，并进入我们新创建区域的DNS管理面板。 NS记录类型已预先填充了一些随机生成的名称服务器。例如，尝试此操作后收到的名称服务器列表如下：

上面的内容非常重要-如果我为thehackerblog.com创建了一个区域，而您执行的操作相同，则我们将获得不同的名称服务器。这样可以确保，如果我从我的AWS账户删除区域文件，则没有人可以接管我的域名，因为名称服务器是我的账户专用的。因此，如果我删除了我的域并想要接管该域，则必须继续尝试，直到获得与上述相同的名称服务器集为止。否则，我的域将指向您控制之外的其他名称服务器。

回到DigitalOcean，以下问题的答案是：“当我从DigitalOcean删除域但忘记更改名称服务器时会发生什么？”变得清晰。如果您从帐户中删除域，那么任何人都可以立即将其重新添加到自己的帐户中，而无需任何所有权证明并接管该域。

注意到可能发生的问题是一回事，但是证明确实确实发生了另一件事是另一回事。在不尝试将Internet上的每个域都添加到我们的DigitalOcean帐户的情况下，我们如何才能找出此问题是否是系统性的和常见的？无论如何，我们如何获得每个域名的列表？

首先，判断域是否已添加到DigitalOcean帐户的一种重要方法是执行常规DNS查询，并查看DigitalOcean域名服务器的响应方式。例如，我们将使用alert.cm，其名称服务器设置为DigitalOcean，但未在任何DigitalOcean帐户下列出：

[受电子邮件保护]〜>挖掘NS alert.cm @ ns1.digitalocean.com。 > DiG 9.8.3-P1 > NS alert.cm @ ns1.digitalocean.com。;;全局选项：+ cmd ;;得到了答案：;; ->> HEADER <<-操作码：QUERY，状态：拒绝，id：53736 ;;标志：qr rd;查询：1，答案：0，权限：0，附加：0；警告：请求递归但不可用；问题部分：; alert.cm。 IN NS ;;查询时间：51毫秒；服务器：173.245.58.51＃53（173.245.58.51）;;时间：2016年8月23日星期二23:09:00； MSG大小RCVD：26

从上面的dig输出中可以看出，DigitalOcean域名服务器返回了DNS REFUSED（RCode 5）错误，表明该域名服务器拒绝响应我们执行的NS记录查询。这为我们提供了一种简便而轻巧的方法，可以区分出DigitalOcean帐户下当前列出的域和未列出的域。

这解决了问题的一部分，但是以这种方式检查Internet上的每个域仍然非常耗时。此外，我们如何获取Internet上每个域名的列表？答案是获取各种顶级域（TLD）的区域文件的副本。首先，我们将获取.com和.net TLD的区域文件，因为出于研究目的可从Verisign轻松获取它们。区域文件包含现有的每个.com和.net域及其对应的名称服务器。通过遍历这些区域文件，我们可以准确地找出有多少.com和.net域名使用DigitalOcean进行DNS托管。在撰写本文时，两个TLD的计数如下：

合并后，总共有187,930个域名以DigitalOcean作为其DNS提供程序。现在，我们可以查询所有这些域，以检查DNS拒绝的错误，以查看它们是否未在DigitalOcean帐户下列出（并因此可以被接管）。经过简短的Python脚本和几个小时的DNS查询，我们就能枚举所有易受攻击的域（至少在前面提到的两个TLD中）。最终计数为21,598个域，这些域在查询时返回了DNS REFUSED错误。通过它们的API将这些域添加到我的DigitalOcean帐户后，实际数字却接近了19,500个域（因为DNS方法似乎并非100％准确）。对于添加到我的帐户的所有域，将基本域的单个DNS A记录添加到EC2实例。这样做是为了了解为什么这么多的域最终以这种状态出现，结果令人惊讶。

虽然我希望大多数域都是尚未配置的纯垃圾邮件/垃圾域（例如，可能都属于一个域经销商），但事实并非如此。接收器服务器只是一个标准的Nginx Web服务器，它返回空白网页并记录Web请求。在将服务器启动几天后，访问日志的大小已增长到1.8GB，并且不断有不断涌入的请求流。其中大多数来自希望尽快抓取网络的搜索引擎，这不足为奇（约80％的流量来自蜘蛛），但是其余的都是合法用户，他们正在导航到现在重定向的网站。

在消灭了各个领域并证明该理论实际上是正确的之后，我联系了DigitalOcean的安全团队来描述该问题（使用其安全页面所指定的PGP）。他们的回应如下：

感谢您发送此信息。这是我们平台中已知的工作流程。我们致力于不断改善客户的体验，并一直在研究减少您描述的行为类型的方法。

因此，从本质上讲，他们知道并且将来可能会寻找减轻这种行为的方法，但他们似乎并未制定任何立即的计划。

另外，我的DigitalOcean帐户已被锁定。这使我无法进行下一步操作：将所有DNS都更改为指向127.0.0.1，从而有效地阻止了流量。当询问支持人员为何我的帐户被锁定时（尽管我有一些想法），我收到以下答复：

我了解这可能会带来不便，但我们将无法为您提供托管服务。

因此，没有任何理由禁止该禁令，也没有进一步的支持。这使我处于无法自拔的状态，被困在我一直沉迷的所有流量中。由于我无法访问自己的帐户来更改域的DNS，因此我一分钟无法收到来自各个站点的数千个请求。我无法拆除EC2污水处理服务器，因为弹性IP可能会重新分配给更具恶意的人，因此我必须付费以保持其正常运行（不确定的时间）。虽然我已停止服务器上的所有服务以保护意外访问这些网站的用户的隐私，并存储了访问日志，但我无法阻止大量的流量。身为这个尴尬的职位，我联系了DigitalOcean的团队，以查看它们是否可以协助从我的帐户中删除域名（使域名再次变得脆弱）或将DNS扩展到127.0.0.1。我收到了安全团队中某人的非常有帮助的答复，看来他们会调查一下。

这提供了一些有趣的见解，说明了为什么使用唯一名称服务器导入域名的方式如此普遍（以防止出现此问题）。值得一提的是，任何使用非唯一名称服务器进行域名导入的系统都可能会受到这种完全相同类型的攻击模式的影响（注册服务商或域名停放服务是什么？）。对该领域的进一步研究可能会产生相似的结果。