AWS Network Firewall — Suricata 規則、TLS 檢測與集中部署

為什麼 AWS Network Firewall 對 ANS-C01 至關重要

AWS Network Firewall 是受管的、有狀態的深層封包檢測 (Deep Packet Inspection) 防火牆服務，ANS-C01 考試期望你對此瞭若指掌。網域 4 中任何涉及按 FQDN 封鎖外向流量、在出口執行 TLS 檢測或建構中央檢測 VPC 的問題，最終都會路由到 AWS Network Firewall。考試編寫者在大約五分之一的網域 4 題目中塞入了這項服務，因為 Network Firewall 恰好位於路由 (網域 2)、監控 (網域 3) 與安全性 (網域 4) 的交匯點，這正是 Specialty 考試旨在衡量的能力。

在本學習指南中，我們將從頭開始剖析 AWS Network Firewall：其架構 (防火牆、防火牆策略、規則群組)、無狀態與有狀態規則群組的區別、Suricata 相容的規則語法、使用匯入 ACM 憑證的 TLS 檢測、網域過濾 vs 5-tuple 過濾、透過 Transit Gateway 實現的分散式 vs 集中式部署拓撲、Firewall Manager 全組織自動化，以及流向 S3、CloudWatch 和 Kinesis 的日誌。我們還會將每個常見的 ANS-C01 陷阱題映射到底層行為，包括著名的「先評估無狀態」問題，這會難倒一半的初次考生。

這是一份 Specialty 深度筆記。涵蓋超過 5,400 字、10 個以上的 H2 章節、結尾的 FAQ 以及中文陷阱提醒。請閱讀兩遍，AWS Network Firewall 將不再是黑盒子，而是考試中可預測的答案模式。

AWS Network Firewall 架構概觀

AWS Network Firewall 由三個你必須理清的邏輯物件組成：防火牆 (Firewall)、防火牆策略 (Firewall Policy) 和規則群組 (Rule Group)。防火牆是每個 VPC 專有的物件，包含一個或多個防火牆端點 — 每個端點都是部署在防火牆子網特定可用區域中的彈性網路介面 (ENI)。防火牆策略是包含規則群組 (無狀態與有狀態) 的可重複使用容器，定義了檢測邏輯。規則群組本身也是可重複使用的；一個規則群組可以被多個防火牆策略參考，而一個策略可以套用到多個防火牆。

當流量透過防火牆子網路由表進入或離開 VPC 時，路由會將封包引導至該可用區域的防火牆端點 ENI。防火牆端點會檢測封包，並決定通過、丟棄或轉發以進行進一步處理。至關重要的是，AWS Network Firewall 是作為透明的內嵌 (Inline) 服務部署的：路由決定流量流向而非安全性群組，且從應用程式的角度來看，防火牆端點不消耗可路由的 IP 地址。流量進入 ENI 並離開 ENI；路由就是合約。

在生產環境中，AWS Network Firewall 的架構幾乎總是如下所示：

工作負載子網 (10.0.1.0/24)
  │
  │ 預設路由 0.0.0.0/0 → 防火牆端點 ENI
  ▼
防火牆子網 (10.0.0.0/28) ── 防火牆端點 (每個 AZ 一個 ENI)
  │
  │ 預設路由 0.0.0.0/0 → IGW 或 NAT 閘道
  ▼
網際網路閘道 (IGW) / NAT 閘道

這是單 VPC 分散式模式。每個 VPC 都有自己的防火牆、防火牆子網和 ENI。AWS Network Firewall 會按可用區域和流量規模水平擴展；隨著傳輸量增加，AWS 會自動在 ENI 後方佈建額外容量。你按每小時每個防火牆端點及處理的每 GB 資料付費，因此多可用區域部署成本較高，但多可用區域設計是任何 ANS-C01 高可用性答案的硬性要求。

無狀態規則群組：以線路速度進行 5-Tuple 過濾

AWS Network Firewall 無狀態規則群組執行 5-tuple 比對：源 IP、目的地 IP、源連接埠、目的地連接埠及協定。無狀態規則不追蹤連線 — 每個封包都是獨立評估的。這使得無狀態規則極快，也正是為什麼 AWS Network Firewall 會在檢測管道中最先評估它們。

