amazon-web-services - 如何将AWS WAF与Application ELB一起使用

Question

我需要对托管在AWS上的Web应用程序使用AWS WAF，以为其提供基于规则的附加安全性。我找不到任何直接将WAF与ELB结合使用的方法，并且WAF需要Cloudfront添加WEB ACL来阻止基于规则的操作。
因此，我将我的应用程序ELB CNAME添加到了cloudfront中，只有域名，带有IP阻止规则的WebACL和HTTPS协议(protocol)已使用cloudfront更新。其余全部保留为默认设置。一旦添加了WAF和带有ELB CNAME的Cloudfront，我就尝试从WAF的阻止ip规则中的一个IP地址访问CNAME ELB。我仍然可以从该IP地址访问我的Web应用程序。另外，我尝试检查cloudwatch指标以了解创建的Web ACL，但我什至没有看到它。
首先，有什么好的方法可以实现我的工作，其次，有没有一种特定的方法可以在Cloudfront上添加ELB CNAME。

感谢致敬，
杰伊

Answer 1

服务更新:以下原始的扩展答案在编写时是正确的，但现在主要适用于经典ELB，因为自2016年12月7日起，现在可以直接集成应用程序负载平衡器(elbv2)使用Web应用程序防火墙(Amazon WAF)。

Starting [2016-12-07] AWS WAF (Web Application Firewall) is available on the Application Load Balancer (ALB). You can now use AWS WAF directly on Application Load Balancers (both internal and external) in a VPC, to protect your websites and web services. With this launch customers can now use AWS WAF on both Amazon CloudFront and Application Load Balancer.

https://aws.amazon.com/about-aws/whats-new/2016/12/AWS-WAF-now-available-on-Application-Load-Balancer/

您似乎确实需要澄清这些部分如何组合在一起。

因此，假设您要保护的实际站点是 app.example.com。

听起来好像您有一个CNAME elb.example.com指向分配给ELB的主机名一样，例如example-123456789.us-west-2.elb.amazonaws.com。如果您访问这两个主机名之一，那么您将直接连接到ELB －不管CloudFront或WAF中配置了什么。这些机器仍然可以通过Internet访问。

这里的窍门是将流量路由到CloudFront，在此处可以通过WAF对其进行防火墙，这意味着还必须进行其他一些操作:首先，这意味着需要一个额外的主机名，因此您需要在DNS中配置app.example.com。作为CNAME(如果使用的是Route 53，则为Alias)，指向分配给您的发行版的dxxxexample.cloudfront.net主机名。

您还可以使用分配的CloudFront主机名直接访问您的站点，以进行测试。实际上，从被阻止的IP地址访问该端点应该确实导致请求被拒绝。

因此，您需要在CloudFront端点上发送流量-而不是直接发送到ELB。

这样是否会使您的ELB仍然暴露在外？

是的，它确实...所以下一步就是堵塞那个孔。

If you're using a custom origin, you can use custom headers to prevent users from bypassing CloudFront and requesting content directly from your origin.

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html

这里的想法是，您将建立一个仅对您的服务器和CloudFront已知的 secret 值。 CloudFront会将其与每个请求一起发送到 header 中，并且您的服务器将要求该值存在，否则它们将变得愚蠢并抛出错误-例如503 Service Unavailable或403 Forbidden甚至404 Not Found。

因此，您可以组成 header 名称(例如 X-My-CloudFront-Secret-String)和随机字符串(例如 o+mJeNieamgKKS0Uu0A1Fqk7sOqa6Mlc3)，并将其配置为CloudFront中的“自定义来源 header ”。此处显示的值是任意示例-可以是任何值。

然后将您的应用程序Web服务器配置为拒绝不存在该 header 和匹配值的任何请求-因为这是您知道该请求来自特定CloudFront发行版的方式。其他任何内容(除了ELB健康检查，您都需要异常(exception))都不来自CloudFront发行版，因此根据定义是未经授权的，因此您的服务器需要拒绝它，并带有错误，但在说明中无需过多解释。错误信息。

此 header 及其期望值仍然是 secret ，因为CloudFront不会将其发送回浏览器-仅在CloudFront发送给ELB的请求中以正向发送。

请注意，您应该为您的ELB获取一个SSL证书(用于elb.example.com主机名)，并将CloudFront配置为使用HTTPS将所有请求转发到您的ELB。 CloudFront和ELB之间的流量被拦截的可能性很小，但这是您应该考虑采取的一项保护措施。

您也可以选择仅允许ELB安全组中的CloudFront IP地址范围来阻止所有未从CloudFront发出的请求，从而减少(但不能消除)大多数未经授权的访问-CloudFront地址范围为 documented(搜索JSON以获取指定为 CLOUDFRONT的块，并仅允许在ELB安全组中使用这些块)，但请注意，如果执行此操作，则仍需要设置上述自定义来源 header 配置，因为如果仅在IP级别进行阻止，则从技术上讲仍然允许任何人的CloudFront发行版访问您的ELB。您的CloudFront分配与其他CloudFront分配共享一个池中的IP地址，因此该请求来自CloudFront的事实不足以保证它来自您的CloudFront分配。另请注意，您需要注册以获取更改通知，以便将新的地址范围添加到CloudFront时，便会知道将其添加到安全组中。