无需泄露私钥(https、tls、ssl)的网络服务器 DDOS 保护

信息安全 tls 公钥基础设施 ddos 云耀斑 可用性
2021-08-11 10:36:26

在不泄露 Web 服务器的 https 私钥的情况下,有哪些可能的方法可以保护组织的 Web 服务器免受 DDoS 攻击?

Web 服务器(例如 CloudFlare)的 DDoS 保护的许多常见解决方案要求您向第三方提供您的 https 私钥,或者(更糟糕的是)让他们能够为您的域创建自己的有效证书(例如控制您的ACME 的 DNS)。

我不愿意将我网站的私钥提供给第三方。

如何在不将我的私钥提供给第三方的情况下保护我的 Web 服务器免受 DDoS 攻击?

3个回答

第 3 方 DDoS 保护服务需要您的私钥的原因是,他们可以实际检查流量并据此采取行动。

没有它,他们只是在分析加密数据的 IP 流。在这种情况下,DDoS 保护仍然是可能的,但仅对基于 OSI 第 3 层和第 4 层的所有攻击真正有效。例如,UDP 泛洪、TCP SYN 攻击、产生大量流量的特定主机等可以在没有根本问题。

但是,无法检测到第 5-7 层攻击,因为它们都是加密的。因此,例如,无法检测到对特定 URL 的攻击。

本地设备可以作为自己进行 5-7 层攻击的解决方案。然而,对于那些第 3/4 层攻击,它并不总是一个解决方案。对于足够小的攻击,它们不会填满您的上游连接,它可以工作,但并不是每个人都能够在自己的网络中处理超过 100Gbps 的 DDoS 攻击,在这种情况下,外部清理中心可能是一个解决方案.

因此,如果您真的不想共享您的密钥,将 5-7 层本地解决方案与 3-4 层远程清理中心相结合可能是一个有趣的组合。当然,这是从技术角度来看,可能有财务或其他原因不这样做。一切都取决于您要防御哪种类型的 DDoS 攻击。

如果您在寻求 DDoS 保护(即试图通过过多请求压倒您的服务器的攻击),则无需将您的 TLS 证书提供给任何人。

通常,如果您在数据中心中设置一个简单的负载均衡器(具有公共 IP 并将所有流量简单地路由到实际服务器),它通常已经具备基本的 DDoS 保护,因为它是数据中心自身防御的一部分。

基本保护会限制请求,并使用路由调整将多余的请求发送到黑洞。这可以保护您的服务器免于过载,同时尝试允许至少一些合法流量仍然通过,但如果客户端离攻击中使用的某些节点太近,一些可能会被阻止。

然后可能会提供更高级别的保护(例如 Azure),您可以在其中获得有关攻击的更多分析信息以及对应该丢弃哪些流量的一些控制,因此您的响应团队可能会尽量减少在交火中捕获的客户端数量,或采取其他具体行动。

执行 TLS 终止的完整反向代理可防止其他攻击,例如停止 SQL 注入或 XSRF 尝试中常用的模式。但这些是其他类型的攻击,而不是 DDoS。

如果您不想使用第三方反向代理,您可以通过使用OWASP Core Rule Set安装modsecurity(在 nginx 或 apache 中)来获得类似的功能我建议仍然安装一个带有 TLS 密钥、modsecurity 和可能的身份验证的单独的 nginx 反向代理,以及带有实际应用程序的单独的服务器,以获得额外的深度防御。

你的关键问题是这样的:

如何在不将私钥提供给第三方的情况下保护我的 Web 服务器免受 DDoS 攻击?

但是您已经自己回答了:

...或者(更糟)让他们能够为您的域创建自己的有效证书(例如,控制您的 DNS 用于 ACME)

不清楚为什么您认为这更糟 - 拥有单独的证书和自己的私钥,这些证书永远不会在任何地方传输,并且可以独立撤销,而不是在多个地方使用单个证书。

可能您假设这将是向服务提供更多密码的情况,但这种情况不太可能发生。

为了对您的流量做任何事情,服务需要位于公共互联网和您的服务器之间。这意味着您的所有流量都已经流经他们的服务器。这通常涉及以下两件事之一:

  • 为 DNS 中指向其服务器的特定子域创建 CNAME。
  • 使用他们的名称服务器来托管 DNS 区域,以便他们可以使用动态 DNS 解析,并管理顶点记录(不能是 CNAME)。

一旦您拥有其中任何一个,他们就不需要任何进一步的访问权限来为域创建证书。例如CloudFlare 的文档说

有几种方法可用于完成 [域控制验证] 过程,Cloudflare 使用的主要方法是:

  • HTTP 令牌
  • CNAME DNS 记录
  • TXT DNS 记录

其中第一个是最简单的:它们拦截对某个纯文本 HTTP URL 的请求,并提供证书颁发机构请求的验证令牌。

从道德上讲,未经您的许可,他们不应该这样做,但是通过将您的 DNS 名称指向他们的服务器,您可以让他们完全控制在该域上提供的服务。