M03-06 · 作業系統指紋辨識

CEH v13｜M03-06 作業系統指紋辨識（OS Fingerprinting）

完整白話文教學：如何從網路封包判斷對方使用什麼作業系統？

這一章最重要的觀念：即使一台電腦沒有主動告訴你它使用 Windows、Linux 或其他作業系統，你仍然可能從它回應網路封包的方式，推測它使用的系統。

這項技術稱為 OS Fingerprinting（作業系統指紋辨識）。

但要記住：指紋辨識只能提供推測，不能直接證明作業系統的確切版本。

本篇依照你提供的 CS Kairos Learn｜M03-06 原始教材，按照九個主要章節逐一講解，包含生活比喻、技術原理、封包範例，以及如何與先前學過的 CEH 知識連結。

一、先建立整體觀念：為什麼要辨認作業系統？

假設你是公司的資安工程師，要了解某台伺服器的安全狀況。

你知道：

• IP 位址：`192.168.1.100`
• TCP Port 22：Open
• TCP Port 80：Open
• TCP Port 443：Open

這些資訊可以幫你知道這台設備有哪些網路服務。

但你還不知道：

它到底是 Windows Server？Ubuntu Server？還是某個特殊的網路設備？

這就需要 OS Fingerprinting。

與前面 CEH 章節的關係

你可以把前面學過的知識串起來：

                  目標設備
              192.168.1.100
                      │
                      ▼
              ① 主機探索
                Host Discovery
                      │
                      ▼
               設備有回應嗎？
                      │
                      ▼
              ② Port Scanning
                 掃描連接埠
                      │
                      ▼
            TCP 22、80、443 Open
                      │
                      ▼
              ③ Service Detection
                 服務版本辨識
                      │
                      ▼
              SSH / HTTP / HTTPS
                      │
                      ▼
              ④ OS Fingerprinting
                 作業系統指紋辨識
                      │
                      ▼
                類似 Linux？
                 類似 Windows？
                      │
                      ▼
              ⑤ 管理端確認
                Verify OS
                      │
                      ▼
              確認實際系統版本

這是一個便於理解的調查流程，不代表工具一定要依照固定順序執行。

接下來，我們進入原始教材的各個章節。

1｜生活例子：從回話習慣辨認窗口

1.1 為什麼網路封包可以暴露作業系統？

想像你打電話給三個不同的人。

第一個人接電話時說：

「您好，我是王先生，請問有什麼需要幫忙？」

第二個人說：

「喂，你好，請問找哪位？」

第三個人說：

「您好，這裡是資訊室，請問有什麼問題？」

雖然三個人都在做同一件事情——接電話，但是他們的回答習慣不同。

如果你已經聽過這三個人講話很多次，之後即使他們沒有報上姓名，你也可能根據說話習慣猜出是誰。

作業系統指紋辨識就是相同的概念。

假設今天有三台電腦：

電腦 A：Windows
電腦 B：Ubuntu Linux
電腦 C：FreeBSD

            資安工程師
                 │
                 │ 送出網路封包
                 ▼
       ┌─────────┬─────────┐
       │         │         │
       ▼         ▼         ▼
    Windows    Ubuntu    FreeBSD
       │         │         │
       ▼         ▼         ▼
    回應方式A  回應方式B  回應方式C
       │         │         │
       └─────────┼─────────┘
                 ▼
              收集特徵
                 │
                 ▼
           比對已知資料庫
                 │
                 ▼
           推測作業系統

Windows、Linux、FreeBSD 都需要遵守 TCP/IP 通訊規範。

但規範不會把所有實作細節都固定成完全相同。

因此，不同作業系統可能在以下方面有所差異：

• TCP 封包的某些預設參數。
• TCP 選項的支援情況與排列順序。
• TCP Sequence Number（序號）的產生方式。
• 收到特殊封包時的反應。
• IP 封包的某些初始設定。

Nmap 就是利用這些特徵進行作業系統推測。Nmap

1.2 什麼是 Protocol Stack（協定堆疊）？

這裡有一個重要的資工觀念。

我們之前學習 TCP、UDP、IP 的時候，認識的是「網路通訊協定」。

但協定只是規則。

真正負責執行規則的，是作業系統或設備中的網路協定堆疊實作。

例如：

你知道 TCP 建立連線需要三向交握（Three-way Handshake）：

Client                      Server
   │                           │
   │ --------- SYN ----------> │
   │                           │
   │ <------ SYN/ACK --------- │
   │                           │
   │ --------- ACK ----------> │
   │                           │
   │      連線建立完成          │

無論對方使用 Windows 還是 Linux，都必須按照 TCP 的規則完成連線。

但它們的 SYN/ACK 封包可能包含不同的 TCP 選項或參數。

這些差異，就是辨識工具可以利用的材料。

你需要建立的觀念

Protocol（協定）是大家共同遵守的規則；Protocol Stack Implementation（協定堆疊實作）是各個系統實際執行規則的方法。

所以，OS Fingerprinting 本質上是在辨認「協定實作的特徵」，而不是直接讀取對方的作業系統名稱。

另外，這種指紋不是像身分證號碼一樣唯一。兩台不同的 Linux 設備可能有類似指紋，系統更新也可能讓指紋改變。

