Access-list (ACL) 封包過濾機制

由 20 年經驗網路架構大師為您解析 | 結合 ExtremeXOS 實務與理論

導言

歡迎來到網路資安的第一道防線課程。我是您的講師 Timmy。在網路世界中，我們不能讓所有流量隨意進出，這就像你家大門不能隨便讓陌生人進入一樣。今天我們將深入探討 Access Control List (ACL)，並比較 Cisco 與 ExtremeXOS 在實作上的異同。

Part 1

一、核心概念 (Concept)

一句話定義

ACL 是一張「允許」或「拒絕」的清單，用來告訴網路設備（路由器或交換器）哪些封包可以通過，哪些必須被丟棄。

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

想像 Switch 是一個高級辦公大樓的「保全警衛」，而 ACL 就是警衛手上的「訪客名單」。

  • 當有人 (封包) 想進入大樓 (Port) 時。
  • 警衛會從名單的第一行開始核對。
  • 規則 1：如果是 VIP (允許的 IP)，直接放行。
  • 規則 2：如果是黑名單 (禁止的 IP)，直接擋下。
  • 重要差異：Cisco 的警衛預設是「名單上沒寫的都不准進 (Implicit Deny)」，但 ExtremeXOS 的警衛比較友善，預設是「名單上沒寫的都放行 (Implicit Permit)」，所以我們通常會在名單最後手動加上「禁止其他人進入」。
Part 2

二、運作原理 (Mechanism)

技術細節：Top-Down Processing

ACL 的檢查機制是「由上而下，逐條比對，擇一執行」(Top-down, First Match)。

  • 命中即停止 (First Match)：一旦封包特徵符合某條規則，設備就會執行該規則的動作 (Permit 或 Deny)，並停止往下檢查。
  • 方向性 (Direction)：ACL 必須套用在介面 (Interface/VLAN) 的「進入 (Ingress)」或「出去 (Egress)」方向才有效。

⚠️ 關鍵差異：預設行為 (Default Action)

這是 ExtremeXOS 使用者最容易踩到的坑！

  • Cisco IOS：預設為 Implicit Deny (隱式拒絕)。若沒匹配到任何規則，封包會被丟棄。
  • ExtremeXOS：預設為 Implicit Permit (隱式允許)。Policy 檔案若沒匹配到任何 entry，封包會被允許通過。
  • 最佳實踐：在 ExtremeXOS 寫 Policy 時，若要實施嚴格過濾，務必在檔案最後加上一個 deny-all 的 entry。

大師觀點：ExtremeXOS vs. Cisco

Cisco IOS (傳統)

access-list 100 permit tcp host 10.1.1.1 any eq 80
! (Hidden: deny ip any any)
int gi0/1
ip access-group 100 in

特色：預設拒絕所有未提及流量。

ExtremeXOS (Policy Based)

entry Allow_Web {
  if match { protocol tcp; dst-port 80; }
  then { permit; }
}
entry Deny_All { // 必須手動加！
  if { always; } then { deny; }
}

特色：預設允許，需手動加上 Deny All。

Part 3

三、架構視覺化 (Visuals)

圖一：ACL 部署位置拓撲圖

