Google Cloud Functions 是否受到 DDoS 攻击的保护？答案

【问题标题】：Are Google Cloud Functions protected from DDoS attacks?Google Cloud Functions 是否受到 DDoS 攻击的保护？
【发布时间】：2018-06-05 12:34:29
【问题描述】：

据我了解，我的 Google Cloud Functions 可以在全球范围内访问。如果我想控制对它们的访问，我需要将授权作为函数本身的一部分来实现。说，我可以使用基于承载令牌的方法。这将保护此函数背后的资源免受未经授权的访问。

但是，由于该功能在全球范围内可用，它仍然可以被坏人 DDoS 攻击。如果攻击没有谷歌的防御那么强大，我的功能/服务可能仍然是响应式的。这很好。但是，我不想为我未授权访问该功能的一方进行的那些功能调用付费。（因为按功能调用次数计费）。 这就是为什么在我负责收费之前了解 Google Cloud Functions 是否检测到 DDoS 攻击并启用对策对我来说很重要的原因。

【问题讨论】：

标签： security google-cloud-platform google-cloud-functions

【解决方案1】：

我认为有关 DDOS 保护的问题已经得到充分回答。不幸的是，现实情况是，无论是否提供 DDOS 保护，都很容易收取大量费用。我在 20 分钟内收取了大约 30 美元的费用，而 DDOS 保护却无处可寻。我们仍然留下“我不想为那些由我未授权访问该函数的一方进行的函数调用付费。”

让我们来谈谈现实的缓解策略。 Google 不会为您提供对支出进行硬性限制的方法，但您可以做很多事情。

限制函数可以拥有的最大实例数

在编辑函数时，您可以指定它可以同时生成的最大实例数。将其设置为您的用户不太可能击中的内容，但如果攻击者这样做，这不会立即破坏银行。那么……

设置预算提醒

您可以在云控制台的“结算”部分创建预算并设置提醒。但是这些警报迟到了几个小时，你可能正在睡觉或什么的所以不要太依赖这个。

混淆您的函数名称

这仅在您的函数仅被私人访问时才相关。您可以为您的函数提供攻击者不太可能猜到的模糊名称（可能是散列）。如果您的功能不是私人访问的，也许您可以...

设置一个 Compute Engine 实例以充当用户和您的云功能之间的中继

计算实例是固定价格的。攻击者可以减慢他们的速度，但不能让他们破坏你的钱包。您可以在计算实例上设置速率限制。用户不会知道你混淆的云函数名，只有中继知道，所以除非他们猜到你的函数名，否则没有人可以直接攻击你的云函数。

如果调用次数过多，请让您的云功能关闭计费

每次调用您的函数时，您都可以让它在 Firebase 或 Cloud Storage 对象中增加一个计数器。如果此计数器过高，您的函数可以自动禁用对您的项目的计费。

Google 提供了一个云功能如何禁用项目计费的示例：https://cloud.google.com/billing/docs/how-to/notify#cap_disable_billing_to_stop_usage

在示例中，它会禁用计费以响应 pub/sub 计费。然而，这些 pub/sub 的价格落后了几个小时，所以这似乎是一个糟糕的策略。在某个地方设置一个柜台会更有效。

【讨论】：

【解决方案2】：

我已向 google-cloud 支持发送了一封电子邮件，内容涉及云功能以及它们是否受到 DDoS 攻击的保护。我从工程团队收到了这个答复（截至 2018 年 4 月 4 日）：

Cloud Functions 位于 Google 前端之后，可缓解和吸收许多第 4 层及以下攻击，例如 SYN 洪水、IP 片段洪水、端口耗尽等。

【讨论】：

最好知道背后是什么等？例如，对于谷歌云功能，它将只是数百万个有效的 http 调用。即使您使用自己的逻辑在您的应用程序中过滤它们，您仍然需要为函数调用付费。您可以将速率限制基于高峰时段的应用程序使用率，但如果攻击者会（轻松）找到限制并攻击谷歌功能暂停所需的调用次数略低，您将一直支付最高费用，并且普通用户将无法使用基于此功能的应用程序，因为暂停。看起来像史诗般的失败。
但同时，如果将常规计算实例与 autoscaler 或 kubernetes 一起使用，我们也会遇到同样的问题。那么解决办法是什么？
从文档看，云功能只能防止TCP/IP中的4层以下的DDoS攻击。黑客仍然可以通过 HTTP 发送大量流量来攻击您的 API。正确的解决方案是您需要设置一个具有 HA 的 API 网关来执行速率限制和负载均衡器。此流程将是访问者发送请求 --> 负载均衡器 --> API 网关 --> Cloud Function
@Edd 你能发个链接到你找到这些信息的地方吗？
@Edd 谢谢你的回复。对不起，我应该更具体。我的问题是关于您对 Google 的评论“向您收取 90%（或类似的）“通常流量”的费用。

