Amazon web services AWS可信顾问和临时端口

当我打开安全组中的临时端口（1024-65535）以允许ALB和EC2容器服务之间的通信时，我在运行AWS Trusted Advisor时得到“推荐操作”（红色！）。我应该担心还是不应该相信AWS的可信顾问

原始答案

安全组是有状态的，这意味着从实例启动到另一个源的流量将允许与该出站请求（即临时端口）相关的所有返回流量。这实际上是VPC中的NACL，在VPC中，您必须允许短暂的流量，因为它不是有状态的，并且不像安全组那样理解返回流量

也就是说，对于ALB->instance流量，您不需要打开sec组中的那些端口，因为sec组将允许从ALB内部发起的流量（到实例）和相关的临时端口流量返回ALB

您的实例只需要检查任何端口（端口80/8080/等），因为它的流量来自外部。但是，它不需要任何东西来允许流量出站到ALB临时端口，因为这些端口是从实例内部启动的，并且连接到允许流量的传入端口

编辑：

在对一个EC2实例进行了大量的尝试和解释之后，我在最初的解释中发现了一些错误。我将把最初的解释留在这里，因为我认为知道错误的发生是很重要的

无论如何，让我们在这里寻找更深入的答案

NACL（网络访问控制列表）

这些是无状态防火墙。基本上，它不知道传出的临时端口流量与传入的HTTP流量相关。它也是一种优先类型的系统。基本上，您可以按照您希望对规则进行评估的顺序（从最低到最高）对规则进行编号。当它遇到与流量匹配的规则时，它就会应用它。您还可以显式拒绝流量

这里的主要缺点是NACL每种方式只允许20条规则（总共40条规则），而安全组每种方式允许50条规则（总共100条规则）。也就是说，如果出于任何原因，安全组规则用完了，那么始终可以采用通用的流量规则并将其应用于NACL。在高遵从的环境中，NaCL也是一个需要考虑的问题，因为绝对的拒绝规则可能是与特定的许可规则的安全组相比的，因此必须绝对禁止某些流量。 安全组

与NACL不同，安全组只能具有许可效果规则。否认仅仅是缺乏一个宽容的角色。但是，在下面解释的某些情况下，安全组将跟踪交通并自动添加允许另一方向交通的规则

默认情况下，安全组具有允许所有出站流量的规则。这里的想法是，如果它是从您的实例启动的，那么绝大多数用例都是可以的。现在，如果一个黑客理论上通过一个服务漏洞获得对系统的访问，那么他们现在就可以在几乎任何他们想要的地方拥有出站流量

您可以在这里删除安全组中的出站流量规则。在这种情况下，您将拥有以下内容：

• 来自实例的流量将被拒绝
• 如果接受传入规则，则无论是否缺少出站规则，都将允许出站流量
• 如果添加了出站规则（例如端口80），则允许从实例调用端口80上的外部服务器。与该端口相关的传入流量也将被允许

安全组还跟踪连接（这就是它们被称为有状态连接的原因），以允许来自另一个方向的流量自动相关但是只有在流量被拒绝的情况下，它才会跟踪此情况

例如，如果没有删除允许所有访问的出站规则，则安全组将不需要是有状态的，因为不需要添加规则。但是，如果不允许通信，则它确实需要有状态。关于它是如何做到这一点，我找不到真正可靠的文档，但我的理论是围绕三方TCP握手。重要的是，当SYN进入或离开允许的端口时，它开始允许另一个方向的流量。然后它完全跟踪其余握手（SYN+ACK->ACK）完成的时间。当连接关闭相关数据包出现时，它可能会删除跟踪

考虑到这一点，在处理高容量前端服务时，如果可能的话，您最好对传出流量更加宽容，因为我可以想象跟踪开始将速度减慢到一个明显的速度

建议

• 取消NACL规则，只允许所有流量进出。让有状态安全组为您处理事情
• 将实例放在专用子网中的ALB后面。由于没有路线，这将阻塞外部交通
• 但是，您需要一个能够让您的私有实例接触到internet以获得重要信息的应用程序，例如从发行版服务器获取软件包更新
• 后端实例的安全组：允许ELB期望入站流量的任何端口。允许所有出站流量
• ALB的安全组：允许任何端口的入站流量（我假设为80或443），并允许所有出站流量
• 创建所谓的堡垒实例。它只是一个EC2实例，只允许SSH（或用于windows实例的RDP）。您可以使用它作为网关登录到专用子网实例。这应该允许安全组中的所有出站流量，并且只允许SSH流量向内到您的IP