設定 Azure 防火牆規則

  • 發行項

您可以使用傳統規則或防火牆原則，在 Azure 防火牆上設定 NAT 規則、網路規則和應用程式規則。 在手動設定規則以允許流量之前，Azure 防火牆預設會拒絕所有流量。

使用傳統規則時的規則處理方式

系統會根據規則類型的優先順序 (數字由低到高，100 到 65,000) 處理規則集合。 規則集合名稱只能有字母、數字、底線、句點或連字號。 其必須以字母或數字開頭，並以字母、數字或底線結束。 最大名稱長度為 80 個字元。

一開始最好先以 100 作為遞增單位，將規則集合的優先順序數字隔開 (100、200、300 等)，以便有空間可在需要時新增更多規則集合。

使用防火牆原則時的規則處理方式

使用防火牆原則時，規則會組織在規則集合和規則集合群組內。 規則集合群組包含零個或多個規則集合。 規則集合的類型為NAT、網路或應用程式。 您可以在單一規則群組內定義多個規則集合類型。 您可以在規則集合中定義零個或多個規則。 規則集合中的規則必須屬於相同類型 (NAT、網路或應用程式)。

規則會根據規則集合群組優先順序和規則集合優先順序進行處理。 優先順序是介於 100 到 65,000 之間任何數位（優先順序最低）。 優先順序最高的規則集合群組會先處理。 在規則集合群組內，會先處理優先順序最高的規則集合（最低數位）。

如果防火牆原則繼承自父原則，則不論子原則的優先順序為何，父原則中的規則集合群組一律優先。

注意

應用程式規則一律會在網路規則之後處理，不論規則集合群組或規則集合優先順序和原則繼承為何，都會在DNAT規則之後進行處理。

以下是範例原則：

假設BaseRCG1是規則集合群組優先順序 （200），其中包含規則集合：DNATRC1、DNATRC3、NetworkRC1。
BaseRCG2 是規則集合群組優先順序 （300），其中包含規則集合：AppRC2、NetworkRC2。
ChildRCG1 是規則集合群組優先順序 （200），其中包含規則集合：ChNetRC1、ChAppRC1。
ChildRCG2 是包含規則集合的規則集合群組：ChNetRC2、ChAppRC2、ChDNATRC3。

根據下表：

名稱 類型 優先順序 規則 繼承來源
BaseRCG1 規則集合群組 200 8 父原則
DNATRC1 DNAT 規則集合 600 7 父原則
DNATRC3 DNAT 規則集合 610 3 父原則
NetworkRC1 網路規則集合 800 1 父原則
BaseRCG2 規則集合群組 300 3 父原則
AppRC2 應用程式規則集合 1200 2 父原則
NetworkRC2 網路規則集合 1300 1 父原則
ChildRCG1 規則集合群組 300 5 -
ChNetRC1 網路規則集合 700 3 -
ChAppRC1 應用程式規則集合 900 2 -
ChildRCG2 規則集合群組 650 9 -
ChNetRC2 網路規則集合 1100 2 -
ChAppRC2 應用程式規則集合 2000 7 -
ChDNATRC3 DNAT 規則集合 3000 2 -

初始處理：

此程式從檢查規則集合群組 （RCG） 作為最低數字開始，也就是優先順序為 200 的 BaseRCG1。 在此群組中，它會搜尋DNAT規則集合，並根據優先順序來評估它們。 在此情況下，會找到DNATRC1（優先順序 600）和DNATRC3（優先順序 610）並據以處理。
接下來，它會移至下一個 RCG BaseRCG2（優先順序 200），但找不到 DNAT 規則集合。
之後，它繼續進行兒童RCG1（優先300），也沒有DNAT規則集合。
最後，它會檢查 ChildRCG2 （優先順序 650），並尋找 ChDNATRC3 規則集合（優先順序 3000）。

規則集合群組內的反覆專案：