無狀態規則有三種可能的動作：通過 (Pass, 轉發到有狀態檢測)、丟棄 (Drop, 捨棄) 或轉發 (Forward, 無視有狀態預設值直接送往有狀態規則群組)。每條規則都有優先順序，無狀態規則按優先順序評估直到觸發比對。如果沒有規則比對成功，則套用防火牆策略的無狀態預設動作 (通常是 aws:forward_to_sfe，即轉發到有狀態引擎)。

無狀態規則還支援自訂動作以發佈指標。你可以附加一個自訂動作，在規則觸發時發佈 CloudWatch 指標維度，這樣你就可以在不啟用完整串流日誌的情況下，針對命中特定無狀態規則的流量建立儀表板。考試偶爾會測試無狀態規則是否能進行網域比對 — 答案是不行。只有有狀態規則能看到第 7 層資料。

無狀態規則範例

典型的無狀態規則群組可能包含諸如「丟棄所有從 10.0.0.0/8 到 0.0.0.0/0 連接埠 53 的 UDP 封包」之類的規則，以封鎖向公有解析器進行的 DNS 資料外洩，或者「丟棄所有導向連接埠 23 (Telnet) 或 445 (SMB) 的 TCP 封包」以強制執行無舊版協定基準。這些規則以線速執行，增加的延遲極小，使其成為粗粒度過濾的理想選擇。

有狀態規則群組：Suricata 規則與連線追蹤

AWS Network Firewall 的有狀態規則群組是執行深層檢測的核心。有狀態規則會追蹤 TCP 連線狀態 (三次交握、FIN/RST 拆除、序列號)，並能根據第 7 層屬性進行比對，如 HTTP 主機標頭、TLS 伺服器名稱指示 (SNI) 和 HTTP URI 路徑。AWS Network Firewall 支援三種格式的有狀態規則：Suricata 相容規則、帶連線追蹤的 AWS 定義 5-tuple 規則，以及網域清單規則。

Suricata 是 AWS Network Firewall 內部使用的開源 IDS/IPS 引擎。Suricata 規則語法功能最強大，也是考試最相關的部分。一條 Suricata 規則如下所示：

alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:"Block uncategorized TLS"; tls.sni; content:"|0d|badsite.example|0d|"; sid:1000001; rev:1;)

drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"Block legacy User-Agent"; http.user_agent; content:"libwww-perl"; sid:1000002; rev:1;)

pass tcp any any -> any 443 (msg:"Allow HTTPS"; flow:established; sid:1000003; rev:1;)

每條規則包含動作 (alert, drop, pass, reject)、協定 (tcp, udp, http, tls, dns, smb, ftp, ssh, ip)、源和目的地以及規則選項。sid 是唯一的簽名 ID；rev 是修訂版本號。Suricata 規則根據規則群組設定，按預設順序或嚴格優先順序進行評估。

AWS 定義的 5-Tuple 有狀態規則

如果你不想編寫 Suricata 語法，AWS Network Firewall 提供了更友善的 5-tuple 有狀態規則格式。你只需提供源 IP、源連接埠、目的地 IP、目的地連接埠、協定和方向 (轉發或任意)，AWS 就會為你產生底層的 Suricata 規則。這些規則會自動追蹤連線狀態 — 一旦允許了外向 TCP SYN，有狀態引擎就會自動允許傳回的 SYN-ACK，無需顯示配置傳回規則。

網域清單規則 (Domain list rules)

網域清單規則是第三種有狀態格式，根據 FQDN 進行比對。你提供網域清單、目標類型 — 純 HTTP 為 HTTP_HOST，HTTPS 為 TLS_SNI — 以及動作 (允許或拒絕)。網域清單規則是實作外向流量 FQDN 出口允許清單最簡單的方法。考試頻繁測試此模式，因為它是「除了核准的 SaaS 提供商外封鎖所有外向連線」的標準答案。