2｜主動與被動：你怎麼取得線索？

這一節要認識兩種重要的辨識方式：

Active Fingerprinting（主動指紋辨識） 與 Passive Fingerprinting（被動指紋辨識）。

兩種方法都是在觀察網路封包，但取得封包的方式不同。

2.1 Active Fingerprinting：主動去問問題

想像你想辨認一個人的身分。

你主動問他幾個問題：

「你住在哪裡？」

「你平常使用什麼交通工具？」

「你在哪裡工作？」

接著分析他的回答。

這就是主動辨識的概念。

在網路世界裡，主動辨識工具會自己製作探測封包，送給目標設備。

例如 Nmap 的：

nmap -O

其中：

`nmap` 是網路掃描工具。

`-O` 是啟用 OS Detection，注意是大寫英文字母 O，不是數字零。

實際使用時仍須指定目標，並取得掃描授權。

Nmap 可能使用 TCP、UDP 和 ICMP 等不同類型的探測封包。

它不只是問「你在不在」，而是觀察：

「我給你這種封包，你會怎麼回答？」

「我換另一種封包，你的回答會不會不同？」

「我送到沒有開啟的 Port，你會怎麼處理？」

接著把不同回答組合成指紋。Nmap

主動辨識的優缺點

主動辨識的好處是，你可以設計不同的問題，取得比較完整的特徵。

但缺點是，它會產生額外網路流量。

在某些環境，主動探測可能觸發 IDS、IPS、防火牆告警，或對較脆弱的設備造成負擔。

因此，不能因為自己只是在「辨認系統」，就認為可以隨意掃描。

2.2 Passive Fingerprinting：觀察既有的對話

現在換個情境。

你不主動打電話給任何人，而是在合法授權的情況下，分析既有的通話紀錄。

透過他們原本的對話習慣，推測講話者可能是誰。

這就是被動辨識。

在網路環境中，被動辨識不需要為了辨認系統而額外送出探測封包。

它分析的是本來就已經發生的網路流量。

例如：

某台 Ubuntu 電腦正在連線到公司的網站。

如果你是有權監控這段流量的網管人員，就可能從這台電腦送出的 TCP 封包，分析它的協定實作特徵。

常見的工具是：

`p0f`

它可以利用既有網路流量進行被動 OS Fingerprinting。

但需要注意：被動辨識不代表能看見所有封包。交換器、路由設定、封包擷取位置都會影響能取得的資料。

主動與被動的差別

這一節最值得理解的觀念

主動是控制輸入，觀察輸出；被動是收集自然發生的輸入與輸出。

如果從資安研究角度來看，這其實與實驗設計有關。

主動辨識比較接近「受控實驗」，你能選擇刺激條件。

被動辨識比較接近「觀察性研究」，你利用已經發生的資料尋找規律。

但主動方法不一定比較準確，被動方法也不一定比較安全。兩者都會受到資料品質、環境及授權條件限制。

3｜工具在看什麼？先認識三種線索

這一節是整個 M03-06 最重要的技術部分。

我們要理解三種可能透露作業系統特徵的資訊：

1. IP 的 TTL。

2. TCP Window 與 TCP Options。

3. 不同封包探測下的回應方式。

先記住一個核心觀念：

辨識工具通常不是看單一數字，而是把多項特徵組合起來比較。

3.1 第一種線索：TTL（Time to Live）

TTL 是什麼？

TTL 是 IPv4 封包標頭中的一個欄位。

它的用途是避免封包在網路中無限制地轉送。

想像你要從宜蘭寄一份資料到台北。

途中可能經過好幾台路由器。

        來源設備
        TTL = 64
           │
           ▼
        Router A
        TTL = 63
           │
           ▼
        Router B
        TTL = 62
           │
           ▼
        Router C
        TTL = 61
           │
           ▼
        目的設備

這張圖假設每經過一台路由器，TTL 減少 1。

在一般 IPv4 轉送過程中，路由器會遞減 TTL。

如果 TTL 降到 0，封包就不能繼續轉送。

這可以避免網路發生路由迴圈時，封包永遠在網路上繞圈。RFC Editor

為什麼 TTL 能幫助辨識作業系統？

因為不同系統及網路設備可能使用不同的初始 TTL 設定。

例如，有些系統預設使用 64，有些使用 128。

如果你觀察到：

收到封包：

Source IP：192.168.1.100
TTL：61

你可能推測：

「它是不是從 TTL 64 開始，經過三次路由轉送？」

計算方式：

64 − 3 = 61

但這裡有一個很重要的問題。

你並不知道它的起始 TTL 一定是 64。

因此，觀察到 TTL 61，不代表你已經證明它使用 Linux。

初始 TTL 可以被修改，也可能受到設備類型與網路環境影響。

另一個容易誤會的地方

假設你是掃描者：

掃描者  ──── SYN ────>  伺服器
        <─── SYN/ACK ──

當你觀察收到的 SYN/ACK 封包 TTL 時：

這個 TTL 反映的是回應封包從產生回應的設備，傳回你的觀察位置的過程。

不是你的 SYN 封包到達對方時的 TTL。

