PaloAlto_21 Security Policy 不是 allow any

 

開場白：allow any 是工程師的泡麵

凌晨兩點、專案卡關、客戶在催、系統就是不通。
這時候，最容易出現的一行設定就是：

Source：any
Destination：any
Service：any
Action：allow

它就像泡麵——
不健康、沒營養、但「立刻可以活下來」。

但在 Palo Alto Networks 的世界裡，
Security Policy 的存在，就是為了阻止你每天吃泡麵。

第一課：Security Policy 到底在管什麼？

先講人話版本：
Security Policy = 誰，可以，在什麼情況下，用什麼方式，跟誰說話。

工程師翻譯版是五個 W：

1. Who（Source）：誰發起連線

2. To Whom（Destination）：要連到哪

3. How（Application / Service）：用什麼方式

4. When（Schedule）：什麼時間

5. So What（Action）：放行 or 擋掉

allow any 等於直接跟防火牆說：

「你不要思考，我來承擔後果。」
（歷史證明，後果通常你也承擔不起）

第二課：為什麼 Palo Alto 討厭 allow any？

因為 Palo Alto 的核心哲學只有一句話：

「我不只看 port，我看你在幹嘛。」

傳統防火牆：

• TCP/443？好，大概是 HTTPS，放。

Palo Alto：

• TCP/443？

• 是 HTTPS？

• 還是 Dropbox？

• 還是某個你不想讓老闆知道的東西？

你如果用 allow any，等於買了跑車卻永遠踩一檔。

第三課：正確的 Policy 心法

1️⃣ 先想「業務需求」，不是先想「怎麼通」

錯誤流程：

ping 不通 → allow any → 世界和平（10 分鐘）

正確流程：

這台 Server 要做什麼？
它應該跟誰說話？

Security Policy 是白名單思維，不是黑名單懺悔錄。

2️⃣ App-ID 是你的好朋友，不是麻煩鬼

很多人抱怨：

「App-ID 很煩，規則寫不動。」

但實話是：
App-ID 是幫你把『不知道自己在幹嘛』變成『我很清楚』。

實務建議：

• 能用 Application，就不要只用 Service

• HTTPS ≠ 一切合法行為

3️⃣ Rule Order：防火牆是從上往下讀的

這不是小說，沒有伏筆。

• 第一條 match，就停

• allow any 放最上面 = 所有規則都是裝飾品

工程師金句：

「規則不是沒生效，是你永遠跑不到它。」

第四課：一個「不丟臉」的 Security Policy 教學範例

假設情境：

Web Server 需要對外提供 HTTPS

錯誤寫法（資安會皺眉）：

• Source：any

• Destination：Web Server

• Service：any

• Action：allow

比較像樣的寫法：

• Source：Internet Zone

• Destination：Web Server Zone

• Application：ssl, web-browsing

• Service：application-default

• Action：allow

這時候 Palo Alto 會說：

「好，我知道你在做網站，不是在亂來。」

第五課：Log 不看，比 allow any 更可怕

很多人寫完規則就收工，
Log 的存在彷彿只是為了佔硬碟。

但事實是：

• Log = 你未來自保的證據

• Log = 你跟資安、稽核、老闆溝通的翻譯機

至少做到三件事：

1. 允許的流量要記錄

2. 被擋的流量要敢看

3. 出事時不要第一句就說「防火牆沒動」

結語：allow any 不是原罪，但是警訊

老實說，每個工程師人生中都用過 allow any。
真正的差別在於：

• 新手：用了就忘

• 老手：用了會內疚，然後刪掉

Security Policy 的成熟度，
不是你會不會寫 allow any，
而是你能不能不用它，系統還是活得好好的。

如果你現在打開 Palo Alto，
看到某條 allow any 在角落對你微笑——
別怕，
它不是在嘲笑你，
它是在等你長大。

PaloAlto_20 的 Routing & NAT

 

一場封包的迷航記，以及工程師的自我修行

如果你第一次打開 Palo Alto Networks Firewall，大概會有一種感覺：
「介面好漂亮。」
三分鐘後：
「Routing 跑去哪？」
十分鐘後：
「為什麼 NAT 看起來像在玩邏輯題？」

