Ultimate AWS-SAP-C01 No28~

No.28 Blocking an IP address

了解当来自客户端的请求一直传递到应用程序会发生什么。
so 有时我们希望可以阻止来自客户端的IP地址，因为它可能是一个恶意行为者，可能它正在尝试访问我们的应用程序。
so 我们希望了解防御线

解决方案体系结构：

该体系结构中，我们在安全组和VPC中有一个人EC2实例，
该实例具有公共IP，so 可以公开访问。这就是我们的客户端进入EC2实例的方式。
假设你要阻止该客户端，

• 第一道防线将是VPC中的网络ACL，
  网络ACL位于VPC级别，在网络ACL中，我们可以为该客户端IP地址创建拒绝规则，这将非常简单，快速且成本低廉，并且该客户端将被弹出。
• 然后，对于EC2实例的安全组，我们不能有拒绝规则，只能有允许规则，
  so 如果我们知道只有授权客户端的子集可以访问我们的EC2实例，那么在我们的安全组中，最好只定义允许进入我们的EC2实例的IP子集。
  但是，如果我们的应用程序是全局的，则我们显然不知道将访问我们应用程序的所有IP地址。
  so 此时的安全组将不会有很大的帮助。
• 最后你可以在EC2上运行可选的防火墙软件。
  可以从软件内部阻止来自客户端的请求。
• 很显然，如果（断断续续的）请求已经到达你的EC2实例，那么它将必须被处理，并且处理该请求将是一个CPU开销。
  这是一个非常简单的用例，但我们已经看到了NACL，安全组和主机防火墙之间的区别。
  

解决方案体系结构With an ALB：

引入应用负载平衡器ALB。
ALB也是在VPC中被定义的，我们仍然是一个EC2实例，
但现在我们有两个安全组，我们有ALB安全组和EC2安全组。

• 在这种情况下，此架构的ALB将位于客户端和EC2之间，它将执行一种称为”更正终止“的操作。
  so 客户端实际链接到ALB，ALB将终止链接，并启动从ALB到EC2实例的新链接。
• 在本例中，我们的EC2安全组必须配置为允许ALB的安全组。
  因为EC2实例可以部署在具有私有IP的私有峰会中，
  并且它看到的流量源来自ALB，而不是客户端
  so 从安全组的角度来看，我们只允许来自ALB安全组的流量，EC2实例这一端是安全的。
  

解决方案体系结构With an NLB：

这是一个事件概念，但对于网络负载平衡器，他不执行链接终止的传输方式。
这是一种过度简化，实际上是通过我们的不配置安全组的网络负载平衡器。
这意味着客户端发起的IP将一直到达我们的EC2实例，即使我们的EC2实例位于私有子组并具有私有IP。
但是，这里的设计是：如果我们再次知道所有客户端的源IP，我们可以在EC2安全组中定义它，但如果我们试图拒绝客户端的一个IP地址，这里我们拥有的唯一防线就是网络ACL。
但是网络负载平衡器没有安全组，所有流量都要经过它，因此，我们的EC2实例可以看到边缘客户端的公共IP。

解决方案体系结构ALB+WAF：

即拥有ALB，我们可以通过安装WAF来拒绝IP，现在，此WAF的成本会稍微高一些，
so 这是一项附加服务和防火墙服务，
但在这里，我们能够对IP地址进行一些复杂的过滤。
并且我们能够建立对请求进行计数的规则，以防止来自客户端的大量请求同时进行。
so 我们对我们的安全或ALB有更大的权力。
so WAF不是介于客户端和ALB之间的服务，而是我们安装在ALB上的服务，我们可以定义一系列规则。
so 这又是一道防线。

解决方案体系结构ALB，CloudFrontWAF：

如果我们在ALB之前使用CloudFront，CloudFront将位于我们的VPC之外。
so 我们的ALB需要允许来自边缘位置的所有CloudFront公共IP，并且有一个在线列表。
so 从ALB来看，它看不到客户端IP，它看到的是CloudFront的公共IP。
so 位于我们的VPC边界的网络ACL根本没有帮助，它无法帮助我们阻止客户端IP地址。
so 在这种情况下，如果我们试图阻止CloudFront的客户端，我们有两种可能性：
如果我们受到一个国家的攻击，那么我们可以使用平台的地理限制功能来限制我们的客户端在CloudFront上拒绝所有国家。
或者如果有一个特定的IP困扰我们，我们可以再次使用WAF以诱导一些IP地址过滤。

如上所述，根据我们的体系结构，我们有不同的防御线来阻止IP地址。