換句話說，必須先確認你到底觀察的是哪個方向的封包。

本小節結論

TTL 能提供線索，但不足以單獨辨認 OS。

判讀時必須同時考慮初始 TTL、路由轉送次數、回應來源，以及其他封包特徵。

3.2 第二種線索：TCP Receive Window

什麼是 TCP Window？

還記得我們在 M03-01 學過 TCP 嗎？

TCP 的重要特性包含：

可靠傳輸、有序傳輸，以及流量控制。

TCP Receive Window（接收視窗）就是流量控制的一部分。

我們用一個生活例子理解。

假設你正在搬家。

你負責從貨車搬箱子進倉庫。

但倉庫目前只剩下可以放 10 個箱子的空間。

因此，你告訴搬運工：

「我現在最多只能再接收 10 箱。」

這個「10 箱」就很像 TCP Receive Window。

        傳送端                  接收端
       Sender                 Receiver
          │                       │
          │                       │
          │ <── Window = 4000 ─── │
          │                       │
          │  對方表示目前可再接收  │
          │  最多 4000 Bytes      │
          │                       │
          │ ──── 傳送資料 ───────> │
          │                       │

嚴格來說，TCP 接收視窗是接收端對傳送端公告的可接收資料範圍，並且會隨著緩衝區使用情況改變。

它不等於電腦的 RAM 容量，也不等於網路頻寬。

另外，TCP Window Scaling（視窗縮放）可以擴大可表示的接收視窗，因此讀取封包時也要考慮是否協商了縮放選項。SYN 與 SYN/ACK 本身的 Window 欄位不套用縮放；後續封包才依協商結果解讀。RFC 7323

為什麼 Receive Window 可以幫助辨認 OS？

不同作業系統的 TCP 協定堆疊，可能採用不同的初始視窗設定與行為。

例如，假設我們觀察到兩台設備：

以上數值只是用來說明的合成範例，並不對應特定作業系統。

你會發現：

雖然兩台設備都在使用 TCP，但它們的設定組合可能不同。

這就是辨識工具會收集的資訊。

3.3 第二大類線索（續）：TCP Options

TCP 的基本標頭包含來源 Port、目的 Port、Sequence Number、ACK Number 等欄位。

除此之外，TCP 還可以攜帶額外的 Options（選項）。

你可以把它想成：

大家使用相同格式的申請表，但某些人會勾選不同的附加功能。

例如：

這些選項的存在與排列方式，都可能成為辨識線索。

例如，假設我們觀察兩台設備的 SYN/ACK：

設備 A：

TCP Options:
MSS
SACK Permitted
Timestamp
Window Scale


設備 B：

TCP Options:
MSS
Window Scale
SACK Permitted

兩台設備都遵守 TCP 規範。

但它們選擇的功能、排列順序不同。

這些差異可能反映出不同的 TCP Stack 實作。

當然，單靠這些選項仍然不足以確認作業系統。

Nmap 會利用多次探測收集不同的 TCP 選項與視窗資訊，再組合成指紋。RFC Editor

3.4 第三大類線索：不同探測下的回應方式

原教材將這部分歸在第三大類。

這裡需要把之前學過的 TCP 和 ICMP 知識結合起來。

想像你今天去一間公司辦事。

你可能遇到以下狀況：

正常提出申請時，櫃檯按照流程接受。

提出不符合規定的申請時，櫃檯可能直接拒絕。

提出奇怪的問題時，有些櫃檯會回覆錯誤訊息，有些可能沒有回應。

不同櫃檯處理例外狀況的方法可能不一樣。

作業系統也可能如此。

Nmap 會使用多種探測封包，例如：

例如：

我們之前學過，對沒有服務監聽的 TCP Port 發出 SYN，通常會收到 RST。

但辨識工具不只看「有沒有收到 RST」。

它還可以觀察回應封包中的其他欄位與細節。

這些特徵組合起來，才有機會分辨不同系統。

Nmap 實際使用什麼資料？

Nmap 官方文件記載，IPv4 OS 指紋辨識會執行多種測試，包括：

`SEQ`：序號相關特徵。

`OPS`：TCP Options。

`WIN`：TCP Window。

`IE`：ICMP Echo 相關特徵。

`ECN`：TCP Explicit Congestion Notification。

`T1–T7`：不同 TCP 探測的回應。

`U1`：UDP 探測的回應。

這些資訊會共同構成用於比對的指紋。Nmap

你不需要現在就背下每個測試的細節。

但要理解：

OS Fingerprinting 並不是一個欄位對應一個系統，而是多個特徵一起提供辨識能力。

這就像辨認一個人的筆跡。

你不會因為某個人寫了一個特定形狀的「中」字，就百分之百認定他是誰。

你可能還會看其他字的寫法、字距、傾斜角度等特徵。

當特徵組合越完整，通常越有機會做出可靠推測。

不過，特徵之間可能相關，也可能受到網路設備共同干擾，所以不能簡單認為特徵越多就一定越準。

4｜為什麼希望同時找到 Open 和 Closed？

這一節會把 M03-03 的 Port Scanning 與本章串起來。

先回想之前學過的 TCP SYN 掃描。