回到BaseRCG1，反覆項目會繼續進行，這次是NETWORK規則。 只會找到 NetworkRC1 （優先順序 800）。
然後，它會移至BaseRCG2，其中 NetworkRC2 （優先順序 1300） 位於其中。
繼續移至 ChildRCG1，它會將 ChNetRC1 （優先順序 700） 探索為網路規則。
最後，在 ChildRCG2 中，它會將 ChNetRC2 （優先順序 1100） 尋找為 NETWORK 規則集合。

應用程式規則的最終反覆專案：

返回BaseRCG1，程式會針對APPLICATION規則進行反覆運算，但找不到任何規則。
在BaseRCG2中，它會將AppRC2 （優先順序1200） 識別為APPLICATION規則。
在 ChildRCG1 中，ChAppRC1 （優先順序 900） 會以 APPLICATION 規則的形式找到。
最後，在 ChildRCG2 中，它會將 ChAppRC2 （優先順序 2000） 找出為 APPLICATION 規則。

總而言之，規則處理順序如下所示：DNATRC1、DNATRC3、ChDNATRC3、NetworkRC1、NetworkRC2、ChNetRC1、ChNetRC2、AppRC2、ChAppRC1、ChAppRC2。

此程式牽涉到依優先順序分析規則集合群組，並在每個群組內根據規則類型（DNAT、NETWORK 和 APPLICATION）的優先順序來排序規則。

因此，首先，所有 DNAT 規則都會從所有規則集合群組進行處理，並依優先順序分析規則集合群組，並依優先順序排序每個規則集合群組內的 DNAT 規則。 然後，網路規則的相同程序，最後用於APPLICATION規則。

如需防火牆原則規則集的詳細資訊，請參閱 Azure 防火牆 原則規則集。

威脅情報

如果您啟用威脅情報型篩選，這些規則會是最高的優先順序，而且一律會先處理（在網路和應用程式規則之前）。 威脅情報篩選可能會在處理任何已設定的規則之前拒絕流量。 如需詳細資訊，請參閱 Azure 防火牆威脅情報型篩選。

IDPS

在警示模式中設定 IDPS 時，IDPS 引擎會與規則處理邏輯平行運作，並針對輸入和輸出流程產生相符簽章的警示。 若與 IDPS 簽章相符，則會在防火牆記錄中記錄警示。 不過，由於 IDPS 引擎與規則處理引擎平行運作，因此應用程式/網路規則拒絕或允許的流量仍可能會產生另一個記錄專案。

在警示和拒絕模式中設定 IDPS 時，IDPS 引擎會在規則處理引擎之後內嵌並啟動。 因此，這兩個引擎都會產生警示，而且可能會封鎖比對流程。 

由 IDPS 執行的工作階段中斷會悄無聲息地封鎖流量。 因此，TCP 層級上不會傳送任何 RST。 由於IDPS會在網路/應用程式規則相符之後一律檢查流量（允許/拒絕），並在記錄中標示，因此IDPS決定因為簽章相符而拒絕會話的位置可能會記錄另一個 Drop 訊息。

啟用未加密和加密流量的 TLS 檢查時。 

輸出連線

網路規則和應用程式規則

如果您設定網路規則和應用程式規則，則會在應用程式規則之前依優先順序套用網路規則。 規則正在終止。 因此，如果在網路規則中找到相符專案，則不會處理任何其他規則。 如果已設定，IDPS 會在所有周遊流量和簽章相符時完成，IDPS 可能會發出警示或/並封鎖可疑流量。

如果沒有任何網路規則相符，且通訊協定為 HTTP、HTTPS 或 MSSQL，則應用程式規則會依優先順序評估封包。

針對 HTTP，Azure 防火牆 根據主機標頭尋找應用程式規則相符專案。 若為 HTTPS，Azure 防火牆只會根據 SNI 來尋找相符的應用程式規則。

在 HTTP 和 TLS 檢查的 HTTPS 案例中，防火牆會忽略封包的目的地 IP 位址，並使用來自主機標頭的 DNS 解析 IP 位址。 防火牆預期會在主機標頭中取得埠號碼，否則會假設標準埠 80。 如果實際 TCP 連接埠與主機標頭中的埠不符，則會捨棄流量。 DNS 解析會由 Azure DNS 或由自訂 DNS (若已在防火牆上設定) 來進行。 

注意

