大部分人第一次接觸 TCP/IP,是在網路概論課本裡看那張四層或七層的模型圖,背下每一層負責什麼、常見協定有哪些,考完試就忘光。這篇不重複那張圖,而是換一個問法:這套從一九七零年代設計至今、幾乎撐起整個網際網路的協定,骨子裡到底藏著什麼跟資安相關的先天限制。

一套為了「能通」設計的協定,不是為了「安全」設計的協定

TCP/IP 誕生的年代,網路是學術機構跟軍方之間的小圈子,設計者要解決的問題是「怎麼讓封包穿過不穩定的線路,可靠地從 A 送到 B」,完全沒有考慮到未來會有數十億台裝置、而且裡面混雜著惡意的參與者。這個歷史背景解釋了為什麼今天講資安,常常要在 TCP/IP 這套底層邏輯上「後補」安全機制,而不是它原生就內建。

最直接的例子是 IP 協定本身不驗證來源。一個封包宣稱自己來自某個 IP 位址,接收端沒有機制去確認這個宣稱是真的——這種行為叫做 IP 位址偽造(IP Spoofing)。你可以把它想成寄信時信封上寫的寄件人地址,郵局不會去查證這個地址是不是你真的住的地方,一樣照送不誤。這個先天的信任漏洞,是後面很多攻擊手法(例如放大型 DDoS 攻擊)的基礎。

三次握手:TCP 怎麼建立連線,以及攻擊者怎麼鑽這個空子

TCP 建立連線的過程叫做三次握手:發起方送出 SYN(想建立連線),接收方回應 SYN-ACK(收到了,也同意),發起方再送出 ACK(確認),連線才算正式建立。這個設計的目的是讓雙方都確認彼此準備好收發資料,聽起來很嚴謹。

但這個機制有個資源分配上的破口:接收方收到 SYN 之後,就要先分配一部分記憶體資源來「記住」這個還沒完成的連線,等著對方的 ACK。如果攻擊者故意送出大量 SYN,卻永遠不回覆最後的 ACK,接收方會一直保留這些半開連線的資源,直到資源耗盡、沒辦法再處理正常使用者的連線請求。這種手法叫做 SYN Flood,是最早期也最經典的一種阻斷服務攻擊(Denial of Service),打的正是 TCP 協定運作邏輯裡「先信任、後驗證」的設計慣性。

埠號:系統對外的一扇扇門

一台主機的 IP 位址像是一棟大樓的地址,埠號(Port)則像是大樓裡的房間號碼,決定資料要送進哪個服務。常見服務有慣用的埠號,例如網頁服務用 80(HTTP)或 443(HTTPS)、遠端登入用 22(SSH)。這些埠號本身不是強制規定,只是業界約定俗成的慣例。

從資安角度看,每一個開放的埠號都是一個潛在的攻擊面。滲透測試流程裡的「掃描與列舉」階段(Day 3 提過),做的第一件事往往就是掃描目標主機開了哪些埠、上面跑著什麼服務——一台伺服器如果開著不需要對外服務、卻沒關掉的埠(例如測試用的資料庫管理介面),就等於在牆上留了一扇沒鎖、甚至沒關緊的門。這也是為什麼「關閉不必要的服務跟埠號」是資安基本功裡最枯燥、卻最有效的一項:攻擊面越小,能被鑽的空子自然越少。

封包在路上,誰都可能看得到

資料從你的電腦送到目的地,中間會經過好幾個中繼節點——你家的路由器、電信商的設備、可能還有其他業者的骨幹網路。如果傳輸過程沒有加密,封包裡的內容理論上任何一個中繼點都看得到,這正是 Day 7 會談的中間人攻擊之所以成立的前提。

這也是為什麼 HTTPS(在 HTTP 外面包一層加密)會變成現在網頁的標準配備,而不是可有可無的加分項——它處理的正是 TCP/IP 這套底層協定本身不保證機密性這個先天限制。加密不是修補 TCP/IP 的漏洞,而是在它之上加蓋一層原本設計時沒有的保護機制。

這一切對你的意義

了解這些不是要你去背 RFC 文件裡的每個欄位,而是建立一種底層思維:每次看到一個資安事件,可以往回追問「這是哪一層出的問題」。是應用程式邏輯寫錯(通常是後面 Web 安全篇章的範疇),還是底層協定運作邏輯本身就有這個空子可鑽?這個問題的答案,往往決定了防禦手段該往哪個層級去補——應用層寫得再安全,如果網路層完全不設防,攻擊者一樣有辦法從底下繞過去。