您可以使用傳統規則或防火牆原則，在 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)。
NETWORK 規則的反覆運算：
回到 BaseRCG1，重複動作會繼續進行，這次是針對 NETWORK 規則。 只找到 NetworkRC1 (優先順序 800)。
然後，它會移至 BaseRCG2，NetworkRC2 (優先順序 1300) 位於其中。
繼續移至 ChildRCG1，它探索到 ChNetRC1 (優先順序 700) 作為 NETWORK 規則。
最後，在 ChildRCG2 中，它找到 ChNetRC2 (優先順序 1100) 作為 NETWORK 規則集合。
APPLICATION 規則的最終反覆運算：
回到 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 位址，並改用從 Host 標頭解析出的 DNS IP 位址。 防火牆預期會在 Host 標頭中取得連接埠號碼；若未提供，則會假設使用標準的 80 連接埠。 如果實際 TCP 連接埠與主機標頭中的連接埠不符，則流量會中斷。 DNS 解析會由 Azure DNS 或由自訂 DNS (若已在防火牆上設定) 來進行。
附註
在 HTTP 與啟用 TLS 檢查的 HTTPS 通訊協定中，Azure 防火牆一律會填入 XFF (X-Forwarded-For) 標頭，其值為原始來源 IP 位址。
當應用程式規則包含 TLS 檢查時，防火牆規則引擎會處理 SNI、主機標頭及 URL 以符合規則。
若在應用程式規則中仍未找到相符項目，封包接著會被拿去與基礎結構規則集合進行比對。 如果仍然沒有相符項目，則封包預設會遭到拒絕。
基礎設施規則收集
Azure 防火牆包含內建的規則集合，適用於依預設允許的基礎結構 FQDN。 這些 FQDN 是平台特定的，且無法用於其他用途。 基礎結構規則集合會在應用程式規則之後、最終全面拒絕規則之前進行處理。
內建基礎設施規則集合包含以下服務：
- 對儲存平台影像儲存庫（PIR）的運算存取
- 受控磁碟狀態儲存體存取
- Azure 診斷與記錄（MDS）
基礎設施規則集合的覆寫
你可以透過建立一個最後處理的拒絕所有應用程式規則集合來覆蓋這個內建的基礎設施規則集合。 它總是在基礎設施規則收集之前被處理。 任何不在基礎架構規則集合中的項目預設會被拒絕。
附註
您可以針對 TCP、UDP、ICMP 或任何 IP 通訊協定設定網路規則。 任何 IP 通訊協定都包含網際網路號碼分配局 (IANA) 通訊協定號碼文件中定義的所有 IP 通訊協定。 如果明確設定目的地連接埠，規則就會轉譯為 TCP+UDP 規則。 2020 年 11 月 9 日之前，任何即代表 TCP、UDP 或 ICMP。 因此，您可能已在該日期之前設定 Protocol = Any 以及 destination ports = '*' 的規則。 如果您不想允許目前定義的任何 IP 通訊協定，請修改規則以明確設定您想要的通訊協定 (TCP、UDP 或 ICMP)。
輸入連線
DNAT 規則和網路規則
在 Azure 入口網站中，您可以藉由如使用 Azure 防火牆 DNAT 篩選輸入因特網或內部網路流量中所述，設定目標網路位址轉換 (DNAT) 以啟用對因特網或內部網路的輸入連接。 NAT 規則會依其優先順序，優先於網路規則套用。 如果找到相符項，流量會根據 DNAT 規則進行轉譯並獲得防火牆允許。 因此，流量不受其他網路規則的任何進一步處理。 基於安全性理由，建議的方法是新增特定的網際網路來源，以允許 DNAT 存取網路，並避免使用萬用字元。
應用程式規則不適用於輸入連線。 因此，若要篩選輸入 HTTP 或 HTTPS 流量，建議使用 Web 應用程式防火牆 (WAF)。 如需詳細資訊，請參閱什麼是 Azure Web 應用程式防火牆？
範例
下列範例顯示某些規則組合的結果。
範例 1
因為有相符的網路規則，所以允許連線至 google.com。
網路規則
- 動作：Allow
| 名稱 | 通訊協定 | 來源類型 | 來源 | 目的地類型 | 目的地位址 | 目的地連接埠 |
|---|---|---|---|---|---|---|
| Allow-web | TCP | IP 位址 | * | IP 位址 | * | 80,443 |
應用程式規則
- 動作：Deny
| 名稱 | 來源類型 | 來源 | 通訊協定:連接埠 | 目標 FQDN |
|---|---|---|---|---|
| Deny-google | IP 位址 | * | http：80，https：443 | google.com |
結果
因為封包符合 Allow-web 網路規則，所以允許連線至 google.com。 正在處理的規則會於此時停止。
範例 2
SSH 流量遭到拒絕，因為優先順序較高的拒絕網路規則集合會封鎖該流量。
網路規則集合 1
- 名稱：Allow-collection
- 優先順序：200
- 動作：Allow
| 名稱 | 通訊協定 | 來源類型 | 來源 | 目的地類型 | 目的地位址 | 目的地連接埠 |
|---|---|---|---|---|---|---|
| Allow-SSH | TCP | IP 位址 | * | IP 位址 | * | 22 |
網路規則集合 2
- 名稱：Deny-collection
- 優先順序：100
- 動作：Deny
| 名稱 | 通訊協定 | 來源類型 | 來源 | 目的地類型 | 目的地位址 | 目的地連接埠 |
|---|---|---|---|---|---|---|
| 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 的明確拒絕規則。