4.1 Open Port：有服務願意接受連線

假設一台伺服器的 TCP 443 正在提供 HTTPS 服務。

你送出 SYN：

Client                     Server
   │                          │
   │ ───── SYN / 443 ───────> │
   │                          │
   │ <────── SYN/ACK ──────── │
   │                          │
   ▼                          ▼
 可判斷這個 Port 為 Open

因為有服務監聽，所以一般情況下，伺服器會回覆 SYN/ACK。

這個回應包含一些可以用於辨識的 TCP 特徵。

4.2 Closed Port：沒有服務接受連線

現在假設 TCP 65000 沒有任何程式監聽。

Client                     Server
   │                          │
   │ ──── SYN / 65000 ──────> │
   │                          │
   │ <──────── RST ────────── │
   │                          │
   ▼                          ▼
 可判斷這個 Port 為 Closed

對一般 TCP SYN 探測來說，收到有效 RST 通常表示該 Port 為 Closed。

請注意，回應也可能由中間的防火牆產生，因此仍需要判斷回應來源。

4.3 為什麼 Open 和 Closed 都重要？

假設你想了解一個人的應對習慣。

你只觀察他接受請求的方式，可能不夠。

如果也觀察他拒絕請求的方式，就能得到另一組資訊。

TCP 指紋辨識也是如此。

Open Port 的回應，可以提供某些 TCP Stack 特徵。

Closed Port 的回應，可以提供另一組特徵。

因此，對 Nmap 的 OS Detection 而言：

同時找到至少一個 Open TCP Port 和一個 Closed TCP Port，通常可以提高辨識效果。

這也是 Nmap 官方文件明確提到的條件。Nmap

如果只有 Open，沒有 Closed 呢？

Nmap 仍可能嘗試辨識。

但是它可能顯示類似以下的警告：

Warning: OS detection will be MUCH less reliable
because we did not find at least 1 open
and 1 closed TCP port

白話文就是：

「我沒有同時找到開啟和關閉的 TCP Port，所以這次 OS 辨識的可靠程度會受到影響。」

這不代表對方沒有作業系統。

只是代表這次取得的辨識資料不夠理想。

那 Filtered 呢？

還記得 M03-03 的內容嗎？

Filtered 表示因過濾或其他因素，工具無法透過這次探測確定 Port 是開啟還是關閉。

例如：

Client                     Firewall           Server
   │                          │                  │
   │ ───── SYN ─────────────> │                  │
   │                          X                  │
   │                       封包遭丟棄            │
   │                                             │
   │  等待逾時，沒有取得可判斷的回應               │

在這個例子中，掃描者無法取得伺服器原本可能產生的回應。

因此，Filtered 不應直接當成 Closed。

4.4 三個容易混淆的 Nmap 參數

`-A` 也會啟用預設 NSE Script Scanning 和 Traceroute 等功能，並不只是 `-O` 的另一種寫法。

考試重點：辨認 OS 用 `-O`，辨認服務版本用 `-sV`。

5｜相符百分比應該怎麼讀？

這一節非常重要，因為它牽涉到統計解釋與證據強度。

假設你使用 OS Fingerprinting 工具，得到以下合成結果：

OS Candidate:

Linux-like System: 95%
FreeBSD-like System: 82%

請問：

這代表目標有 95% 的機率是 Linux 嗎？

不一定，而且不能直接這樣解釋。

5.1 相似度不等於真實機率

先用一個例子。

假設你今天想要辨認一個人的筆跡。

你建立了一個辨識系統，分析 20 項筆跡特徵。

系統發現：

某個人的筆跡與已知樣本，有 19 項特徵一致。

因此你計算：

19 ÷ 20 × 100% = 95%

這個例子中的 95%，表示特徵符合比例。

但你能直接說：

「這份筆跡有 95% 的機率是某個人寫的」嗎？

不能。

因為可能有很多人具有類似的筆跡。

而且不同特徵的辨識能力可能不同。

5.2 Nmap 是怎麼比對的？

以 Nmap 官方說明的 IPv4 OS Fingerprinting 為例，它會將取得的指紋與 `nmap-os-db` 中的已知樣本進行比較。

不同測試項目具有不同的權重。

可以用以下簡化概念理解：

Match Score = 符合項目的加權分數 ÷ 可比較項目的總加權分數

假設：

可比較項目的總加權分數是 100。

符合的項目得到 95 分。

最後得到：

Match Score = 95%

這表示與資料庫中某個樣本高度相符。

但它不代表已經經過統計校準，能保證在真實世界有 95% 的正確率。

需要補充的是，Nmap 的 IPv6 OS 分類採用不同的方法，因此不能假設所有 OS 辨識分數都用同一種公式計算。Nmap

5.3 為什麼工具可能辨識錯誤？

想像有以下情況。

某台設備原本是 Ubuntu。

但管理員修改了某些網路參數。

另一種情況是，這台設備前面存在代理伺服器或其他網路設備。

第三種情況是，目標運行的系統版本很新，而辨識資料庫尚未有足夠的對應樣本。

這些原因都可能影響辨識結果。

因此，工具可能顯示：

No exact OS matches for host

意思是：

