问题标签 [amazon-waf]

我想知道 - 对于 AWS WAF 和 AWS API Gateway，选择哪些资源来保护它们以获得最大安全性的最佳实践是什么？

还是简单地说：

1. 对于所有静态内容 - 在 CloudFront 上使用 WAF
2. 对于所有 REST api 调用 - 使用 API Gateway 保护它
3. 对于其他一切 - 使用 WAF 保护它

亲切的问候，

我已经尝试了所有可能的过滤器来阻止 hitleap 并且假流量仍在通过：

我只是不明白，因为用户代理很明显是“HitLeap Viewer 2.8”

我已经正确分配了所有规则并将其添加到我的云端分发中。我在这里想念什么？

我需要将 AWS WAF 用于托管在 AWS 上的 Web 应用程序，以便为其提供额外的基于规则的安全性。我找不到任何方法可以直接将 WAF 与 ELB 一起使用，而 WAF 需要 Cloudfront 添加 WEB ACL 以阻止基于规则的操作。因此，我将我的应用程序 ELB CNAME 添加到云端，只有域名、带有 IP 阻止规则的 WebACL 和 HTTPS 协议使用云端进行了更新。其余所有已保留默认值。一旦添加了带有 ELB CNAME 的 WAF 和 Cloudfront，我尝试从 WAF 中的阻止 IP 规则中的 IP 地址之一访问 CNAME ELB。我仍然可以从该 IP 地址访问我的 Web 应用程序。此外，我尝试检查创建的 Web ACL 的 cloudwatch 指标，我发现它甚至没有被命中。首先，有什么好的方法可以实现我正在做的事情，其次，有没有一种特定的方法可以在云端添加 ELB CNAME。

谢谢和问候， 杰伊

我正在使用 AWS cloudfront 为基于 Java 的 Web 应用程序提供我的内容。当我通过云前端访问我的内容时，我的应用程序运行正常，但是当我通过云前端路由我的整个 Web 应用程序时，它会给出以下错误。错误 无法满足请求。此分发未配置为允许用于此请求的 HTTP 请求方法。该发行版仅支持可缓存的请求。由云端（CloudFront）生成请求ID：4XzY7bSuqBbiTuwbQZKgpVdLpPru5PZ-4oPDWqwvB_FgIbTIsdZJaA==

我想使用 AWS cloudfront 来避免对基于 Java 的 Web 应用程序（整个应用程序）的 DDos 攻击。如果有人帮助我，那就太好了

在此先感谢 Sateesh

我正在尝试使用这些为 WAF 提供的示例堆栈通过 AWS CloudFormation 启动一个堆栈：

https://s3.amazonaws.com/solutions-reference/aws-waf-security-automations/latest/aws-waf-security-automations.template https://s3.amazonaws.com/cloudformation-examples/community/common -attacks.json

我想在 us-east-1 区域启动这些堆栈，我通过访问以下 URL 来实现： https ://us-east-1.console.aws.amazon.com/cloudformation/home?region=us-东1#/stacks/new

仍然在创建 WAF ACL 和规则时，它们是 Global (Cloudfront) 而不是 us-east-1 区域的一部分。我已经尝试了几次，它的工作原理是这样的。

要在特定区域启动这些堆栈，我需要做更多的事情吗？

我创建了以下 AWS WAF ACL，我想使用 terraform 将它与我的 ALB 相关联。有什么办法可以使用 terraform 做到这一点？我想阻止所有请求，除了那些使用亚马逊 Web 服务 Web 应用程序防火墙 aws waf 具有密钥的请求。为此，我创建了 byte_set、aws 规则和访问控制列表、ACL

我想将 WAF 放在 API Gateway 前面，并且我发现只有通过在APIG前面手动放置启用 WAF 的额外 Cloudfront 分发才能实现。有点遗憾，特别是因为 APIG 现在原生支持自定义域，但它应该可以工作。

现在为了使解决方案安全而不仅仅是晦涩难懂，我想强制 API 只能通过 Cloudfront 发行版访问。这样做的最佳选择是什么？

• 我希望能够使用与 S3 类似的“原始访问身份”，但不知道该怎么做。
• 如果我可以将 IAM 用户（或角色？）分配给 Cloudfront 发行版，我可以使用 APIG IAM 功能，但我不知道如何做到这一点。
• 我可能需要 APIG 中的 API 密钥，并将其作为来自 Cloudfront 的 Origin Custom Header 传递。只要我们不想将 API 密钥用于其他目的，这可能会奏效，所以我对此并不完全满意。
• 可以使用虚拟 (!) 自定义授权方，令牌验证表达式实际上检查作为来自 Cloudfront 的 Origin 自定义标头传递的秘密。应该可以，它更灵活，但有点脏……还是不行？

有更好的想法吗？或者也许存在“正确的方法”，但我忽略了它？

在 AWS 中，我创建了一个访问控制列表作为设置 WAF 的一部分。

我有几个应用程序负载均衡器（在 EC2 的负载均衡器下找到）。

这些都不会作为用于将 ACL 关联到 ALB 的下拉列表中的选项出现，事实上，当尝试关联下拉列表时，下拉列表是空的。

一切都共享同一个区域，所以我不确定为什么没有看到这些应用程序负载均衡器。

我不确定它是否相关，但 ALB 被列为“经典”类型。

我发现这个部门缺少亚马逊文档，任何帮助将不胜感激。

如果我们尝试在经典 ELB 中启用 WAF，我无法创建，我是否知道实现它的方法，所以这将有助于我们在基础设施中设置一层安全性

我是新的 NodeJS，并试图更改 AWS 提供的此示例以更新信誉列表，但它仅特定于 CloudFront 全球区域。

https://github.com/awslabs/aws-waf-sample/tree/master/waf-reputation-lists

我已经对 CloudFormation 进行了更改以创建区域 IPSetID，但是该函数在 IPSetID 不存在的情况下退出。我认为这是因为 SDK 正在查看全局而不是区域，即 eu-west-1，因此我在配置中设置了区域，但它仍然无法找到 IPSet。

我看到了一个最近的问题（AWS WAF 更新 ip sets and rules specific to a region from lambda），它显示了 URL 的差异，但是我不知道从哪里开始更新 URL？