【解决方案3】：

我最近一直在问自己同样的问题，并偶然发现了这些信息。简短回答您的问题：Google 仍然不会自动保护您的 GCF 免受大规模 DDOS 攻击，因此：除非 Google 基础架构因攻击尝试而崩溃，否则您将不得不为攻击造成的所有流量和计算时间付费。

有一些机制，你应该仔细研究一下，因为我不确定它们是否也适用于 GCF：

2020 年 7 月更新：正如 morozko 所指出的，似乎有一个专门的 Google 服务解决了这个问题，称为 Google Cloud Armor (Link to Google)。

【讨论】：

谢谢伊戈尔。我会看一下随附的文档。 IMO，谷歌应该做亚马逊所做的——简单地将云功能与 API 网关集成，并配置每个 API 路由的基于调用率的行为。如果发生 DDoS，我们当然仍然需要为 API 网关的使用付费，但情况不一样。

【解决方案4】：

这是我自己的真实经历：他们没有。您必须使用自己的规则组合、来源检测等来防止这种情况。我最近成为 DDoS 的受害者，不得不关闭服务一段时间以实施我自己的安全墙。

【讨论】：

您能否描述一下您为实现自己的安全墙采取了哪些步骤？

【解决方案5】：

通过阅读https://cloud.google.com/functions/quotas 和https://cloud.google.com/functions/pricing 的文档，似乎没有针对HTTP 函数的任何滥用保护。您应该区分使 Google 服务器无响应的 DDoS 攻击和某些攻击者知道您的 HTTP 函数的 URL 并调用它数百万次的滥用行为，后者仅与您支付的费用有关。

【讨论】：

是的，我说的是后一种。我的答案可能不太正确。那么，这是一个很大的禁忌服务。我们应该始终假设 URL 是众所周知的或容易被发现的。 Cloud Functions 尤其如此，因为它们旨在用作“常规”网络服务的替代品，在这种情况下，我们通常不会为每次调用支付任何费用，除了可能与流量相关的费用。跨度>
我不确定这就是它们的用途，每个人都有不同的用例。如果有帮助，请接受我的回答...
来自文档：Google Cloud Functions is a serverless execution environment for building and connecting cloud services. 这与用例无关...
我赞成您的回答，因为您将我指向包含我已经知道的信息的文档。我还没准备好接受这个作为答案，因为它不够深，也不能解决我遇到的问题。作为一名建筑主管，您非常了解我的意思。（顺便说一句，我自己甚至没有对这个答案投赞成票，好像它有什么根本性的问题）
它没有回答您的问题还是不是您期望的答案？无论如何，它是关于用例的，对于某些人来说，这种无服务器执行的响应时间对于 Web 服务来说是不可接受的。您应该考虑所有这些数据，并确定它是否适合您的案例。如果您愿意接受此类滥用的潜在成本，并且总体而言，使用无服务器而不是其他解决方案可以节省您的时间和资金，

【解决方案6】：

目前处于测试阶段的Google Cloud Armour可以缓解DDoS攻击

另请参阅相关 Google 内部人员的 short example 与 GC 安全规则和相应的 reference docs

【讨论】：

这似乎是个好主意，但价格似乎比云函数本身还要高：Google Cloud Armor 上的每百万 HTTP(S) 请求 0.75 美元 VS Cloud Functions 上的每百万次调用 0.40 美元。 ..

【解决方案7】：

一种可能的解决方案是 API 网关，您可以在其中使用 firebase 身份验证。成功通过 api gw 身份验证后，它可以调用您使用 --no-allow-unauthenticated 标志部署的函数。但是，如果您也为未经身份验证的 api gw 请求付费，我会感到困惑..

【讨论】：