網站突然連不上，你會先說「防火牆擋住了」，還是先問：線路斷了、連線排不進去，還是網站程式忙不過來？
我比較在意後面這個問題。背出 OSI 七層，可以幫你通過第一個提問；說清楚攻擊利用什麼、防護擋住什麼，才真的能把模型用在排查與溝通上。
這篇是「資安面試 E01｜OSI 七層 × 資安攻防」的延伸閱讀，適合正在補網路基礎、準備資安面試，或剛開始接觸藍隊工作的人。以下情境彼此獨立、均為假設，不涉及真實公司環境，也不提供攻擊操作步驟。
先把七層當成問題地圖，不是七個安全產品
OSI 是整理通訊功能的模型，不是每種協定或攻擊只能入住一層的分類箱。尤其是上面三層，現代網際網路的實作常把多種功能整合在應用中：拿 Web Session 解釋狀態管理、拿 TLS 解釋加密，是教學上的對照，不代表它們只能歸在 L5 或 L6。
| 層級 | 先理解的功能 | 本文的風險與防護切入點 |
|---|---|---|
| L7 應用層 | 使用者實際使用的服務 | SQL Injection、XSS、應用資源耗盡 |
| L6 表達層 | 資料表示與轉換 | 以 TLS 說明傳輸加密及其邊界 |
| L5 會話層 | 對話建立、維持與結束 | 以登入狀態說明憑證與有效期限 |
| L4 傳輸層 | 端到端傳輸與連線 | TCP 半開連線狀態與 SYN Flood |
| L3 網路層 | IP 位址與跨網路路由 | 來源位址偽造、流量與上游防護 |
| L2 資料鏈結層 | 區域鏈路上的訊框轉送 | ARP 欺騙、MAC 表與交換器設定 |
| L1 實體層 | 訊號、線路與設備連接 | 實體接觸、破壞與可用性 |
每段都可以問三件事：正常怎麼運作？攻擊破壞哪個假設或耗掉哪個資源？防護需要什麼條件？
L1：線路斷了，加密也救不了可用性
假設有人拔掉機櫃裡的網路線，網站可能直接離線；如果陌生設備能接入未受管控的插孔，又是另一種風險。兩者都提醒我們：安全不能只從軟體設定開始想。
門禁、機櫃上鎖、線路管理與設備盤點，是限制實體接觸的基本功；備援則要考慮是否真的走不同路徑。兩條線如果共用同一個容易被切斷的路段，不等於排除了單點故障。這裡要分清楚：加密處理資料保密，備援與實體保護處理的還包括服務能不能繼續用。
L2：交換器會轉送，不代表會判斷誰在說謊
ARP 欺騙：把閘道的 IP 對應到錯誤的 MAC
在常見的 IPv4 乙太網路中，電腦要把資料交給閘道，得先知道對方的 MAC 位址。ARP 欺騙就是讓電腦接受錯誤的 IP–MAC 對應，把原本要交給真閘道的訊框送給攻擊者；是否形成中間人轉送，還取決於攻擊者位置、轉送行為及環境條件。Cisco：DAI 與 ARP 防護
圖 1｜正常是「同事電腦 → 交換器 → 真閘道 → Internet」；被欺騙且攻擊者繼續轉送時，是「同事電腦 → 交換器 → 假閘道 → 真閘道 → Internet」。這是邏輯順序，不是實體佈線圖；重返同一交換器的跳點與回程已省略。封包繞路，也不代表 HTTPS 內容已被解密。
因此，「交換器預設就會擋 ARP Spoofing，只有集線器不行」是不正確的判斷。以 Cisco Catalyst 9300 的 IOS XE 17.9 文件為例，DAI（Dynamic ARP Inspection，檢查 ARP 宣告是否可信）預設在所有 VLAN 關閉；設備支援不等於已啟用。Cisco：DAI 預設設定
要使用這道防線，必須確認 VLAN、埠的信任設定與驗證依據。常見依據是 DHCP Snooping 學到的 IP–MAC 綁定；固定 IP 設備則要另規劃適當的綁定或 ARP ACL，不能為了讓它通過，就把一般使用者埠全部設為可信任。Cisco：DAI 驗證依據
MAC Flooding：別把「未知目的地泛洪」講成全部變廣播
MAC Flooding 針對的是交換器學習 MAC 位址的容量。目的 MAC 不在轉送表時，交換器通常會將該未知單播訊框泛洪到同一 VLAN 的其他合適轉送埠，不包含進入埠；不等於所有既有流量突然跨 VLAN 廣播。實際行為仍受設備與設定影響。防護可從合理的埠 MAC 數量限制、接入控管與異常告警檢查起。Cisco：Unicast Flooding
L3、L4：同樣連不上，先分清楚耗盡哪種資源
IP Spoofing 是偽造來源位址；DDoS 是分散來源造成阻斷服務，兩者不是同義詞。來源位址過濾可以減少不合理的偽造封包，但不能因此宣稱能擋住所有 DDoS。RFC 2827：來源位址過濾
圖 2｜左邊是網路容量被吃掉，中間是半開連線狀態累積，右邊是高成本應用工作。三者不是互斥分類；圖中沒有代表真實環境的測量值。
在 L3 的流量問題裡，假設大量 ICMP 流量已塞滿對外線路，只在內部防火牆丟棄封包，未必能把上游那段頻寬還給正常使用者。這時要評估 ISP 或上游防護，並確認實際涵蓋的 IP、協定、容量與觸發流程。不是每種保護方案都覆蓋所有服務。Cloudflare：DDoS protection overview
黑洞路由也不是「清洗後正常上網」的同義詞。它可能連正常流量一起丟棄，犧牲目標服務來減少對其他基礎設施的影響，屬於有代價的處置。Cloudflare：DDoS blackhole routing
到了 L4，TCP 的三向交握是 SYN、SYN-ACK、ACK。SYN Flood 的典型機制，是讓接收端保留大量等待完成的半開連線狀態，影響正常連線。SYN cookies、SYN cache 或代理式防護，各自有適用條件；不能只靠把等待佇列加大，就認為問題消失。這是在說主要機制，不是保證事件「一定不吃頻寬或 CPU」。RFC 4987：TCP SYN Flooding
我會把調查問題寫得更具體：哪一段先出現丟包？半開連線是否異常增加？服務延遲上升時，資料庫和工作佇列又發生什麼事？先對齊時間，再決定在哪裡介入，不從「連不上」直接跳到攻擊結論。
L5：登入狀態要能延續，也要能結束
Web Session 讓網站記住使用者已登入。問題是：如果承載登入狀態的憑證被偷走，伺服器會不會把拿著它的人當成原使用者？
Session ID 應難以猜測，登入或權限改變時適當更新，並由伺服器執行期限與撤銷。Cookie 的 Secure、HttpOnly、SameSite 各有用途；HttpOnly 限制腳本讀取 Cookie，卻不代表 XSS 無法藉使用者身分發出操作。OWASP：Session Management
所以「有設 Cookie」不是完成防護，「換了 IP」也不等於帳號一定遭入侵。調查時要把登入、工作階段、裝置與資料操作放在同一條時間線上理解。
L6：HTTPS 保護的是通道，不是整個網站的所有行為
圖 3｜綠色區塊是瀏覽器到網站 TLS 終止點的保護範圍。端點安全、使用者權限與資料庫連線，仍需要各自確認。
正確使用 TLS，可以保護通道的機密性、完整性並驗證對端；常見 HTTPS 情境主要驗證伺服器，不會自動證明操作網站的人是合法使用者。若前端在 CDN 或反向代理終止 TLS，後面連到源站的那段也要另外檢查。RFC 8446：TLS 1.3
SSL Stripping 的重點也不是破解現代 TLS，而是利用可介入的未加密起點，讓使用者停留在 HTTP。HSTS 讓瀏覽器對已知站點強制 HTTPS；首次接觸時是否已具備這項政策，仍是部署時要考慮的邊界。Preload 可以處理部分首次連線問題，但要符合條件並評估長期維護。OWASP：HSTS
憑證釘選（Pinning）也不是一般網站一律加上的標準答案。它帶來憑證輪替與更新風險，只有在能掌握客戶端、伺服器及可靠更新機制等條件下，才值得審慎評估。OWASP：Pinning
L7：流量合法進門，不代表程式處理得安全
圖 4｜SQL Injection 的核心修正位置在查詢建構；XSS 的核心修正位置在內容進入瀏覽器的方式。兩者不能用同一個「過濾特殊字元」概括。
SQL Injection 發生在不可信輸入影響了 SQL 的結構或語意。使用參數化查詢，把資料和查詢結構分開，並限制資料庫帳號權限，是基本方向；動態欄位名等不能直接套用值參數的位置，還需要受控設計。OWASP：SQL Injection Prevention
XSS 則是讓不可信內容在瀏覽器中變成可執行內容。依輸出位置採用正確編碼與安全 API；若功能真的允許富文字 HTML，則需要適當淨化。WAF 可作補充，不能代替程式修正。OWASP：XSS Prevention
應用層 DoS 也不一定靠巨大流量：反覆觸發昂貴報表或查詢，就可能壓垮應用資源。檢查請求成本、併發上限、逾時與限流；可安全快取的工作才使用快取。要同時監看延遲、資料庫和佇列，避免只看頻寬。OWASP：Denial of Service
有 HTTPS，為什麼還是可能資料外洩？
想像一個假設情境：使用者 A 已登入，網站卻讓他讀取使用者 B 的資料。連線全程可以有 HTTPS，但伺服器的授權檢查仍然出了問題。加密保護了傳送過程，沒有替伺服器決定「這筆資料能不能給 A」。權限應針對每次請求與目標資源驗證。OWASP：Authorization
如果由我開始調查，我會先列出待驗證的假設，而不是宣布 TLS 被破解：
- 是哪個帳號、工作階段或服務身分讀取了哪些資料？
- 當時的權限是否允許那個操作？伺服器真的檢查了嗎？
- 資料離開系統前，經過哪些端點、應用與連線？
- 現有紀錄能支持哪些結論，哪些仍需要補證據？
這不是固定的查案順序；事件範圍、可取得證據和緊急程度會影響先後。也別把所有例子硬串成一場從 L1 打到 L7 的入侵。
下一次回答 OSI，試著多說三句
挑一個你能描述的假設服務，不必操作攻擊工具，也不必拿公司的網路圖。先畫出「使用者 → 交換器 → 閘道 → 網站」，再選一項風險，用三句話回答：
- 正常情況下，資料應該怎麼走、由誰處理？
- 出問題的是信任關係、資源容量，還是程式與權限？
- 防護放在哪裡；設好之後，還有哪些事不能保證？
能把這三句講清楚，比多背幾個縮寫更有用。OSI 的價值，不是讓所有問題都有一個漂亮的層級標籤，而是讓我們更有依據地問下一個問題。