这是一个旧的（一年多）帖子，它已经在我的队列中排了一段时间。有些东西可能已经过时了。

许多 Web 管理员使用Cloudflare来屏蔽其服务器的 IP 地址以防止 DDoS 攻击。Cloudflare 的工作原理是位于客户端和服务器之间。由于 Cloudflare 作为中间人运行，服务器的 IP 永远不需要向公众透露，因为公共客户端通过 Cloudflare 连接。任何攻击都会首先路由到 Cloudflare，后者可以提供防御并保护源服务器。不幸的是，攻击者仍然可以通过许多其他方式解析原始服务器的 IP 地址，绕过 Cloudflare 的保护并直接攻击源。

在这篇文章中，我将重点介绍一些方法，简要介绍它们如何/为什么工作，并给出修复它们的步骤。

DNS解析

背景
几乎所有“Cloudflare IP 解析器”都使用的最基本技术是暴力破解 DNS 记录。但首先，让我们回顾一些有关其工作原理的背景信息。假设您是 example.com 的网络管理员，IP 地址为 111.111.111.111。

Cloudflare 的经典图是这样的：

简而言之，您将 DNS 管理移交给 Cloudflare。您域的 A 记录（在图中表示为“您的裸网站”）现在切换到 Cloudflare IP 地址（“Cloudflare 的全球分布式网络”。现在，与 example.com 的所有连接都将发送到 Cloudflare 的 IP 地址（例如，222.222。 xxx.xxx），而不是您的原始服务器（例如 111.111.111.111），并且 Cloudflare 会在访问者和您的原始服务器之间反向代理请求。

问题是 Cloudflare 仅代理从开放互联网到服务器 IP 地址的 HTTP/HTTPS 连接（端口 80/443）。所以你将无法通过example.com访问源服务器上运行的其他服务；Cloudflare 服务器不响应 FTP（端口 21）、SSH（端口 22）、cPanel（端口 2082）等……那么管理员如何访问这些服务？

解决方案只是创建一个新的 DNS 记录，例如指向您原始 IP 地址的 direct.example.com。当您需要连接到原始 IP 时，您只需使用 direct.example.com 而不是 example.com。

攻击
现在，假设您是攻击者。通过 ping example.com 和 www.example.com，您会发现该网站启用了 Cloudflare，这意味着 example.com 和 www.example.com 都有一个属于 Cloudflare 的 IP 地址。

使用上面“背景”部分中的信息，您知道站点管理员可能有其他子域，其记录直接指向原始 IP，不受 Cloudflare 保护。现在，您可以简单地猜测它们是什么并尝试 ping 它们。一些流行的有“mail.example.com”、“ssh.example.com”、“ftp.example.com”和“direct.example.com”。您还可以运行“host -a example.com”来列出公布的 DNS 记录。

这种方法是所有“Cloudflare IP 解析器/脚本”使用的方法。

可能的修复
Cloudflare 网站的 DNS 解析一直是一种常见的攻击媒介，因此许多细心的网络管理员已经确保他们没有任何悬空的子域。如果您想访问没有任何子域的原始服务器，您可以创建一个完全独立的域（例如，connect.otherdomain.com）或直接使用您服务器的 IP 地址进行连接。

DNS/托管历史

背景
如果您是为您的域 (example.com) 设置 Cloudflare 的站点管理员，则您的网站很可能已经上线并托管在公共 IP 地址（例如 111.111.111.111）上。

如果某个网站在同一 IP 上托管了一段时间（约 1 个月），则公共网络爬虫很可能已经访问过它。这些爬虫中的许多都保存了这些信息，以后可以访问这些信息。

攻击攻击
者可以简单地在托管历史数据库中查找网站，并在设置 Cloudflare 之前找出原始 IP 地址。

免费服务包括Netcraft和Cloudflare-watch。

可能的修复
幸运的是，修复非常简单。如果您要启动新网站并希望隐藏源服务器的 IP，请确保在将域链接到主机之前设置 Cloudflare。

如果原始服务器的 IP 在历史数据库中，最好的办法是切换 IP 地址。从您的主机购买/租用新 IP 应该不会太难。确保旧 IP 不再指向同一台服务器。

出站 IP 泄漏

背景
到目前为止，大多数想要保护自己免受 DDoS 攻击的人都足够安全。出站 IP 泄漏是指您的服务器向客户端发送其 IP 地址，这是难以跟踪的。

我见过的最常见的 IP 泄漏案例是通过出站电子邮件。假设您经营着一个流行的论坛，coolcats.com。您已采取预防措施，并且没有从 DNS 直接引用您的源服务器 IP 并在 Cloudflare 上运行。当用户注册您的论坛时，他们会收到一封确认电子邮件。除非您手动配置了出站电子邮件服务器，否则大多数 Web 服务器软件的默认确认是使用本地邮件服务器。这意味着论坛软件发送的任何电子邮件都有包含真实源服务器 IP 的标头。

攻击 攻击
者可以寻找运行在服务器上的服务来建立出站连接。虽然电子邮件是最常见的，但任何允许用户指示服务器进行出站连接的东西都容易受到攻击。攻击者可以触发该出站连接（例如，注册发送确认电子邮件的论坛）并从任何元数据（例如，电子邮件标头）中获取源服务器的 IP 地址。

可能的修复
确保不允许本地服务器进行出站连接。例如，使用其他服务器或服务（即 Mailgun、外部 smtp 服务器）代表您的服务器发送电子邮件。

错误配置的服务

背景
Web 服务器的默认配置是响应所有发送请求的 IP，除非启用了显式白名单/黑名单。这就是面向公众的网站的设置方式——您希望世界上的任何人都能够查看您的公开内容。但是，当启用 Cloudflare 时，对源服务器的所有请求都是从 Cloudflare 服务器发出的。例如，域 example.com 有一个 IP 为 111.111.111.111 的源服务器，并且正在提供内容为“Hello, World!”的网页。如果站点位于 Cloudflare 之后，当访问者请求 example.com 时，源服务器会看到来自充当反向代理的 Cloudflare 的请求，并发送“Hello, World!” 到 Cloudflare，后者又将其发送给访问者。但是如果访问者直接向 111.111.111.111 IP 地址发送 example.com 的 HTTP 请求，

攻击
知道网络服务器配置为以相同的方式响应所有 IP 地址，攻击者可以验证网站的源服务器 IP。如果攻击者知道源服务器所在的一般 IP 块，他们可以扫描启动的主机，然后直接向 IP 发送 HTTP 请求。下面的代码显示了对 IP 的请求，要求获取 example.com 的内容。

$ nc 111.111.111.111 80
GET / HTTP/1.1
主机：example.com

如果此请求返回的数据与对 example.com 的请求相同（如下），则该 IP 地址很可能是 example.com 的源服务器

$ nc example.com 80
GET / HTTP/1.1
主机：example.com

使用像 Zmap 这样的工具将允许攻击者以很少的资源快速扫描大量 IP 块。

可能的修复
防止这种攻击的最简单方法是禁止非 Cloudflare IP 连接到您的网络服务器。Cloudflare 发布其 IP 范围（可在此处找到），因此您可以设置仅包含 Cloudflare 和管理员 IP 的白名单。

包起来

希望这篇文章提高了您对 Cloudflare 托管站点以及任何其他 IP 掩码服务（例如 Tor）可能的攻击媒介的认识。如果您知道任何其他揭开源服务器掩码的方法，请随时在评论中分享，我会确保将它们添加到此列表中！