網域清單規則不需要執行完整的 TLS 解密來讀取 HTTP 主機標頭。對於 TLS 流量，規則會讀取 TLS 交握中未加密 ClientHello 的 SNI。這意味著即使不啟用 TLS 檢測，網域規則也能看到 SNI，但它無法驗證實際目的地是否與 SNI 匹配 (高級攻擊者可以在 SNI 中偽造)。對於高保證環境，請將網域清單規則與 TLS 檢測結合使用。

TLS 檢測：解密流量以獲得第 7 層可見性

TLS 檢測是 AWS Network Firewall 的一項功能，它會解密 TLS 流量、對純文字負載執行深層檢測，並在轉發前重新加密。對於涉及監控加密出口流量、檢測 HTTPS 上的惡意軟體命令與控制以及向雲端儲存進行資料外洩的網域 4 問題，TLS 檢測至關重要。

AWS Network Firewall 的 TLS 檢測支援雙向：外向 (VPC 工作負載到網際網路目的地) 和內向 (網際網路用戶端到 VPC 工作負載)。這兩種模式需要不同的憑證處理。

對於外向 TLS 檢測，你配置一個參考 AWS Certificate Manager 中儲存的憑證授權單位 (CA) 憑證的 TLS 檢測配置。CA 憑證用於為工作負載聯繫的目的地動態產生冒充憑證。為了使此機制運作，每個發起外向 TLS 的工作負載都必須信任該 CA 憑證；否則，工作負載的 TLS 交握將會失敗，因為它接收到的伺服器憑證 (冒充憑證) 是由不受信任的 CA 簽發的。

對於內向 TLS 檢測，你將實際的伺服器憑證 (你的工作負載呈現給用戶端的憑證) 匯入 ACM，防火牆會使用它在防火牆處終止 TLS 並重新加密到後端。後端可能使用不同的憑證甚至純文字。

TLS 檢測的效能與隱私

TLS 檢測會增加 CPU 成本 (解密 + 重新加密) 和檢測延遲。AWS Network Firewall 會透明地處理這些，但會有比非檢測流量更高的每 GB 處理費。從隱私角度看，TLS 檢測破壞了端到端加密保證；某些目的地 (銀行、醫療入口網站) 在其服務條款中明確禁止中間人檢測。AWS Network Firewall 支援「範圍 (Scope)」功能，讓你可以將特定目的地排除在 TLS 檢測之外 — 例如，永遠不檢測 *.bank.com 的流量。

集中式 vs 分散式部署拓撲

AWS Network Firewall 可以部署在兩種架構模式中：分散式與集中式。選擇取決於 VPC 數量、營運模式和成本約束。ANS-C01 題目經常要求你根據情境選擇正確模式。

分散式部署 (Distributed deployment)

在分散式模式中，每個 VPC 都有自己的 AWS Network Firewall。每個 VPC 擁有自己的防火牆、防火牆策略、規則群組和路由。此模式邏輯簡單，沒有共享的爆炸半徑，是小型環境的預設起點。缺點是成本高 — 每個 VPC 都需為每個 AZ 的防火牆端點付費 — 以及規則一致性問題，這需要 Firewall Manager 或 IaC 紀律來維持。

透過 Transit Gateway 的集中式部署 (Centralized deployment)

在集中式模式中，單個檢測 VPC 託管 AWS Network Firewall，Transit Gateway 將來自支點 VPC 的流量路由到檢測 VPC。此模式將防火牆端點數量從 N×AZs 減少到 1×AZs，大幅降低大規模部署的成本。它實現了規則的集中管理。這是「我們有 50 個 VPC 並需要一致的出口檢測」的標準答案。

集中式模式需要精確的 Transit Gateway 路由。支點 VPC 將所有流量發送到 TGW。支點連接的 TGW 路由表指向檢測 VPC 連接。檢測 VPC 的 TGW 連接必須處於設備模式 (Appliance Mode)，這能確保給定流量在進入和出去時使用相同的 AZ — 如果不開啟設備模式，回程流量可能會通過不同的 AZ 返回並繞過防火牆 (流量狀態將不匹配)。

集中式模式中的路由

集中式檢測的路由表設計如下：