HTTP 和 HTTPS 通訊協定（使用 TLS 檢查）一律會填入 Azure 防火牆 XFF （X-Forwarded-For） 標頭等於原始來源 IP 位址。 

當應用程式規則包含 TLS 檢查時，防火牆規則引擎會處理 SNI、主機標頭，以及符合規則的 URL。

如果在應用程式規則中仍然找不到相符專案，則會根據基礎結構規則集合評估封包。 如果仍然沒有相符專案，則預設會拒絕封包。

注意

網路規則可以針對 TCP、UDP、ICMP 或任何 IP 通訊協定進行設定。 任何IP通訊協定都包含因特網指派號碼授權單位 （IANA） 通訊協定號碼檔中定義的所有IP通訊協定。 如果明確設定目的地埠，則規則會轉譯為 TCP+UDP 規則。 在 2020 年 11 月 9 日之前， 任何 表示 TCP 或 UDP 或 ICMP。 因此，您可能已在該日期 之前使用 Protocol = Any 設定規則，而 目的地埠 = '*'。 如果您不想允許目前定義的任何IP通訊協定，請修改規則以明確設定您想要的通訊協定（TCP、UDP 或ICMP）。

輸入連線

DNAT 規則和網路規則

您可以設定目的地網路位址轉換 （DNAT）來啟用輸入因特網連線，如使用 Azure 入口網站 篩選具有 Azure 防火牆 DNAT 的輸入流量中所述。 NAT 規則會依其優先順序，優先於網路規則套用。 如果找到相符專案，流量會根據DNAT規則轉譯，並由防火牆允許。 因此，流量不會受到其他網路規則的任何進一步處理。 基於安全性理由，建議的方法是新增特定的網際網路來源，以允許 DNAT 存取網路，並避免使用萬用字元。

應用程式規則不適用於輸入連線。 因此，若要篩選輸入 HTTP 或 HTTPS 流量，建議使用 Web 應用程式防火牆 (WAF)。 如需詳細資訊，請參閱什麼是 Azure Web 應用程式防火牆？

範例

下列範例顯示其中一些規則組合的結果。

範例 1

因為有相符的網路規則，因此允許 google.com 連線。

網路規則

  • 動作：允許
NAME 通訊協定 來源類型 來源 目的地類型 目的地位址 目的地連接埠
Allow-web TCP IP 位址 * IP 位址 * 80,443

應用程式規則

  • 動作：Deny
NAME 來源類型 來源 通訊協定:連接埠 目標 FQDN
Deny-google IP 位址 * http:80,https:443 google.com

結果

允許連線至 google.com，因為封包符合 Allow-web 網路規則。 正在處理的規則會於此時停止。

範例 2

SSH 流量遭到拒絕，因為較高的優先順序 拒絕 網路規則集合會封鎖它。

網路規則集合 1

  • 名稱：Allow-collection
  • 優先順序：200
  • 動作：允許
NAME 通訊協定 來源類型 來源 目的地類型 目的地位址 目的地連接埠
Allow-SSH TCP IP 位址 * IP 位址 * 22

網路規則集合 2

  • 名稱：Deny-collection
  • 優先順序：100
  • 動作：Deny
NAME 通訊協定 來源類型 來源 目的地類型 目的地位址 目的地連接埠
Deny-SSH TCP IP 位址 * IP 位址 * 22

結果

SSH 連線遭到拒絕，因為較高的優先順序網路規則集合會封鎖它。 正在處理的規則會於此時停止。

規則變更

如果您將規則變更為拒絕先前允許的流量，則會捨棄任何相關的現有工作階段。

三向交握行為

作為具狀態服務，Azure 防火牆 完成從來源到目的地的允許流量的 TCP 三向交握。 例如，VNet-A 到 VNet-B。

建立允許從 VNet-A 到 VNet-B 的規則，不表示就允許起始從 VNet-B 到 VNet-A 的新連線。

因此，不需要建立從 VNet-B 到 VNet-A 的明確拒絕規則。 如果您建立此拒絕規則，您會中斷從 VNet-A 到 VNet-B 的初始允許規則的三向交握。

下一步