「這次沒有找到足夠精確的已知作業系統指紋。」

但絕對不代表：

「這台設備沒有作業系統。」

更不代表：

「這台設備一定安全。」

這一節要學會的專業判斷

假設你的資安報告中寫：

已確認目標使用 Linux，信心度 95%。

這個描述可能過度確定。

比較適當的寫法是：

OS 指紋比對結果顯示，目標與 Linux 類系統的已知特徵高度相符，工具顯示 95% 的相符分數；但尚未透過管理端資料確認實際作業系統及版本。

這就是將「工具推測」與「已驗證事實」分開。

在滲透測試、數位鑑識及資安稽核中，這是一項非常重要的專業能力。

6｜你辨認到的是前端，還是後端？

這一節是我認為整個 M03-06 最值得深入理解的實務問題之一。

因為現代網路架構中，一個 IP 位址不一定只對應一台伺服器。

很多網站的前面都有 Reverse Proxy（反向代理）、Load Balancer（負載平衡器）、Firewall（防火牆）等設備。

因此：

你掃描到的作業系統，不一定是實際執行網站程式的那台伺服器。

6.1 先用生活例子理解

假設你打電話到一間醫院。

電話先由總機人員接聽，再轉給醫師。

          你
          │
          │ 打電話
          ▼
       醫院總機
          │
          │ 轉接電話
          ▼
         醫師

如果你根據接電話的方式分析對方身分，你首先觀察到的是總機人員的特徵。

不一定是醫師的特徵。

這與網路上的 Reverse Proxy 很相似。

6.2 Reverse Proxy 是什麼？

假設你架設一個網站。

你有兩台伺服器：

伺服器 A：Nginx Reverse Proxy。

伺服器 B：真正執行網站程式的 Application Server。

外部使用者要瀏覽網站時，可能先連到 A。

A 再向 B 取得網站內容。

          外部使用者
              │
              │ HTTPS Request
              ▼
    ┌────────────────────┐
    │  Server A          │
    │  Reverse Proxy     │
    │                    │
    │  接受外部 TCP 連線  │
    └────────────────────┘
              │
              │ 新的內部連線
              ▼
    ┌────────────────────┐
    │  Server B          │
    │  Application       │
    │                    │
    │  實際執行網站程式   │
    └────────────────────┘

這裡有一個非常重要的技術細節。

如果 A 終止外部 TCP 連線，再對 B 建立另一條 TCP 連線，那麼外部觀察者取得的 TCP 指紋，通常優先反映 A 的協定堆疊。

它不是直接反映 B 的 TCP Stack。

但網站回傳的 HTTP 內容，可能來自 B。

會發生什麼情況？

假設：

Server A：Linux
Server B：Windows Server

現在外部資安工程師使用兩種方法：

第一種：OS Fingerprinting。

得到的結果：

OS Guess: Linux

第二種：Service Version Detection。

網站回應提供了與 Windows IIS 有關的線索：

Server: Microsoft-IIS

你可能覺得很奇怪：

「為什麼 OS 是 Linux，但 Web Server 卻像 Windows IIS？」

其實兩者不一定衝突。

因為你可能從不同層次觀察到了不同設備。

             掃描者
                │
                ▼
       ┌─────────────────┐
       │ A：Linux        │
       │ Reverse Proxy   │
       └─────────────────┘
                │
                ▼
       ┌─────────────────┐
       │ B：Windows      │
       │ IIS Web Server  │
       └─────────────────┘


TCP 指紋
    └── 可能來自 A

HTTP 服務資訊
    └── 可能來自 B

但 HTTP `Server` 標頭也可以被代理修改，因此仍須查證。

你需要辨認的是：每一項證據究竟來自哪一台設備、哪一個網路層次。

Nmap 官方也明確區分 TCP/IP Stack 指紋與服務版本辨識所產生的系統線索。Nmap

6.3 NAT 與 Reverse Proxy 有什麼不同？

這是容易混淆的地方。

我們之前在網路課程認識過 NAT（Network Address Translation，網路位址轉換）。

NAT 的主要工作是轉換網路封包中的位址或連接埠資訊。

它不一定會終止 TCP 連線。

例如：

        外部 Client
              │
              │ TCP 連線
              ▼
       NAT Gateway
       改寫位址資訊
              │
              ▼
       內部 Server
       真正處理 TCP

假設 NAT 只是轉換位址並轉送封包，外部觀察到的 TCP 回應仍可能由內部 Server 的協定堆疊產生。

這與 TCP Reverse Proxy 不同。

例如防火牆可能直接替目標回覆 RST。

這時候，你看到的部分 TCP 回應，可能不是由原始目標作業系統產生的。

Nmap 官方文件也將這些中間設備視為 OS 指紋辨識可能出錯的原因。Nmap

本章的核心

你要養成一個習慣：

當你看到任何掃描結果，不要只問：

「它顯示什麼作業系統？」

還應該問：

「這個封包到底是誰產生的？」

這才是能夠真正理解網路架構的資安工程師需要具備的判斷能力。

原教材也有一張適合搭配本節閱讀的圖：

查看原教材：前端與後端 TCP 連線示意圖（SVG）