支點 VPC 子網 → 0.0.0.0/0 → TGW
TGW 支點路由表 → 0.0.0.0/0 → 檢測 VPC 連接
檢測 VPC 防火牆子網 → 0.0.0.0/0 → 防火牆端點 ENI
檢測 VPC 公有子網 → 0.0.0.0/0 → IGW 或 NAT 閘道
TGW 檢測路由表 → 10.0.0.0/8 → 支點 VPC 連接

這裡刻意設定了兩個 TGW 路由表 — 一個用於支點 (預設路由到檢測)，一個用於檢測 VPC (特定路由回支點)。這種分離防止了流量繞過檢測。

Firewall Manager：全組織自動化

AWS Firewall Manager 是針對 AWS Network Firewall、AWS WAF、AWS Shield Advanced、安全性群組以及 Route 53 Resolver DNS Firewall 的多帳戶、多區域編排層。對於 ANS-C01，Network Firewall 的使用案例最為相關。

Firewall Manager 的 Network Firewall 策略指定了防火牆策略 ARN、範圍內的 AWS Organizations OU 或帳戶，以及部署模型 (集中式檢測 VPC 或分散式單 VPC)。當新帳戶加入組織或建立新 VPC 時，Firewall Manager 會自動建立防火牆、附加策略並修復配置漂移。不合規資源會以調查結果的形式呈現。

Firewall Manager 要求啟用 AWS Organizations 的所有功能、啟用 AWS Config 的成員帳戶以及委派管理員帳戶。考試會測試你是否記得這些前提條件 — 建議在沒有 Organizations 的情況下使用 Firewall Manager 的答案都是錯誤的。

日誌記錄：警示日誌與串流日誌

AWS Network Firewall 產生兩種日誌類型：警示日誌 (Alert logs) 和串流日誌 (Flow logs)。警示日誌記錄具有 alert 或 drop 動作的有狀態規則事件 — 這些是與安全性相關的發現。串流日誌記錄通過防火牆的每個連線的元資料 — 這些是網路可見性記錄。兩者均可發送到 S3、CloudWatch Logs 或 Kinesis Data Firehose。

警示日誌是 SIEM 整合的主要來源。典型的警示日誌項目包含防火牆 ARN、源及目的地 IP 地址與連接埠、協定、比對的簽名 ID (sid)、規則訊息以及動作。你可以使用 Amazon Athena 搭配分區投影來查詢 S3 中的警示日誌，進行基於時間的過濾。

串流日誌在結構上與 VPC Flow Logs 類似，但包含防火牆處理特定的額外欄位 — 檢測結果 (pass, drop, alert)、比對的規則群組以及連線狀態。串流日誌量很大；對於大型環境，請將其發送到 Kinesis Firehose 並進行壓縮以控制儲存成本。

常見規則模式與使用案例

以下是 ANS-C01 考生應熟記的六種規則模式。

模式 1：出口 FQDN 允許清單

使用帶有 TLS_SNI 和 HTTP_HOST 目標類型的網域清單有狀態規則群組。列出核准的網域 (*.amazonaws.com, *.salesforce.com, github.com)。將預設有狀態動作設定為 drop established。導向任何其他 FQDN 的外向流量都將在防火牆被封鎖。

模式 2：封鎖已知惡意 IP

使用一個目的地 IP 設定為 AWS 受管已知惡意 IP 前綴清單 (或你維護的自訂前綴清單) 的無狀態規則群組。無狀態丟棄速度快且不消耗連線追蹤資源。

模式 3：僅 IDS 模式

將所有有狀態規則的動作設定為 alert 而非 drop。防火牆會觀察流量並產生警示日誌而不會進行攔截。這是推薦的部署初期模式；觀察一週，驗證合法流量不會產生誤報警示後，再將動作切換為 drop。

模式 4：合規性要求的外向 TLS 檢測

使用匯入的 CA 憑證啟用 TLS 檢測。配置一條 Suricata 規則，丟棄帶有與惡意軟體相關的特定 TLS JA3 指紋的流量。透過 SSM State Manager 向所有工作負載分發 CA 憑證。

模式 5：東西向檢測 (East-west inspection)

使用帶有 TGW 設備模式的集中式檢測 VPC 模式，但配置針對 RFC 1918 源及目的地地址進行比對的規則。這會檢測 VPC 對 VPC 的流量，而不僅僅是向網際網路的外向流量。

