☰

如何設定 AWS 網路存取控制清單以透過 SSH 存取私有子網

tag-icon • tag-icon ssh amazon-web-services access-control-list amazon-vpc
如何設定 AWS 網路存取控制清單以透過 SSH 存取私有子網

我正在上 AWS 課程。我想做的是設定一個有兩台 Linux 伺服器的 VPC。我已經設定了具有兩個子網路的 VPC。我在每個地方都放置了一台伺服器。這個想法是一個子網路是公共的，另一個子網路是私有的。

我建立了兩個網路 ACL，並將其與每個子網路關聯。

我可以從我的機器透過 SSH 連接到公共子網路中的伺服器。當我嘗試透過 SSH 連接到我的私有子網路中的伺服器時，出現連線逾時。

我不確定需要在兩個網路 ACL 中設定哪些規則才能讓 SSH 正常運作。有人可以幫忙嗎？鑑於我正在學習，我希望能夠解釋為什麼應該制定規則，而不僅僅是規則應該是什麼。

我有一個名為 MyVPC，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

答案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 範圍的攻擊，只需添加 NACL 即可完全阻止 IP/子網來源，這是一種簡單的方法。
  2. 作為將控制權委託給團隊的一種方式 - 安全團隊應用廣泛的 NACL 配置（例如僅允許來自受信任的公司網路的流量），然後允許營運/開發團隊配置自己的安全群組規則。這樣，即使工程師嘗試將其實例上的安全性群組開放到網際網路進行測試，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 首先被滿足並且無論如何都允許所有流量- 所以雖然它不起作用，但它並沒有達到實際上並沒有引起你的問題。

答案2

ACL 是無狀態的。

您的「公用」子網路可能會阻止來自私有子網路的 SSH 連線的返迴路徑。您還需要一個與入站端所有連接埠的出站規則相同的規則，但您可以將其限制在子網路範圍 10.0.2.0/24 內。

編輯新增：此外，0.0.0.0/32 的出站規則是錯誤的。除非你的 IP 剛好是 0.0.0.0，否則它不會起作用。

相關內容