7｜完整合成案例：從「像什麼」走到「確認什麼」

現在我們把前面六節整合起來。

假設你是某公司的資安工程師。

公司授權你在隔離測試環境中，分析一個網站服務。

網路架構如下：

              資安工程師
                  │
                  │
                  ▼
        192.168.1.100
         Frontend A
                  │
                  │ Reverse Proxy
                  ▼
        192.168.1.200
          Backend B

前端 A 負責接受外部 TCP 連線，再連線至後端 B。

這是教學用的合成情境，不是真實掃描結果。

7.1 第一階段：取得 Port 資訊

你得到以下結果：

Host: 192.168.1.100

PORT       STATE
443/tcp    open
65000/tcp  closed

這代表什麼？

TCP 443：

這次測試得到 Open 的結果，表示有服務接受該連接埠的連線。

TCP 65000：

這次測試得到 Closed 的結果，表示該入口沒有服務監聽，且取得了可以支持 Closed 判斷的回應。

但是，現在還不知道確切的 OS。

7.2 第二階段：取得封包特徵

工具又觀察到：

IP TTL: 61

TCP Window:
  已取得視窗欄位

TCP Options:
  已取得選項及順序

你可以得到什麼結論？

首先：

TTL 61 是一項觀察結果。

其次：

TCP Window 與 TCP Options 是另外兩組可能有辨識價值的資料。

但這些資訊本身不能直接證明對方使用哪個作業系統。

7.3 第三階段：OS 指紋比對

接著，辨識工具提供了以下候選：

OS Candidate:

System Family A

這表示：

工具認為目標回應與資料庫中的系統家族 A 特徵相近。

但它仍然是推測。

不能直接當成已驗證的 OS。

7.4 第四階段：服務辨識

接著，你取得網站回應：

Application: B

工具現在掌握兩項資訊：

OS 指紋像是系統家族 A。

應用程式資訊顯示 B。

那麼，A 與 B 是不是互相矛盾？

不一定。

因為架構文件顯示：

前端 A 終止外部 TCP 連線。

後端 B 提供應用服務。

因此，一個合理的假設是：

TCP 指紋可能來自前端 A。

應用資訊可能來自後端 B。

但是仍需由管理端確認。

7.5 第五階段：建立證據紀錄

這一節最重要的成果，是學會將證據分成三個層次。

如果要寫成專業資安報告，可以這樣表達：

在指定測試位置與時間，前端服務的 TCP 443 呈現 Open、TCP 65000 呈現 Closed，並取得 TTL 與 TCP 選項等特徵。

OS Fingerprinting 工具將目標歸類為系統家族 A 的候選。

根據現有架構文件，外部 TCP 連線由前端設備 A 終止，因此該指紋應優先與前端設備核對。應用程式 B 的回應資訊則應另外確認實際來源。

目前尚未透過管理端確認兩台設備的完整系統版本、核心版本及修補狀態。

這樣的紀錄有幾個好處。

首先，別人可以知道哪些資訊確實有觀察到。

其次，別人知道哪些是工具推論。

最後，別人可以明確知道還需要補哪些證據。

進一步：管理端究竟要確認什麼？

假設前端 A 確實是一台 Ubuntu Server。

管理員可以登入自己的 Ubuntu，使用：

cat /etc/os-release

查看系統發行版資訊。

例如：

NAME="Ubuntu"
VERSION_ID="24.04"

接著使用：

uname -r

查看正在執行的 Linux Kernel 版本。

還可以使用：

sudo ss -lntp

查看本機正在監聽的 TCP 服務。

這三種證據的用途不同：

需要特別注意：如果在容器內執行，`/etc/os-release` 可能描述容器中的發行版，而 `uname -r` 通常反映共用的宿主機核心。

同樣地，這些指令也不能單獨證明系統已完成所有安全修補。

仍需要核對套件版本、供應商安全公告，以及實際安裝與重啟狀態。

本節結論

完整的 OS Fingerprinting 工作不應停在：

Nmap 說它是 Linux
          │
          ▼
       結案

而應該是：

觀察網路回應
      │
      ▼
取得 OS 指紋
      │
      ▼
比對已知資料庫
      │
      ▼
取得候選系統
      │
      ▼
確認網路架構
      │
      ▼
確認回應來源
      │
      ▼
管理端查證系統版本
      │
      ▼
確認修補狀態
      │
      ▼
完成有證據的資產紀錄

查看原教材：作業系統指紋證據查核流程圖（SVG）

8｜防護與驗收：把識別結果用在維運

我們已經學會如何推測 OS。

但這項技術對防守方有什麼價值？

這一節要從「辨認系統」進一步思考「如何改善資安管理」。

原教材提出四個主要方向。

8.1 第一個方向：維護資產清單

假設一家公司有 100 台設備。

資產管理系統記錄：

80 台 Windows 工作站
15 台 Linux Server
5 台網路設備

但是經過授權的網路盤點後，發現某個 IP 位址呈現出疑似路由器或其他設備的特徵。

這時候，你不應直接將它當成惡意設備。

而是應該進一步確認：

這台設備是否登錄於資產清單？

它是否由公司管理？

它的用途是什麼？

誰負責維護？

