如何为到私有子网的 SSH 设置 AWS 网络访问控制列表

Question

我正在 AWS 上做一门课程。我想要做的是设置一个带有两台 Linux 服务器的 VPC。我已经设置了具有两个子网的 VPC。我在每个服务器中都放置了一台服务器。这个想法是一个子网是公共的，另一个是私有的。

我创建了两个网络 ACL，并为每个子网关联了一个。

我可以从我的机器通过 SSH 连接到公共子网中的服务器。当我尝试通过 SSH 连接到我的私有子网中的服务器时，我遇到了连接超时。

我不确定需要在我的两个网络 ACL 中设置什么规则才能使 SSH 正常工作。任何人都可以帮忙吗？鉴于我正在学习，我希望能解释为什么规则应该是，而不仅仅是规则应该是什么。

我有一个名为 MyVPC 的 VPC，其 CIDR 为 10.0.0.0/16
我的第一个子网名为 MyVPCSub1 CIDR 10.0.1.0/24
我的第二个子网名为 MyVPCSub2 CIDR 10.0.2.0/24
我有一个名为 MyInternetRoute 的路由表与 MyVPCSub1 路由关联：

|Dest        |Targ  |  
|10.0.0.0/16 |local |
|0.0.0.0/0   |igw   |

我有一个名为 MyPrivate 的路由表与 MyVPCSub2 相关联的路由是：

|Dest        |Targ  |
|10.0.0.0/16 |local |

我有一个名为 MyWeb 的网络 ACL 与带有规则的 MyVPCSub1 关联：

入站：

| #   | Type | Protocol | Ports | Source     | A/D
| 99  | HTTP | TCP      | 80    | {My IP}/32 | D
| 100 | HTTP | TCP      | 80    | 0.0.0.0/0  | A
| 200 | HTTPS| TCP      | 443   | 0.0.0.0/0  | A
| 300 | SSH  | TCP      | 22    | {My IP}/32 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0  | D

出站：

| #   | Type   | Protocol | Ports      | Source     | A/D
| 50  | ALL    | ALL      | ALL        | 0.0.0.0/0  | A
| 100 | HTTP   | TCP      | 80         | 0.0.0.0/0  | A
| 200 | HTTPS  | TCP      | 443        | 0.0.0.0/0  | A
| 300 | Custom | TCP      | 1024-65535 | 0.0.0.0/32 | A
| *   | ALL    | ALL      | ALL        | 0.0.0.0/0  | D

我有一个名为 MyPrivate 的网络 ACL 与带有规则的 MyVPCSub2 相关联：

入站：

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

出站：

| #   | Type | Protocol | Ports | Source    | A/D
| 100 | ALL  | ALL      | ALL   | 0.0.0.0/0 | A
| *   | ALL  | ALL      | ALL   | 0.0.0.0/0 | D

Answer 1

首先是定义一些术语的含义。

NACLS - 网络访问控制列表，是一种应用于子网级别的无状态数据包过滤器。记住“无状态”方面很重要，这意味着您需要明确所有进入和离开子网的流量。例如，使用“全状态”规则方法（AWS 中的安全组适用的方法），您可以简单地为 SSH 指定 TCP/22 的入站流量，它会自动允许出站流量。对于 NACLS，情况并非如此，您需要在每个方向指定一个规则以允许流量通过。

安全组 - 这些是可应用于 VPC 中的一个或多个实例的完整规则组。请注意，它们适用于实例级别。安全组可以与传统的全状态防火墙进行比较，但由于它应用于单个实例级别，您甚至可以在同一子网内将实例彼此隔离，这很好。并且因为它们是全状态的，如果您想允许流量进入服务器（例如用于 SSH 的 TCP/22），您不必担心创建相应的出站规则，平台会自动处理，所以它们更容易管理 - 这也意味着出错的机会更少。

有一个很好的表格比较了这两者：VPC 安全性比较

