即使使用Cloudflare CDN，也如何解决源IP泄露和DD攻击的问题？

支持
1

我的网站使用了 Discourse。起初，它没有 Cloudflare 的保护，遭受了 DDoS 攻击。

后来，我更改了 IP 地址并实施了 Cloudflare。但是，由于源服务器 IP 地址泄露，网站再次遭受了 DDoS 攻击。

在使用 Cloudflare CDN 时，我们如何防止源服务器 IP 地址泄露？有人有什么好方法吗？谢谢。

2

我不知道，但每个在线服务器的 IP 地址将在创建时同时泄露。

3

您可以执行以下操作来防止大量泄露：

  • 在另一台 VPS 上设置一个代理服务器，例如 Tinyproxy
  • 设置环境变量 HTTPS_PROXY 和 HTTP_PROXY，以便 Discourse 使用它（在 app.yml 的 env 部分设置它们）
  • 设置 NO_PROXY='127.0.0.1, localhost, <internal-network>'

另请参阅 https://meta.discourse.org/t/install-discourse-with-internet-access-only-via-proxy/66396/、https://meta.discourse.org/t/configuration-outbound-proxy/65992 和 Discourse Link previews through a proxy server? - #14 by supermathie

此外，当您使用 CF 时，您可以修改 Discourse 主机上的防火墙，使其仅允许来自您的 Cloudflare IP（以及您自己访问它的主机）的入站流量。

4 个赞
4

这是解决方案。隐藏式安全并不安全。这样一来，你的 IP 地址是否是公开的秘密就无关紧要了。

3 个赞
5

或者，另一种更简单的方法是使用所谓的 Cloudflare 隧道。它应该是一次性设置，然后您应该能够在很大程度上关闭防火墙以进行入站连接。

2 个赞
6

我相信我很久以前就采用了这种方法（没有您提到的代理设置）。我不确定这是否适用于所有防火墙（或者是我设置中的某些东西）

但在我的 ufw 的情况下，值得一提的是 docker 默认会绕过 ufw，因此您需要确保也将其规则应用于您的内部 docker IP。

已经有一段时间了，但如果您仍然需要，我可以在本周晚些时候进一步研究细节。

是的，Cloudflare 隧道太棒了！@itsbhanusharma

1 个赞
7

您将需要使用您的 VPS 提供商为您提供的防火墙。使用基于主机的防火墙在对抗 DDoS 攻击方面效果会差得多，因为流量确实会到达您的网络堆栈。

3 个赞
8

我认为大多数大型提供商默认都提供 DDOS 防护？这难道不够吗？通过界面手动添加 CloudFlare IP 地址似乎很麻烦（例如，我的自定义 bash 脚本需要 2 秒钟并自动获取 CF IP 地址）。

不得不说，我通常读到的是相反的观点，ufw/本地防火墙优于提供商的防火墙 :thinking:

编辑；我确实理解这里的逻辑，从 DDOS 的角度来看，这可能更有效，而且你是对的。话虽如此，如果主 IP 从一开始就被正确隐藏，DDOS 应该不成问题，对吧？

1 个赞
9

现在大多数提供商都有相应的 API 了？

没错！但这“如果”的条件相当苛刻……

2 个赞
10

实际上是错误的。仅仅因为 IP 地址没有隐藏起来。如果反向代理或类似工具能够阻止 DDoS 攻击，那么 DDoS 就不是问题。即使真的发生了攻击，也需要比入门级解决方案更强大的东西。而且，如果机器人或被控制的用户正在攻击关闭的端口或 IP 限制的端口，那也不是什么大问题。我会称之为 WordPress 世界里的另一个星期四，但 Discourse 在很多方面是另一个世界。

另一方面，我不是这方面的专家。

但我很好奇……需要多少流量才能成功进行 DDoS 攻击？当然，这取决于设置的资源，但请给我一些数字。

1 个赞
11

这取决于你对“隐藏”的定义。是的，所有的IP地址都是公开的。但哪一个40亿个IP地址是正确的呢？我认为，对于这个讨论，如果无法确定提供特定Discourse论坛的服务器的IP地址，那么该IP就可以被认为是隐藏的（即函数f(h)是未确定的，其中函数f给出主机的真实IP地址）。
假设：

  • 你不是Cloudflare
  • 该论坛没有通过出站流量（如oneboxing或出站电子邮件标头或其他方式）泄露其IP

但我同意你的观点，“隐藏”是一个令人困惑且不正确的术语。“未知”可能更好。

这取决于DDoS的类型。对于应用程序层攻击，这可能是正确的，但也很困难，因为它需要某种带有请求检查的速率限制。但对于网络层攻击（简单的放大攻击或SYN攻击），这可能不成立。此外，你基本上是在说“如果你能缓解它，它就不是问题”，这很明显，但也很困难和/或昂贵。

这也取决于攻击的类型。应用程序层攻击需要针对Discourse进行定制，但可以例如运行一些繁重的查询（如搜索）来压垮应用程序服务器，而网络层攻击可以更通用，需要更多流量，并且可以简单地堵塞nginx或VPS网络。

4 个赞
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.