這有助於找出未納管設備或資產資料不一致的問題。

要如何驗收？

不只是確認有一份資產清單。

還應該確認：

能否將觀察到的 IP、設備識別資訊、實際資產、負責人及系統版本對應起來？

而且這些資料有沒有記錄來源與確認日期？

OS Fingerprinting 是資產發現的輔助工具，不是資產身分的最終證明。

8.2 第二個方向：減少不必要的開放入口

假設你發現：

某台公司的網站伺服器有以下 Port：

22/tcp    open
80/tcp    open
443/tcp   open
3306/tcp  open

你知道：

22 通常用於 SSH。

80 通常用於 HTTP。

443 通常用於 HTTPS。

3306 常見於 MySQL。

請問：

這是不是代表所有 Port 都有漏洞？

不是。

Open 代表有服務入口，但不代表服務必然存在弱點。

你真正應該做的是：

確認這些服務是否有業務必要，以及是否應允許目前的來源存取。

例如：

假設公司的 MySQL 服務只需要接受後端應用伺服器的連線。

那麼就可以評估是否應限制其他來源對資料庫入口的連線。

這是一種降低 Attack Surface（攻擊面）的措施。

如何驗收？

必須從不同來源驗證實際存取結果。

例如：

授權的應用伺服器應能連線。

未獲授權的來源則不應連線成功。

注意，從某個來源觀察到 Filtered，不代表所有來源都受到相同的限制。

這正好呼應我們在 M03-04 學過的觀念：Port State 是特定探測條件下的觀測結果。

8.3 第三個方向：更新與修補

假設 OS Fingerprinting 顯示某台設備可能使用某個 Linux Kernel 家族。

你是否可以直接拿這個結果，搜尋 CVE，然後宣告：

「這台設備存在某個核心漏洞」？

不能。

因為：

OS Fingerprinting 不一定能準確辨認 Kernel 版本。

而且即使版本名稱看似較舊，也不代表一定缺少安全修補。

Linux 發行版供應商可能將安全修補程式回移到既有套件版本，這種機制稱為 Backport。

因此，版本字串不能單獨證明漏洞存在，也不能單獨證明漏洞已修補。

Nmap 官方文件也特別提到，套件版本資訊與實際修補狀態不一定完全一致。Nmap

正確流程

OS Fingerprinting
       │
       ▼
取得系統候選
       │
       ▼
確認實際 OS
       │
       ▼
確認 Kernel／套件版本
       │
       ▼
比對供應商安全公告
       │
       ▼
確認適用的安全更新
       │
       ▼
部署與驗證更新
       │
       ▼
記錄最終修補狀態

這也是後續 M05 Vulnerability Analysis（弱點分析）會進一步學習的核心工作之一。

8.4 第四個方向：觀察異常探測

還記得我們在第二節討論 Active Fingerprinting 嗎？

主動 OS Fingerprinting 可能送出多種探測封包。

因此，防守方可能透過防火牆、IDS 或其他網路監控系統，觀察到某些與指紋辨識相關的活動。

例如：

短時間內，某個來源對同一台設備送出多種 TCP 探測。

其中包含一般業務流量比較少出現的封包特徵。

這些行為可能值得調查。

但不能只因為看到幾個特殊封包，就認定對方一定在攻擊。

原因包括：

合法的網路診斷工具可能產生類似流量。

授權的弱點掃描也可能產生這些封包。

不同網路設備可能影響日誌內容。

因此，應該將來源、時間、目標、封包特徵與實際授權情況一起分析。

如何驗收？

假設你部署了一套偵測規則。

應該在隔離且已授權的環境中，使用已知測試流量驗證：

偵測系統是否能取得相關紀錄？

是否能辨認需要調查的活動？

是否會產生大量誤報？

紀錄是否能對應到實際設備與發生時間？

沒有看到告警，不代表一定沒有發生探測，也可能是監控位置或偵測能力不足。

9｜安全練習與小檢核

最後一節，我們要把整章知識整合起來。

原始教材使用紙上案例進行練習，不要求對任何真實設備執行掃描。

我們沿用這種方式，先練習判斷證據。

9.1 綜合情境

假設某醫院有以下架構：

               Internet
                   │
                   ▼
             Firewall
                   │
                   ▼
        ┌─────────────────────┐
        │ Server A            │
        │ Reverse Proxy       │
        │ 192.168.1.10        │
        └─────────────────────┘
                   │
                   ▼
        ┌─────────────────────┐
        │ Server B            │
        │ Hospital Web App    │
        │ 192.168.1.20        │
        └─────────────────────┘

你在授權測試中取得：

TCP Port:

443/tcp   open
65000/tcp closed


Packet Characteristics:

TTL: 61

TCP Options:
MSS
SACK Permitted
Timestamp
Window Scale


OS Detection:

Candidate: Linux-like System
Match Score: 95%


Service Detection:

Application: Hospital Web App

架構文件另外記載：

Server A 終止外部 TCP 連線。

Server B 執行醫院網站應用程式。

9.2 判讀練習

請試著回答以下四題。

問題一：TTL

你看到 TTL 61。

為什麼不能直接判斷這台設備一定是 Linux？

