設定 Azure 防火牆規則
您可以使用傳統規則或防火牆原則，在 Azure 防火牆上設定 NAT 規則、網路規則和應用程式規則。 在手動設定規則以允許流量之前，Azure 防火牆預設會拒絕所有流量。 規則正在終止，因此規則處理會在相符項目上停止。
使用傳統規則時的規則處理方式
系統會根據規則類型的優先順序 (數字由低到高，100 到 65,000) 處理規則集合。 規則集合名稱只能有字母、數字、底線、句點或連字號。 其必須以字母或數字開頭，並以字母、數字或底線結束。 最大名稱長度為 80 個字元。
一開始最好先以 100 作為遞增單位，將規則集合的優先順序數字隔開 (100、200、300 等)，以便有空間可在需要時新增更多規則集合。
使用防火牆原則時的規則處理方式
使用防火牆原則時，規則會組織在規則集合和規則集合群組內。 規則集合群組包含零個或多個規則集合。 規則集合屬於 NAT、網路或應用程式類型。 您可以在單一規則群組內定義多個規則集合類型。 您可以在規則集合中定義零個或多個規則。 規則集合中的規則必須屬於相同類型 (NAT、網路或應用程式)。
系統會根據規則集合群組和規則集合的優先順序來處理規則。 優先順序是介於 100 (最高優先順序) 至 65,000 (最低優先順序) 之間的任何數字。 系統會先處理優先順序最高的規則集合群組。 在規則集合群組內，系統會先處理優先順序最高 (數字最小) 的規則集合。
如果防火牆原則繼承自父原則，不論子原則的優先順序為何，一律會優先採用父原則中的規則集合群組。
注意
應用程式規則一律會在網路規則之後處理，這些規則會在 DNAT 規則之後處理，而不論規則集合群組或規則集合優先順序和原則繼承為何。
所以，總結來説：
家長原則始終優先。
- 規則集合群組依優先順序順序處理。
- 規則集合依優先順序順序處理。
- 先處理 DNAT 規則，然後處理網路規則，再處理應用程式規則。
以下是範例原則：
假設 BaseRCG1 是規則集合群組優先順序 (200)，其中包含規則集合：DNATRC1、DNATRC3、NetworkRC1。
BaseRCG2 是規則集合群組優先順序 (300)，其中包含規則集合：AppRC2、NetworkRC2。
ChildRCG1 是規則集合群組優先順序 (300)，其中包含規則集合：ChNetRC1、ChAppRC1。
ChildRCG2 是規則集合群組優先順序 （650），其中包含規則集合：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 | - |
DNAT 規則的初始反覆專案：
處理程序首先會檢查編號最小的規則集合群組 (RCG)，即優先順序為 200 的 BaseRCG1。 在此群組中，它會搜尋 DNAT 規則集合並根據其優先順序對其進行評估。 在此情況下，會找到 DNATRC1 (優先順序 600) 和 DNATRC3 (優先順序 610) 並據以處理。
接下來，它會移至下一個 RCG BaseRCG2（優先順序 300），但找不到 DNAT 規則集合。
接下來，它會繼續到 ChildRCG1 (優先順序 300)，同樣沒有 DNAT 規則集合。
最後，它會檢查 ChildRCG2 (優先順序 650)，並找到 ChDNATRC3 規則集合 (優先順序 3000)。
網路規則的反覆專案：
回到 BaseRCG1，重複動作會繼續進行，這次是針對 NETWORK 規則。 只找到 NetworkRC1 (優先順序 800)。
然後，它會移至 BaseRCG2，NetworkRC2 (優先順序 1300) 位於其中。
繼續移至 ChildRCG1，它探索到 ChNetRC1 (優先順序 700) 作為 NETWORK 規則。
最後，在 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 規則進行排序。 然後對 NETWORK 規則進行相同的處理程序，最後再對 APPLICATION 規則進行相同的處理程序。
如需防火牆原則規則集的詳細資訊，請參閱 Azure 防火牆原則規則集。
威脅情報
您如有啟用參考威脅情報的篩選，則這些規則的優先順序最高，一律優先處理 (其順序在網路及應用程式規則之前)。 威脅情報篩選可能會在處理任何已設定的規則之前拒絕流量。 如需詳細資訊，請參閱 Azure 防火牆威脅情報型篩選。
IDPS
當 IDPS 設定為 [警示] 模式時，IDPS 引擎會與規則處理邏輯平行運作，並針對輸入和輸出流程的相符簽章產生警示。 若與 IDPS 簽章相符，則會在防火牆記錄中記錄警示。 不過，由於 IDPS 引擎與規則處理引擎平行運作，因此遭應用程式/網路規則拒絕或允許的流量仍可能會產生另一個記錄輸入。
當 IDPS 設定為 [警示和拒絕] 模式時，IDPS 引擎會在規則處理引擎之後內嵌並啟動。 因此，這兩個引擎都會產生警示，而且可能會封鎖相符的流程。
由 IDPS 執行的工作階段中斷會悄無聲息地封鎖流量。 因此，不會在 TCP 層級上傳送任何 RST。 由於 IDPS 一律會在符合網路/應用程式規則 (允許/拒絕) 且將其標示在記錄之後再行檢查流量，因此可能會記錄另一個 [卸除] 訊息，IDPS 則因簽章相符而決定拒絕的工作階段。
啟用 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 以及 destination ports = '*' 的規則。 如果您不想允許目前定義的任何 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 |
結果
因為封包符合 Allow-web 網路規則，所以允許連線至 google.com。 正在處理的規則會於此時停止。
範例 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 的明確拒絕規則。