模式 6：封鎖加密 DNS (DoH)

將網域清單規則 (deny dns.google, cloudflare-dns.com) 與丟棄導向已知 DoH 伺服器 IP 範圍的外向無狀態規則相結合。這會強制所有 DNS 解析通過 Route 53 Resolver，由 DNS Firewall 進行檢測。

白話文解釋

AWS Network Firewall 聽起來很硬，但只要用日常生活的類比，你會發現它其實沒那麼複雜。底下三個比喻挑你最有感覺的記住即可。

類比一：機場海關（Stateless vs Stateful 兩道關卡）

把每個進出 VPC 的封包想像成出入境的旅客，AWS Network Firewall 就是機場海關，而 stateless 跟 stateful 是兩道不同性質的檢查站：

• 無狀態規則 (Stateless rule group) = 第一道金屬探測門。它不認得你，只看你身上有沒有金屬（5-tuple：來源 IP、目的 IP、協定、port）。每位旅客獨立檢查，不管你是不是同一團人。這道門很快，因為它不需要記憶。所以它一定排在最前面。
• 有狀態規則 (Stateful rule group) = 第二道海關官員的詢問桌。海關會記住「這位旅客剛剛入境，等下他離境是同一個人」，所以連線狀態（TCP handshake、return traffic）會被自動追蹤。Suricata rule 就像海關手冊裡的「可疑行為清單」，包括 SNI、HTTP host 這種 Layer 7 細節。
• 網域清單規則 (Domain list rule) = 海關手上那張「禁止前往國家清單」。只要你護照上的目的地（SNI / HTTP Host）出現在黑名單，立刻拒絕通行。
• TLS 檢測 (TLS inspection) = 海關打開你的密封信封檢查內容。但要打開信封，海關自己得有「機場專用印章」（CA certificate），而你也得事先承認這個印章（信任 CA），不然你會覺得海關偽造文件就拒絕配合。

如果第一道金屬探測門就把你攔下（stateless drop），你根本不會走到第二道海關（stateful 不會評估）。這就是「stateless 先評估」的核心邏輯。

類比二：公司大樓的兩種管制（Distributed vs Centralized）

把 50 個 VPC 想像成公司在不同城市的 50 個分公司，每個分公司都需要管制誰可以進出。

• 分散式部署 (Distributed deployment) = 每個分公司自己僱保全。優點是各做各的、出事不會互相影響；缺點是 50 份保全薪水。
• 集中式部署 (Centralized deployment via Transit Gateway) = 全公司集中在總部設一個保全室，所有分公司的訪客先搭高鐵（TGW）到總部，由總部保全檢查完再放行。便宜又一致，但你必須確保「同一個人去回都走同一條軌道」（appliance mode），不然回程的人換條路回來，保全會說「沒看過你」就拒絕讓你入境。

類比三：圖書館的借書規則手冊（Suricata Rule）

把有狀態規則群組想成圖書館管理員的「借書違規行為手冊」。每位讀者（封包）走進來，管理員依序看手冊：

• 規則 1：書包裡有食物（drop tcp ... content:"食物"）→ 趕出去。
• 規則 2：身分證是 VIP（pass tls ... tls.sni:"vip-domain"）→ 直接放行。
• 規則 3：穿著運動服但偷偷帶相機（http.user_agent:"libwww-perl"）→ 通報並驅離（alert + drop）。
• 規則 4（預設）：沒中規則就採取預設動作（drop established 或 forward）。

每條規則都有 sid（編號）跟 rev（修訂版本）。當你修改規則但忘了升 rev，AWS Network Firewall 不會重新編譯，這也是常見地雷。

情境分析

兩個鏡像 ANS-C01 題目風格的情境：

情境 A：跨 50 個 VPC 封鎖除核准 FQDN 以外的所有外向流量

要求：一家金融服務公司在 3 個 AWS 區域擁有 50 個生產 VPC。安全性團隊必須對所有外向 HTTPS 流量強制執行單一的核准 SaaS 網域允許清單。新增網域必須在幾分鐘內傳播。合規稽核員要求集中報告。