你還需要哪些資訊？

問題二：主動與被動辨識

假設你有兩種方式：

方法 A：在授權環境中使用 Nmap `-O`。

方法 B：分析已合法取得的既有網路封包。

這兩種方法取得證據的方式有什麼不同？各有哪些限制？

問題三：Reverse Proxy

工具顯示：

OS: Linux-like System
Application: Hospital Web App

但你知道前端 A 終止 TCP 連線。

你應該優先確認哪一台設備的作業系統？

為什麼不能直接認定後端 B 使用 Linux？

問題四：證據與驗證

假設 OS 指紋比對分數是 95%。

你的報告可以直接寫：

「已確認系統使用 Linux，可信度為 95%」嗎？

如果不行，你會如何修改這段文字？

10｜來源與版本範圍

這一節是補充原教材的技術依據。

本課主要依照 CS Kairos Learn 的 M03-06 教材整理，並核對 Nmap 官方技術文件與網路協定規範。

以下四份文件最值得保留：

技術上的一個注意事項是：Nmap 的 OS 辨識實作與資料庫可能隨版本更新，因此分析真實掃描結果時，也要保存工具版本。

11｜延伸 Q&A：初學者最容易混淆的三件事

以下三題是教材延伸解說；實際讀者提問另由頁面 Q&A 區保存。

Q1：如果我知道對方的 IP，就能知道對方的作業系統嗎？

不能。

IP 位址只是網路定位資訊。

它本身通常不會告訴你對方使用什麼作業系統。

你需要透過封包回應、服務資訊或授權管理端資料，取得更多證據。

即使有封包回應，也不保證能辨認成功。

Q2：如果網站使用 HTTPS，還能進行 OS Fingerprinting 嗎？

可以。

對使用 TCP 的 HTTPS 連線（例如 HTTP/1.1 或 HTTP/2），TLS 加密應用資料，但不代表外部觀察者完全看不到 IP 與 TCP 標頭。HTTP/3 使用 QUIC／UDP，不能直接套用這裡的 TCP Window 與 TCP Options 判讀。

例如 TCP Window、TCP Options 等資訊，仍可能出現在未被 TLS 加密的網路封包標頭中。

因此，使用 HTTPS 不會自動阻止 TCP/IP 指紋辨識。

不過，如果前面還有 Reverse Proxy、VPN 或其他網路設備，可能改變實際觀察到的端點及封包特徵。

Q3：如果 Nmap 已經辨認出 Linux，是不是就可以開始找 Linux 漏洞？

OS Fingerprinting 的結果可以作為後續弱點調查的線索。

但不能直接推定存在某個漏洞。

至少還需要確認實際系統與版本、相關元件、修補狀態，以及漏洞的適用條件。

這也說明了 CEH M03 與 M05 的差異：

M03 偏重發現與辨識；M05 則進一步評估弱點是否存在，以及它的風險。

本章總整理：OS Fingerprinting 的核心知識地圖

最後，你應該真正掌握的一件事

這一章表面上是在教你「如何辨認作業系統」。

但從資安工程與研究的角度來看，它還在訓練一項更重要的能力：

從有限的網路觀測，建立可驗證的技術推論。

整個過程可以濃縮成：

觀察 → 特徵 → 推測 → 查證 → 結論

其中最容易犯錯的地方，就是把「推測」直接當成「結論」。

這個原則不只適用於 OS Fingerprinting，也適用於後續的服務辨識、弱點分析、入侵調查與數位鑑識。

建議下一步： 先完成第 9 節的四道情境題，特別是第三題的 Reverse Proxy 判斷。只要能清楚說出「誰產生封包、工具辨認的是誰、還缺什麼證據」，就已掌握本章最重要的技術概念。

參考解答：TTL 61 能確認系統嗎？

TTL 61 是接收位置看到的剩餘值；來源初始值與沿途扣減都會影響它。假設從 64 開始、每站扣 1，才可得到 3 次扣減的合成推算。不同系統與設定可能呈現相同 TTL，因此還需其他回應特徵、網路位置及管理端資料。請把實際數值與假設分開記錄。

參考解答：主動與被動如何取得證據？

分析已合法取得的既有封包，是利用當時已發生的流量；能分析什麼受紀錄內容及觀察位置限制。Nmap -O 則會另送探測、觀察回應，屬主動辨識。兩者都需要適當授權；被動不代表可以任意收集他人的流量。

參考解答：前後端線索如何核對？

先確認外部 TCP 連線在哪裡終止。若在前端，協定堆疊指紋優先用來查核前端；服務自述另核對其實際來源與後端執行中程式。保留各自的觀察位置、時間、工具與原始回應，再以架構設定、設備版本和更新紀錄確認。線索不同可以反映不同層的設備，不必先認定其中一個結果錯誤。

參考解答：候選或無精確匹配如何記錄？

寫明「工具推測／候選」、原始名稱與分數，以及缺少的回應或工具警告。95% 的特徵比對分數不自動等於真實正確率；無精確匹配也不等於沒有作業系統。接著請授權管理者核對目標設備、完整系統與核心版本、套件修補紀錄及前置設備關係。確認前不把候選直接填成已驗證版本或弱點成立。