该页面上还有一个很好的图表，它显示了根据流动方向应用于流量的事物的顺序......所以请检查一下。

然后就子网而言，我们有：

公共子网 - 在 AWS 术语中，这只是一个附加了路由表的子网，该路由表通过附加的 Internet 网关具有 0.0.0.0/0 路由

私有子网 - 这是相反的，即它没有通过附加 Internet 网关的 0.0.0.0/0 路由。请注意，它仍然可以通过 NAT 网关或您环境中的类似代理具有 0.0.0.0/0 路由，只是不是直接的。

问题是，当您拥有 NACLS 和安全组时 - 您使用哪个。AWS 将 NACL 描述为“您的 VPC 的可选安全层”。确实，一般来说安全组就足够了，它们更灵活并提供相同的保护。根据我的经验，在一些典型的情况下，我看到使用了 NACLS：

1. 已知不良行为者的黑洞 - 如果您受到来自特定 IP 范围的攻击，这是一种简单的方法，只需添加一个完全阻止 IP/子网源的 NACL。
2. 作为将控制权委托给团队的一种方式——安全团队应用广泛的 NACL 配置（例如只允许来自受信任企业网络的流量），然后允许运营/开发团队配置他们自己的安全组规则。这样，即使工程师尝试将其实例上的安全组开放到 Internet 进行测试，NACL 也会阻止它。您可以使用 IAM 来限制谁可以修改 NACL，但授予团队访问权限以控制其他一切，它可以作为大型环境中配置错误的一个很好的后盾。

AWS 还提供了有关此处提供的许多配置方案的一些指导：您的 VPC 的推荐网络 ACL 规则

不过，我的指导通常是安全组提供适当的保护，更易于理解和配置，并且在其应用程序中更加灵活和细化。NACL 确实为您提供了针对人为错误或更高级配置的额外支持，但对于基本用途，它们通常不使用。因此我假设为什么 AWS 将它们称为“可选”。

我会将 NACL 保留在其默认配置中（允许所有流量进出），而现在将重点放在安全组上，因为使用 NACL 作为第二层只会增加额外的复杂层，这在您的场景中可能不需要。从学习的角度来看，很高兴知道它们在那里，它们是无状态的，它们在子网级别应用，并且在路由决策之后和进入子网的流量的安全组之前应用。

关于您的具体情况，因为您使用的是 NACL，所以您需要记住它们是无状态的。因此，所有进出子网的流量都需要考虑在内——这是安全组如此简单的主要原因。所以在你的情况下，你有：

• 从您的 IP 通过 TCP/22 流量进入您的公共服务器 - 是的 - 规则 #300 入站
• 在高端口上从公共服务器返回流量以返回 SSH 流量 - 是的 - 规则 #50 出站（但不是规则 #300 - 见下文）
• 从公共子网出站到 TCP/22 上的私有子网的流量 - 是的 - 规则 #50 出站
• 来自公共网络的私有子网入站流量 - 是的 - 规则 #100 入站
• 将流量从您的私有服务器返回到私有子网上的公共服务器 - 是的 - 规则 #100 出站
• 将流量从您的私有服务器返回到公共子网上的公共服务器- 啊 - 不，没有规则允许高端口（ssh 客户端在公共服务器上使用的临时端口启动与私有服务器的连接）返回来自私人服务器。

您需要在出站公共子网 ACL 上添加类似规则 #300（但请注意，源 IP 的格式略有错误 - 见下文）之类的规则，但与私有子网的源绑定。然后假设您的安全组配置良好，那么您应该很高兴。

希望有帮助。

要添加 - 根据其他答案 - 公共子网出站规则集上的规则 #300 格式错误。它应该是 0.0.0.0/0 而不是 0.0.0.0/32，但是在您的情况下，您没有达到该规则，因为第 50 条规则首先被命中并且无论如何都允许所有流量 - 所以虽然它不起作用，但它不是实际上并没有导致你的问题。