Fortinet FortiGate 實戰課程 - 防火牆策略與物件

Concept 一、核心概念

1. 策略與物件 (Policy & Objects)

定義： 防火牆策略是控制流量通過的「規則清單」；而物件則是將重複使用的資訊（如 IP、服務埠號）打包成的「群組標籤」。

🏢 生活化比喻：大樓保全與訪客名單

想像 FortiGate 是一棟高級商業大樓的大廳保全 (Firewall)。

物件 (Objects)：就像是我們給人貼的標籤。不用記住每個人的身分證字號 (IP)，只要給他們一個代號叫「會計部人員」(Address Object)。
策略 (Policy)：就是保全手上的那一張「放行清單」。規則寫著：「如果是『會計部人員』要去『財務金庫』，則『允許進入』」。
順序 (Priority)：清單從第一行開始讀。如果第一行寫「今日閉館」，就算你是老闆也會被擋在門口，因為保全看到第一行就執行了 (Top-Down)。

Mechanism 二、運作原理

1. 物件化管理 (Object-Based)

FortiGate 強烈建議使用物件，而非直接在規則中輸入 IP。

Address Object：定義 IP、子網段 (Subnet)、FQDN (如 www.google.com) 或地理位置 (GeoIP)。
Service Object：定義通訊協定與埠號 (如 TCP/443, UDP/53)。
優勢：當伺服器 IP 變更時，只需修改 Object 內容，所有引用該 Object 的 50 條 Policy 會自動更新。

2. 策略匹配邏輯 (Matching Logic)

核心行為模式：Top-Down First Match

由上而下掃描： 封包進入後，依序比對 ID 1, ID 2, ID 3...
擇一匹配 (First Match)： 一旦符合某一條規則的「所有條件」(來源、目的、服務、時間)，立即執行動作 (Allow/Deny)，並停止往下搜尋。
隱式拒絕 (Implicit Deny)： 若完全沒配對到任何規則，則觸發最底層的 Default Deny，預設丟棄封包。

🔑 關鍵五要素 (5-Tuple Match)

要讓一條策略生效，封包必須同時符合：Source Interface/Address + Destination Interface/Address + Service + Schedule。若動作為 ACCEPT，則封包通過。

Configuration 三、實戰設定範例 (CLI & GUI)

本節示範如何建立常用的位址與服務物件，並提供 GUI 與 CLI 對照。

Step 1: 建立單一 IP 物件 (Single Host)

路徑：Policy & Objects > Addresses > Create New

Name: Web_Server_Local

Type: Subnet

IP/Netmask: 192.168.100.10/32 (/32 代表單一 IP)

Interface: any

config firewall address edit "Web_Server_Local" set subnet 192.168.100.10 255.255.255.255 next end

Step 2: 建立 FQDN 物件 (Domain)

適用於 IP 浮動的雲端服務。FQDN 支援萬用字元 (*)。

Google 物件

Name: FQDN_Google

Type: FQDN

FQDN: *.google.com

Facebook 物件

Name: FQDN_Facebook

Type: FQDN

FQDN: *.facebook.com

config firewall address edit "FQDN_Google" set type fqdn set fqdn "*.google.com" next edit "FQDN_Facebook" set type fqdn set fqdn "*.facebook.com" next end

Step 3: 建立物件群組 (Address Group)

路徑：Policy & Objects > Address Groups

Group Name: Grp_Social_Media

Members: FQDN_Google FQDN_Facebook

config firewall addrgrp edit "Grp_Social_Media" set member "FQDN_Google" "FQDN_Facebook" next end

Step 4: 建立自訂服務 (Custom Service)

若應用程式使用非標準 Port (例如 10443)，需建立 Custom Service。
路徑：Policy & Objects > Services > Create New

Name: TCP_10443_App

Category: Network Services

Protocol Type: TCP/UDP/SCTP

Destination Port: TCP 10443

Comment: Internal Web App

config firewall service custom edit "TCP_10443_App" set tcp-portrange 10443 set comment "Internal Web App" next end

Step 5: 套用至防火牆策略 (Firewall Policy)

將上述 Group 與 Custom Service 結合。路徑：Policy & Objects > Firewall Policy

Name: Allow_App_Access

Incoming Iface: LAN (Port2)

Outgoing Iface: WAN (Port1)

Source: all

Destination: Grp_Social_Media

Schedule: always

Service: HTTPS, HTTP, TCP_10443_App

Action: ACCEPT

* NAT 已啟用 (預設)

config firewall policy edit 1 set name "Allow_App_Access" set srcintf "port2" set dstintf "port1" set srcaddr "all" set dstaddr "Grp_Social_Media" set service "HTTPS" "HTTP" "TCP_10443_App" set schedule "always" set action accept set nat enable next end

Visuals 四、架構視覺化

使用 Mermaid 語法展示物件組成與封包決策流程。

1. 物件與策略的關係 (Object Composition)

展示 Address/Service 物件如何被 Policy 引用。

graph TD classDef obj fill:#f3f4f6,stroke:#4b5563,stroke-width:1px; classDef policy fill:#fee2e2,stroke:#b91c1c,stroke-width:2px; subgraph Address_Objects [位址物件庫] direction TB A1[HR_PC: 192.168.1.10]:::obj A2[IT_Admin: 10.0.0.5]:::obj A3[Server_Farm: 172.16.1.0/24]:::obj end subgraph Service_Objects [服務物件庫] direction TB S1[Web: TCP 80/443]:::obj S2[SSH: TCP 22]:::obj end subgraph Firewall_Policy [防火牆策略規則] direction TB P1[Policy 1: IT to Server
Action: Allow]:::policy P2[Policy 2: HR to Web
Action: Allow]:::policy end A2 --> P1 A3 --> P1 S2 --> P1 A1 --> P2 S1 --> P2

2. 封包匹配流程 (Matching Logic)

由上而下的決策過程。

sequenceDiagram participant Packet as 封包 (Packet) participant Policy1 as Policy 1 (Specific) participant Policy2 as Policy 2 (General) participant Implicit as Implicit Deny Packet->>Policy1: 檢查條件 (Src, Dst, Svc) alt 符合 Policy 1 ? Policy1-->>Packet: 符合! 執行動作 (Allow/Deny) Note right of Policy1: 停止搜尋 (Stop) else 不符合 Packet->>Policy2: 繼續檢查下一條 alt 符合 Policy 2 ? Policy2-->>Packet: 符合! 執行動作 else 不符合 Packet->>Implicit: 落入最後一條 Implicit-->>Packet: DROP (丟棄) end end

Use Case 五、實務應用場景

場景：企業分層上網權限管理

情境描述： 行銷部需開放 Facebook/YouTube 進行推廣，但一般員工僅能瀏覽普通網頁，並嚴格禁止高風險網站。

解決方案 (注意順序)：

Rule 1 (特權)

來源：行銷部 | 服務：HTTP/S | 動作：ALLOW (Web Filter: 放行 Social)

Rule 2 (一般)

來源：全體員工 | 服務：HTTP/S | 動作：ALLOW (Web Filter: 阻擋 Social)

Implicit Deny (Drop All Others)

👍 優點 (Pros)

精確控制： 滿足業務需求同時保障頻寬，避免非相關人員濫用。
安全性： 預設阻擋 (Default Deny) 原則確保未被允許的流量無法通過。

👎 常見錯誤 (Risk)

順序錯誤： 若將「一般規則」放在「特權規則」上面，行銷部會先匹配到一般規則，導致無法使用社群媒體 (因為一般規則擋掉了)。

Quiz 六、隨堂測驗

請點擊您認為正確的選項，系統將會顯示解析。