graph TD %% Nodes with quoted labels for safety Internet((網際網路 Internet)) FW[防火牆 Firewall] CoreSW["核心交換器 Core Switch
(L3 Routing)"] %% Subgraphs with Quoted Labels subgraph AccessLayer ["Access Layer"] AccSW1["存取交換器 SW1"] AccSW2["存取交換器 SW2"] end subgraph VLAN10 ["VLAN 10 (財務部)"] PC_Fin["財務部 PC
192.168.10.x"] end subgraph VLAN20 ["VLAN 20 (工程部)"] PC_Eng["工程部 PC
192.168.20.x"] end subgraph Servers ["Server Farm"] Svr_Fin["財務主機
10.10.10.100"] Svr_Web["Web 主機
10.10.10.200"] end %% Connections Internet --- FW FW --- CoreSW CoreSW --- AccSW1 CoreSW --- AccSW2 AccSW1 --- PC_Fin AccSW2 --- PC_Eng CoreSW --- Svr_Fin CoreSW --- Svr_Web %% Styles style CoreSW fill:#f9f,stroke:#333,stroke-width:2px style Svr_Fin fill:#ff9,stroke:#333 style Svr_Web fill:#bbf,stroke:#333 %% Link Styles %% Link index 6 is CoreSW --- Svr_Fin linkStyle 6 stroke:red,stroke-width:4px %% Note ACLNote["在 Core Switch 實施 ACL"] ACLNote -.-> CoreSW

說明：通常建議將 Extended ACL 盡量靠近「來源端」部署，以減少不必要的網路頻寬消耗。

圖二：ExtremeXOS 封包過濾邏輯流程圖

sequenceDiagram participant Packet as 封包 (Packet) participant ACL as ACL 檢查機制 (Policy) participant Action as 執行動作 Packet->>ACL: 到達介面 (Ingress) loop 規則比對 (Top-Down) ACL->>ACL: 檢查 Entry 1 alt 符合 Entry 1? ACL->>Action: 是 -> 執行 Entry 1 動作 Note right of Action: 停止檢查 else 不符合 ACL->>ACL: 檢查 Entry 2 alt 符合 Entry 2? ACL->>Action: 是 -> 執行 Entry 2 動作 else 不符合 ACL->>ACL: 繼續檢查下一條... end end end opt 所有規則皆不符合 Note over ACL, Action: ExtremeXOS 預設行為 ACL->>Action: 預設允許 (Implicit Permit) !!! Note right of Action: 封包通過 (除非手動加 Deny) end
Part 4

四、實務應用場景 (Use Case)

案例一：財務部資料隔離 (IP Based)

情境：為了資訊安全，禁止「工程部 (VLAN 20)」存取「財務部伺服器 (10.10.10.100)」，但允許其他流量。

// 檔案: block_eng_to_fin.pol

entry Block_Finance_Access {
  if match {
    source-address 192.168.20.0/24;
    destination-address 10.10.10.100/32;
  } then {
    deny;
  }
}
// 這裡如果不加 Permit_Others，其實預設也是 Permit
// 但為了可讀性與明確性，習慣上還是會寫出來，或者在需要白名單時加 Deny_All

案例二：Web 伺服器服務管控 (Destination Port Filtering)

情境：公司有一台對外的 Web 主機 (10.10.10.200)。 我們希望開放全世界存取其 Web 服務 (Port 80, 443)，但嚴格禁止外部對其進行遠端管理 (SSH Port 22)。

// 檔案: secure_web_server.pol

// 1. 允許 IT 管理員 SSH
entry Allow_IT_SSH {
  if match {
    source-address 192.168.99.0/24;
    destination-address 10.10.10.200/32;
    protocol tcp; destination-port 22;
  } then { permit; }
}

// 2. 阻擋其他所有人的 SSH
entry Block_Public_SSH {
  if match {
    destination-address 10.10.10.200/32;
    protocol tcp; destination-port 22;
  } then { deny; }
}

// 3. 注意：如果不加最後的 Deny All，其他 Port (如 80/443) 預設是會通的 (Implicit Permit)
// 如果我們要實施「白名單」(只准 80/443/22)，則必須這樣寫：

entry Allow_Web { ... permit; }

entry Deny_Rest {
  if { always; } then { deny; }
}

優點 (Pros)

  • 彈性高：Default Permit 對於「只擋壞人」的黑名單策略很方便，不用寫 Permit Any。
  • 硬體加速：Extreme 交換器使用 ASIC 硬體過濾，效能極佳。

注意事項 (Notes)

  • 安全性風險：若忘記加 Deny All，可能意外開放權限。
  • Protocol 欄位：過濾 Port 時，務必先指定 L4 協定。
Part 5

五、ACL 與 Firewall Policy 差異解析 (Comparison)

許多學員常問：「既然 Switch 上的 ACL 也能擋封包，為什麼我們還需要昂貴的 Firewall？」這就要從「無狀態 (Stateless)」與「狀態感知 (Stateful)」的核心差異說起。

🛡️ 生活化比喻

ACL (Switch 上的過濾)

就像「地鐵站的驗票閘門」。

  • 只看票 (Header)：只要票沒問題就開門。
  • 沒記憶 (Stateless)：它不記得你剛剛是不是才剛進站，也不管你是不是壞人，只認票。
  • 速度極快：每秒可以處理大量人流。

Firewall Policy (防火牆策略)

就像「機場的海關移民官」。

  • 查戶口 (Stateful)：它會看你的護照，還會查電腦紀錄，知道你「什麼時候出境的」。
  • 應用層檢查 (Deep Inspection)：它會打開你的行李箱 (Payload)，檢查有沒有違禁品 (病毒、惡意程式)。
  • 速度較慢：檢查程序繁瑣，處理量能有限。

技術規格對照表

特性 ACL (Switch) Firewall Policy
核心機制 Packet Filtering
(逐包過濾)		 Stateful Inspection
(狀態檢測)
連線狀態 無狀態 (Stateless)
不知封包屬於哪個連線		 有狀態 (Stateful)
追蹤 Session Table
運作層級 Layer 2 ~ Layer 4
(MAC, IP, Port)		 Layer 3 ~ Layer 7
(App-ID, User-ID)
處理效能 極高 (ASIC 硬體線速) 中/高 (CPU/NPU 運算)
主要用途 內網網段隔離、
基本 QoS、阻擋廣播風暴		 邊界防護、VPN、
IPS (入侵防禦)、防毒

圖三：無狀態 (Stateless) vs 有狀態 (Stateful) 運作差異

graph TD subgraph ACL_Stateless ["ACL (無狀態) - 笨拙但快速"] P1["封包 1: 來源A -> 目的B (Port 80)"] --> Check1{"檢查規則"} Check1 -- "符合 Permit" --> Pass1["放行"] P2["封包 2: 目的B -> 來源A (回傳封包)"] --> Check2{"檢查規則"} Check2 -- "需額外設定規則
否則會被擋下!" --> Drop1["丟棄?"] style Drop1 fill:#f9f,stroke:#333 end subgraph FW_Stateful ["Firewall (有狀態) - 聰明且自動"] FP1["封包 1: 來源A -> 目的B (SYN)"] --> FWCheck{"檢查策略"} FWCheck -- "允許" --> Session["建立連線表 (Session Table)
A <--> B"] FP2["封包 2: 目的B -> 來源A (SYN-ACK)"] --> LookSession{"查表"} LookSession -- "表中有紀錄
自動放行!" --> Pass2["放行"] style Session fill:#d1fae5,stroke:#059669 end %% Invisible link to force vertical layout Drop1 ~~~ FP1

重點：ACL 必須明確設定「雙向」規則才能通訊；Firewall 只要允許「去程」，「回程」會自動依據狀態表放行。

Part 6

六、隨堂測驗 (Quiz)