正確答案：建立一個具有網域清單規則群組 (TLS_SNI 目標, allow 動作) 的 AWS Network Firewall 策略，列出核准的網域，並將預設有狀態動作設定為 drop established。使用 AWS Firewall Manager 在 AWS Organizations 中部署該策略，並採用每個區域集中式檢測 VPC (TGW + appliance mode) 的模式。日誌透過 Kinesis Firehose 發送到中央 S3 儲存貯體。網域更新透過規則群組 ARN 傳播 — Firewall Manager 在幾分鐘內重新評估。

錯誤答案：NACL (無法按 FQDN 比對)、安全性群組 (無法按 FQDN 比對) 或沒有 Firewall Manager 的每個 VPC 分散式防火牆 (營運漂移不可避免)。

情境 B：在出口執行 TLS 檢測以偵測惡意軟體 C2

要求：一家醫療 SaaS 提供商需要偵測 EC2 工作負載外向流量中 HTTPS 上的惡意軟體命令與控制。安全性團隊擁有一份來自威脅情資的惡意 JA3 指紋清單。

正確答案：在出口防火牆上啟用 AWS Network Firewall TLS 檢測。將 CA 憑證 (來自 AWS Private CA) 匯入 ACM 並在 TLS 檢測配置中參考。透過 Systems Manager 向 EC2 工作負載分發 CA 憑證。新增具有 tls.ja3.hash 比對的 Suricata 規則，以丟棄已知惡意的指紋。將警示日誌發送到中央安全性 S3 儲存貯體供 SIEM 擷取。

錯誤答案：AWS WAF (不檢測外向流量)、針對串流日誌的 CloudWatch 警示 (無 TLS 可見性)、僅使用 GuardDuty (能偵測已知威脅但無法執行內嵌檢測或封鎖)。

常見考試陷阱與反模式

其他反模式：

• 忘記在集中式檢測 VPC 的 TGW 連接上啟用設備模式。
• 嘗試使用 ACM 請求發行的公有憑證作為 TLS 檢測的 CA (ACM 不發行 CA 憑證；你必須匯入)。
• 將防火牆放置在直接連接到 IGW 的公有子網中 — 防火牆必須位於擁有顯示路由的專用子網中。
• 假設有狀態規則會平等地封鎖每個封包 — 有狀態預設動作必須設定為 drop established 或 drop strict 才能真正執行預設封鎖。
• Suricata 規則中遺漏了 flow:established 關鍵字，這會導致規則比對沒有狀態的 SYN 封包。
• 忘記帶有 sid 衝突的 Suricata 規則會靜默加載失敗。
• 相信 AWS Network Firewall 可以解密任何 TLS 流量 — 它只能解密工作負載信任該 CA 且 SNI 未被鎖定 (Pinned) 的流量。

定價與配額

AWS Network Firewall 按每個防火牆端點每小時計費 (約 $0.395/小時/端點，因區域而異)，外加每 GB 處理費 (約 $0.065/GB)。TLS 檢測會增加增量處理費用。在使用三個可用區域進行冗餘的情況下，單個防火牆的每小時成本大約是每月 $850 (不含流量費)。對於分散式模式下的 50 個 VPC，這每月超過 $40,000 — 這正是集中式檢測如此具備吸引力的原因。

需記住的配額限制：每個規則群組 30 條無狀態規則 (預設)、每個防火牆策略 30 個有狀態規則群組、每個防火牆策略 1 個 TLS 檢測配置、每個有狀態規則群組 30,000 條 Suricata 規則 (受管限制)。對於高規則數量的環境，可透過 Service Quotas 請求提高限制。

與其他 AWS 服務的整合

AWS Network Firewall 與 AWS 服務緊密整合：

• VPC：防火牆端點是專用防火牆子網中的 ENI；路由表決定流量流向。
• Transit Gateway：採用設備模式的檢測 VPC 模式，用於集中式東西向與南北向檢測。
• Route 53 Resolver DNS Firewall：互補服務，過濾 DNS 查詢；與 Network Firewall 搭配使用可實現完整的 DNS + IP/L7 覆蓋。
• Firewall Manager：全組織策略部署與漂移修復。
• CloudWatch Logs / S3 / Kinesis：警示與串流日誌的日誌目的地。
• Security Hub：警示日誌會輸入 Security Hub 調查結果。
• Lambda + EventBridge：當高嚴重性警示觸發時執行自動化修復 (例如隔離受損的 ENI)。