放心，你不是一個人。
在 PaloAlto_20（泛指 PA 防火牆 10.x 世代設定邏輯）裡，Routing 與 NAT 從來不是單純的「網路設定」，而是一場工程師心智成熟度測驗。

一、Routing：不是幫你指路，是決定你的人生方向

在工程師的世界裡，Routing 就像人生規劃。
你以為只要設定一條 Default Route（0.0.0.0/0），封包就會自動走向幸福的彼岸。
但 Palo Alto 冷冷地告訴你一句話：

「不好意思，我要先看 Virtual Router。」

是的，Palo Alto 沒有「全域 Routing Table」，
每個 Interface 都要掛在正確的 Virtual Router 底下，
否則你的封包會陷入量子狀態——
介於「送出」與「消失」之間。

工程師常見錯誤清單：

• Interface 掛錯 Virtual Router

• 靜態路由寫得很美，但根本沒人用

• OSPF 開得很開心，對面根本沒鄰居

這時候你會學到 Palo Alto 的第一堂人生課：
👉 Routing 沒錯，只是你想得太天真。

二、NAT：封包的變裝秀，比你想得更複雜

如果 Routing 是人生方向，那 NAT 就是身分證改名大賽。

在 Palo Alto 裡，NAT 不是「順手設定一下」，
而是明確告訴你：
「我什麼時候要改你、在哪裡改你、改成什麼樣子。」

Palo Alto 的 NAT 三大靈魂問題：

1. Original Packet 長怎樣？

2. Translated Packet 要變成誰？

3. 這一切發生在 Security Policy 之前，還是之後？

很多新手工程師會天真地問：
「為什麼我 NAT 設好了，還是連不上？」

答案通常只有一句：
👉 因為你的 Security Policy 根本不是用 NAT 後的 IP 在比對。

這一刻，你會突然理解為什麼資深工程師都不愛說話。
不是冷漠，是已經痛過。

三、Routing × NAT：當兩個世界開始互相傷害

真正的修羅場，是 Routing 跟 NAT 同時出問題。

經典場景如下：

• 封包進來 → Routing 看得懂

• NAT 改得很開心

• 封包出去 → Routing 說「這不是我認識的你」

然後 Session 就這樣死在 Log 裡，
留下你一個人盯著 Monitor → Traffic，看著封包的最後一跳。

這時候你會開始做工程師的三大儀式：

1. 開 Packet Capture

2. 打開 CLI 看 test routing fib-lookup

3. 默默懷疑人生選擇

四、工程師的覺醒：你終於開始「看流程」

某一天，你突然不再亂改設定了。

你會開始照流程思考：

1. 封包從哪個 Interface 進來？

2. 屬於哪個 Zone？

3. Routing 決定往哪走？

4. NAT 什麼時候介入？

5. Security Policy 用的是哪個 IP？

6. 回程路由是不是對稱？

那一刻，你不會特別開心，
但你會很平靜地說一句話：

「嗯，這個我大概知道問題在哪。」

恭喜你，你已經從「亂試工程師」
進化成「有邏輯的工程師」。

五、結語：Palo Alto 沒有很難，只是很誠實

PaloAlto_20 的 Routing & NAT，
其實沒有陷阱、沒有魔法、也沒有黑箱。

它只是把網路的本質攤開來，
逼你面對現實。

如果你哪天設定完，
封包一次就通，Log 乾乾淨淨，
那不是因為運氣好——

而是因為你已經學會用工程師的方式思考。

最後送你一句 Palo Alto 生存守則：

「Routing 決定你去哪，NAT 決定你是誰。」

而工程師，決定要不要再加班。

PaloAlto_19 SSL 解密：別當那個「隔著麻袋摸大象」的資安工程師

前言：加密流量，是駭客最溫柔的掩護

如果你已經搞定了 Zone 的邏輯，也學會了用 App-ID 去抓應用程式，你可能會覺得自己現在就像機房裡的葉問，一個能打十個。

但我要潑你一盆冷水。

在 2026 年的今天，超過 90% 的網路流量都是加密的（HTTPS/TLS）。如果你沒有開啟 SSL Decryption (SSL 解密)，你的 PA-1410 就算效能再強，在它眼裡，這些流量通通都長這樣：

[一團亂碼] -> [目的地] -> [又一團亂碼]

