如何将AWS WAF与Application ELB一起使用 [英] How to use AWS WAF with Application ELB
问题描述
我需要对托管在AWS上的Web应用程序使用AWS WAF，以为其提供基于规则的附加安全性。我找不到任何直接将WAF与ELB结合使用的方法，并且WAF需要Cloudfront添加WEB ACL来阻止基于规则的操作。
因此，我将我的应用程序ELB CNAME添加到了cloudfront中，只有域名，带有IP阻止规则的WebACL和HTTPS协议已使用cloudfront更新。其余全部保留为默认设置。一旦同时添加了WAF和带有ELB CNAME的Cloudfront，我便尝试从WAF的阻止ip规则中的ip地址之一访问CNAME ELB。我仍然可以从该IP地址访问我的Web应用程序。另外，我尝试检查cloudwatch指标以了解创建的Web ACL，但我什至没有看到它。
首先，有没有什么好方法可以实现我的工作，其次，有没有一种在Cloudfront上添加ELB CNAME的特定方法。
I need to use AWS WAF for my web application hosted on AWS to provide additional rule based security to it. I couldnt find any way to directly use WAF with ELB and WAF needs Cloudfront to add WEB ACL to block actions based on rules. So, I added my Application ELB CNAME to cloudfront, only the domain name, WebACL with an IP block rule and HTTPS protocol was updated with cloudfront. Rest all has been left default. once both WAF and Cloudfront with ELB CNAME was added, i tried to access the CNAME ELB from one of the ip address that is in the block ip rule in WAF. I am still able to access my web application from that IP address. Also, I tried to check cloudwatch metrics for Web ACL created and I see its not even being hit. First, is there any good way to achieve what I am doing and second, is there a specific way to add ELB CNAME on cloudfront.
感谢和问候，
Jay
Thanks and Regards, Jay
推荐答案
服务更新：以下原始的扩展答案正确于在撰写本文时，但现在主要适用于Classic ELB，因为自2016年12月7日起，应用程序负载平衡器（elbv2）现在可以直接与Web应用程序防火墙（Amazon WAF）集成。
Service update: The orignal, extended answer below was correct at the time it was written, but is now primarily applicable to Classic ELB, because -- as of 2016-12-07 -- Application Load Balancers (elbv2) can now be directly integrated with Web Application Firewall (Amazon WAF).
开始[2016-12-07] AWS WAF（Web应用程序防火墙）在应用程序负载平衡器（ALB）上可用。现在，您可以直接在VPC中的Application Load Balancer（内部和外部）上使用AWS WAF，以保护您的网站和Web服务。通过此次发布，客户现在可以在Amazon CloudFront和Application Load Balancer上使用AWS 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.
看来您确实需要对这些部分的组合方式进行澄清。
It seems like you do need some clarification on how these pieces fit together.
因此，假设您要保护的实际站点是 app.example.com 。
So let's say your actual site that you want to secure is app.example.com.
听起来好像您有一个CNAME elb.example.com指向为ELB分配的主机名，例如example-123456789.us-west-2.elb.amazonaws.com。如果您访问这两个主机名之一，那么您将直接连接到ELB －无论CloudFront或WAF中配置了什么。这些机器仍然可以通过Internet进行访问。
It sounds as if you have a CNAME elb.example.com pointing to the assigned hostname of the ELB, which is something like example-123456789.us-west-2.elb.amazonaws.com. If you access either of these hostnames, you're connecting directly to the ELB -- regardless of what's configured in CloudFront or WAF. These machines are still accessible over the Internet.
这里的窍门是将流量路由到CloudFront，在这里WAF可以对其进行防火墙保护，这意味着另外一些事情必须发生：首先，这意味着需要一个额外的主机名，因此您在DNS中将app.example.com配置为CNAME（如果使用Route 53，则配置为Alias），指向分配给dxxxexample.cloudfront.net的主机名您的分布。
The trick here is to route the traffic to CloudFront, where it can be firewalled by WAF, which means a couple of additional things have to happen: first, this means an additional hostname is needed, so you configure app.example.com in DNS as a CNAME (or Alias, if you're using Route 53) pointing to the dxxxexample.cloudfront.net hostname assigned to your distribution.
您还可以使用分配的CloudFront主机名直接访问您的站点，以进行测试。从被阻止的IP地址访问此端点确实应该导致请求现在被拒绝。
You can also access your sitr using the assigned CloudFront hostname, directly, for testing. Accessing this endpoint from the blocked IP address should indeed result in the request being denied, now.
因此，CloudFront端点是您需要的地方发送您的流量-而不是直接发送给ELB。
So, the CloudFront endpoint is where you need to send your traffic -- not directly to the ELB.
这是否会使您的ELB仍然处于暴露状态？
Doesn't that leave your ELB still exposed?
是的，它确实是...所以下一步就是塞住那个洞。
Yes, it does... so the next step is to plug that hole.
如果您使用的是自定义来源，则可以使用自定义标头来防止用户绕过CloudFront并直接从您的来源请求内容。
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已知的秘密值。 CloudFront会将其与每个请求一起发送到标头中，并且您的服务器将要求该值存在，否则它们将愚蠢地抛出错误，例如503 Service Unavailable或403 Forbidden甚至404 Not Found。
The idea here is that you will establish a secret value known only to your servers and CloudFront. CloudFront will send this in the headers along with every request, and your servers will require that value to be present or else they will play dumb and throw an error -- such as 503 Service Unavailable or 403 Forbidden or even 404 Not Found.
因此，您组成了标题名称，例如 X-My-CloudFront-Secret-String 和一个随机字符串，例如 o + mJeNieamgKKS0Uu0A1Fqk7sOqa6Mlc3 并将其配置为CloudFront中的自定义来源标题。
So, you make up a header name, like X-My-CloudFront-Secret-String and a random string, like o+mJeNieamgKKS0Uu0A1Fqk7sOqa6Mlc3 and configure this as a Custom Origin Header in CloudFront. The values shown here are arbitrary examples -- this can be anything.
然后将您的应用程序Web服务器配置为拒绝不存在该标头和匹配值的任何请求- -因为这是您知道请求来自特定CloudFront发行版的方式。其他任何内容（除了ELB运行状况检查之外，您需要对其进行例外处理）都不来自CloudFront发行版，因此根据定义是未经授权的，因此您的服务器需要通过错误拒绝它，而无需在其中进行过多解释。错误消息。
Then configure your application web server to deny any request where this header and the matching value are not present -- because this is how you know the request came from your specific CloudFront distribution. Anything else (other than ELB health checks, for which you need to make an exception) is not from your CloudFront distribution, and is therefore unauthorized by definition, so your server needs to deny it with an error, but without explaining too much in the error message.
此标头及其期望值仍然是机密，因为CloudFront不会将其发送回浏览器，而是仅向前发送。 CloudFront发送到您的ELB的请求。
This header and its expected value remains a secret because it will not be sent back to the browser by CloudFront -- it's only sent in the forward direction, in the requests that CloudFront sends to your ELB.
请注意，您应该为ELB获取SSL证书（用于elb.example.com主机名），并将CloudFront配置为使用HTTPS将所有请求转发到ELB。 CloudFront和ELB之间的流量被拦截的可能性很小，但这是您应该考虑采取的保护措施。
Note that you should get an SSL cert for your ELB (for the elb.example.com hostname) and configure CloudFront to forward all requests to your ELB using HTTPS. The likelihood of interception of traffic between CloudFront and ELB is low, but this is a protection you should consider implenting.
您还可以选择也减少（但不能消除）大多数未经授权的访问，方法是仅允许ELB安全组中的CloudFront IP地址范围来阻止所有未从CloudFront发出的请求-CloudFront地址范围为已记录（在JSON中搜索指定为 CLOUDFRONT ，并且仅在ELB安全组中允许这些），但是请注意，如果执行此操作，则仍需要设置自定义来源标头配置（如上所述），因为如果仅在IP级别进行阻止，则说明从技术上讲，仍然允许任何人的CloudFront发行版访问您的ELB。您的CloudFront分配与其他CloudFront分配共享一个池中的IP地址，因此该请求来自CloudFront的事实不足以保证它来自您的 CloudFront分配。另请注意，您需要注册以获取更改通知，以便将新的地址范围添加到CloudFront时，便会知道将其添加到安全组中。
You can optionally also reduce (but not eliminate) most unauthorized access by blocking all requests that don't arrive from CloudFront by only allowing the CloudFront IP address ranges in the ELB security group -- the CloudFront address ranges are documented (search the JSON for blocks designated as CLOUDFRONT, and allow only these in the ELB security group) but note that if you do this, you still need to set up the custom origin header configuration, discussed above, because if you only block at the IP level, you're still technically allowing anybody's CloudFront distribution to access your ELB. Your CloudFront distribution shares IP addresses in a pool with other CloudFront distribution, so the fact that the request arrives from CloudFront is not a sufficient guarantee that it is from your CloudFront distribution. Note also that you need to sign up for change notifications so that if new address ranges are added to CloudFront, then you'll know to add them to your security group.
这篇关于如何将AWS WAF与Application ELB一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