FAQ

Q1: AWS Network Firewall 是有狀態還是無狀態的？

兩者皆是。AWS Network Firewall 具有兩個評估引擎：一個以線速執行 5-tuple 比對的無狀態引擎，以及一個運行帶有連線追蹤的 Suricata 相容規則的有狀態引擎。流量始終先由無狀態引擎評估；如果無狀態動作是「轉發到 SFE」(預設值)，封包將進入有狀態引擎。這種結合提供了快速過濾與深層第 7 層檢測的優勢。

Q2: AWS Network Firewall 能取代 AWS WAF 嗎？

不能。AWS WAF 是第 7 層網頁應用程式防火牆，保護 HTTP/HTTPS 端點 (CloudFront, ALB, API Gateway) 免受 SQLi、XSS 和機器人濫用等應用層威脅。AWS Network Firewall 是第 3-7 層防火牆，保護整個 VPC 免受網路層威脅並強制執行基於 FQDN 的出口策略。它們用途不同 — 大多數生產架構會同時使用兩者：邊緣處在負載平衡器前用 WAF，VPC 路由路徑上用 Network Firewall。

Q3: Network Firewall 網域清單規則與 Route 53 Resolver DNS Firewall 有什麼區別？

Route 53 Resolver DNS Firewall 在解析器處過濾 DNS 查詢 — 它為受封鎖網域返回 NXDOMAIN 或自訂 IP。AWS Network Firewall 網域清單規則過濾實際的 TCP/HTTP/TLS 流量 — 它允許 DNS 正常解析，但封鎖隨後的連線。DNS Firewall 較便宜且能防止工作負載獲取 IP，通常是首選。Network Firewall 網域規則能捕捉使用硬編碼 IP 或外部 DNS 解析器 (DoH) 的流量。

Q4: 為什麼集中式檢測必須開啟設備模式？

如果不開啟設備模式，Transit Gateway 會隨機在可用區域間散列流量。單個 TCP 連線可能從 AZ-a 進入檢測 VPC，但回程流量可能從 AZ-b 返回。AZ-b 中的有狀態防火牆沒有原始連線紀錄 (狀態存在於 AZ-a 中)，因此它會將封包視為不合法狀態而丟棄。設備模式將流量在雙向均釘住在一個 AZ，確保同一個防火牆端點能看到整個連線。

Q5: 我能否使用 AWS Network Firewall 檢測 VPC 對 VPC 的流量？

可以，透過集中式檢測 VPC 模式。支點 VPC 將跨 VPC 流量路由到 Transit Gateway；TGW 將流量路由到檢測 VPC 防火牆端點；防火牆檢測後轉發回 TGW；TGW 路由到目的地支點。東西向檢測是集中式檢測最常見的使用案例之一。

Q6: Network Firewall 如何處理使用非標準 TLS 或自訂協定的流量？

有狀態 Suricata 規則支援通用的 TCP 和 IP 比對，因此即使沒有協定特定解析，你也能透過 5-tuple 封鎖流量。對於非 TLS 的加密協定，若沒有協定特定的解密功能 (AWS Network Firewall 對非 TLS 不提供此功能)，你無法檢測負載內容。備案是允許清單已知合法的 IP 並封鎖其餘所有內容。

Q7: 對於 ANS-C01 風格的生產環境，我應該啟用哪種日誌模式？

警示日誌和串流日誌都要啟用。將警示日誌發送到 S3 進行長期保留與 SIEM 擷取 (典型保留期：合規要求 1 年)。將串流日誌發送到 Kinesis Firehose 並轉換為 Parquet 格式存入 S3，以便進行即時 Athena 查詢。警示日誌數量的警示可偵測攻擊波；串流日誌數量可偵測基準流量異常。

Q8: 如何從第三方防火牆設備遷移到 AWS Network Firewall？