這就像是你身為機場安檢員，看到旅客提著一個「死鎖的保險箱」走進來。你問他裡面裝什麼，他說裝的是「個人隱私（HTTPS）」。你就揮揮手讓他過去了？這不叫資安，這叫佛系管理。

今天的 PaloAlto_19，我們要聊聊如何優雅地拆開這些保險箱，又不被旅客（使用者）投訴到爆。

一、 為什麼非「拆」不可？（SSL 解密的必要性）

很多老闆（甚至有些資深工程師）會問：「解密很耗效能耶，真的有必要嗎？」

我通常會回他一個情境： 如果有一個員工，從家裡的雲端硬碟下載了一個包著 Cobalt Strike（木馬） 的檔案，並且這個檔案是透過 HTTPS 傳輸的。

• 沒開解密： PA 只看到 App: web-browsing，流量通過。恭喜你，內網中毒了。

• 開了解密： PA 會在防火牆中間把流量拆開，用 Content-ID 掃描裡面的位元組。發現病毒，直接攔截。

一句話總結：不開解密，你的進階威脅防禦（IPS、WildFire）就跟裝飾品沒兩樣。

二、 實戰操作：PA-1410 的「中間人」演技

SSL 解密的原理其實就是合法的「中間人攻擊 (Man-in-the-Middle)」。

1. 使用者想連到 Google。

2. PA-1410 攔截請求，自己偽裝成 Google 發一個憑證給使用者。

3. PA-1410 另外去跟真正的 Google 連線。

這中間最容易翻車的地方就是：憑證 (Certificate)。

如果你的使用者電腦不信任 PA 發出來的那張「代理憑證」，他們打開瀏覽器就會看到滿螢幕的「您的連線不是私密連線」。接著，你的分機就會被打爆，主管會站在你背後，問你為什麼公司網路壞了。

良的避坑指南：

• 一定要透過 AD GPO 派送憑證： 讓全公司的電腦預設信任 PA 的 Sub-CA 憑證。

• 手機與 IoT 設備是地雷： 這些東西很難塞憑證進去，建議先排除在解密清單外，不然你的報修單會接到手軟。

三、 哪些東西打死都不能解？（Decryption Exclusion）

做 SSL 解密不能像推土機一樣全推平，有些東西解密了會出大事（甚至有法律責任）：

1. 金融銀行類 (Financial Services)： 你解密員工的網銀帳密？這在某些法規下是違法的。

2. 醫療與隱私 (Health and Medicine)： 同上，別給自己找麻煩。

3. 政府網站： 有些政府憑證有特殊檢查機制，解密後會直接斷線。

4. 不支援解密的 App： 例如 Dropbox 或某些特定的手機 App，它們會檢查憑證的「指紋」（Certificate Pinning），一旦發現中間有人動手腳，就直接擺工。

工程師的專業溫柔： 在 PA 的 Decryption Policy 裡，記得最上面要疊一層 No-Decrypt 的規則，把這些敏感類別通通排除。

四、 效能與「爆機」的恐懼

「解密會讓防火牆變慢」這不是傳聞，這是物理規律。解密需要大量的數學運算。 好在我們用的是 PA-1410，它有專門的硬體加速晶片處理這塊。但即便如此，你還是要監控你的 DP CPU (Dataplane CPU)。

如果有一天你發現解密開下去，CPU 飆到 90%，請不要驚慌，這時候你有兩個選擇：

1. 縮小範圍： 只解密「最危險」的類別（例如：Web-browsing, Unknown-tcp）。

2. 升級硬體： 拿著數據去找老闆，說我們需要更高階的型號了。（這也是幫自己爭取預算的好機會）。

五、 結語：資安就是一場「透明度」的戰爭

SSL 解密很痛苦，部署過程會有很多雜音，甚至會讓你懷疑人生。但一旦你熬過去，你會發現你的 Traffic Log 變得很清澈。

你會看到：

• 本來是 SSL 的流量，現在顯示為 Google-base。

• 原本藏在加密流量裡的惡意檔案，被 WildFire 準確擊落。

• 員工在上班時間偷偷用加密代理跳牆，被你一秒抓到。

資安工程師的價值，就在於你能看到別人看不見的東西。