第一階段：與現有設備並行部署處於僅 IDS 模式 (動作均為 alert) 的 Network Firewall。第二階段：驗證警示日誌是否符合預期流量模式；精煉規則。第三階段：將檢測規則中的 alert 切換為 drop。第四階段：從路由路徑中移除第三方設備。僅 IDS 階段對於避免在切換期間封鎖合法流量至關重要。

Q9: Network Firewall 是否支援跨可用區域的高可用性？

是的 — AWS Network Firewall 設計為每個可用區域部署一個防火牆端點。每個端點在其可用區域內都是高可用性的 (AWS 管理 ENI 後方的容量)。為了實現跨可用區域的彈性，請在至少兩個可用區域部署端點，並配置子網路由表將流量引導至當地的防火牆端點。考試期望任何生產級答案都具備多可用區域特性。

Q10: Network Firewall 能否封鎖單個 VPC 內的橫向移動？

間接地可以。Network Firewall 位於子網間的路由路徑上，因此可以檢測跨越子網邊界的流量。對於同一個子網內 (執行個體對執行個體) 的橫向移動，請使用具有參考來源 SG 的安全性群組。結合透過 Network Firewall 的子網級路由以及執行個體級安全性群組，可提供完整的橫向移動防護。

總結：AWS Network Firewall 答案模式

當你在 ANS-C01 中讀到涉及 Network Firewall 的題目時，請跑一遍此檢核表：

• 要求是按 FQDN 封鎖出口嗎？ → 帶有 TLS_SNI/HTTP_HOST 的 AWS Network Firewall 網域清單規則群組。
• 要求是檢測 TLS 負載中的惡意軟體嗎？ → 使用匯入 CA 憑證的 AWS Network Firewall TLS 檢測。
• 要求是跨 10 個以上 VPC 強制執行規則嗎？ → 帶有 Network Firewall 策略的 AWS Firewall Manager。
• 要求是高成本效益地集中檢測嗎？ → 集中式檢測 VPC + 開啟設備模式的 TGW。
• 題目是問為什麼有狀態規則沒生效嗎？ → 先檢查無狀態引擎 (可能正在丟棄或未轉發)。
• 題目是關於可用區域間的不對稱路由嗎？ → TGW 連接上的設備模式。
• 題目是關於 TLS 檢測憑證設定嗎？ → 將 CA 憑證匯入 ACM (不能請求發行)。

AWS Network Firewall 是 VPC 級深層封包檢測、基於 FQDN 的出口過濾以及 TLS 可見性的標準答案。掌握無狀態優先的評估順序、設備模式要求、匯入 CA 憑證流程以及 Firewall Manager 組織模型，網域 4 中關於 Network Firewall 的問題將變為模式比對練習。

常考陷阱

• Stateless rule 先評估 — 任何「stateful 規則沒生效」的題目，先檢查 stateless engine 是否先 drop 或沒 forward to SFE。
• TLS inspection 必須 import CA 憑證 — ACM 不簽 CA 憑證，必須用 AWS Private CA 或自有 CA 產生後 import 到 ACM。
• Appliance mode 是中央化檢查的硬性需求 — 沒開啟，回程流量會走錯 AZ，stateful 連線狀態對不上，封包被丟。
• Network Firewall 不取代 Security Group — SG 是 ENI 級身份控制，Network Firewall 是路由路徑檢查，兩者是互補。
• Suricata sid 不可重複 — 規則 sid 衝突會靜默 fail，整個 rule group 不載入。
• Domain list rule 看的是 SNI / HTTP Host — 不需開啟 TLS inspection 也能用，但攻擊者可以偽造 SNI；高保證需求請搭配 TLS inspection。
• Firewall Manager 需要 AWS Organizations + Config — 沒有 Organizations 就不能用 Firewall Manager 自動部署。
• Network Firewall 端點是 ENI，要單獨子網路 — 不要把它放在跟工作負載一起的 subnet。
• 跨 AZ 必須多端點 — 一個 firewall 一個 AZ 一個 ENI；多 AZ 部署需要每個 AZ 都有端點。
• Drop 預設動作要設定 — 預設 stateful action 是 forward to SFE，等於沒開拒絕；要改成 drop established 才會真正擋。