M03-05 · 服務版本與橫幅蒐集

CEH M03-05｜服務版本與 Banner：怎麼知道開著的入口在提供什麼服務？

一句話結論：連接埠告訴你入口在哪，服務回應提供辨識線索；把回應、測試條件與設備端資料對起來，才能更可靠地確認服務及修補狀態。

上一單元的重點是 Open、Closed、Filtered：這次測試看到了什麼連接埠狀態。今天接著回答一個問題：入口開著之後，裡面究竟是什麼服務、什麼版本？

1｜先用店面招牌理解

想像同一條街上有一間店：

- 門牌是 443 號，這只是地址線索。

- 你按門鈴，有人回應，表示這次能聯絡到這個入口。

- 對方說「這裡是晨光書店」，你取得店家自我介紹。

- 你依規則詢問營業項目，從回答方式辨認它提供哪些服務。

- 最後，管理者出示登記資料與實際營業紀錄，你再核對是否一致。

網路服務也類似。Port（連接埠）是網路程式接收通訊的入口編號；Service（服務）是入口提供的功能，例如網頁、郵件或遠端管理；Version（版本）是軟體的版本識別。三者有關聯，但不能只憑一個入口號碼，就把服務、產品及完整版本都填好。

例如 TCP 443 常用於 HTTPS。TCP（傳輸控制協定）提供有連線的可靠傳輸；HTTPS是經過 TLS（傳輸層安全性協定）保護的 HTTP 網頁通訊。自訂服務也可以使用 TCP 443；一般網頁服務也可以設在其他連接埠。

2｜Banner 是什麼？取得它有什麼用？

Banner（服務識別訊息）是服務對外回傳、可用來辨識自身的文字或資訊。Banner Grabbing（擷取服務識別訊息）就是取得這些回應，作為資產盤點與後續查核的線索。

它不是只指登入畫面的歡迎標語。常見例子包括：

以上字串是合成示例，不是實際掃描結果。SSH 是 Secure Shell，用來建立安全遠端連線；HTTP 是 Hypertext Transfer Protocol，網頁用來交換請求與回應的協定；標頭是描述請求或回應的欄位。

Banner 的價值是讓你開始有依據地盤點：這個端點可能提供什麼、是否出現未預期的服務、要找哪位管理者核對。它也可能省略版本、被管理者修改，或出自前面的代理服務。因此，先保留原始回應，再標註它支持到哪一層結論。

3｜「等服務先說話」與「送出探測」有何不同？

取得識別資料時，有些服務會在連線建立後先傳送開場訊息；另一些服務要收到符合協定的請求，才會回答。

Probe（探測訊息）是為了觀察服務行為而送出的資料。Service Detection（服務辨識）會分析回應內容；Version Detection（版本辨識）進一步嘗試辨認產品、版本及相關資訊。Banner 擷取是其中一種方法，不涵蓋所有辨識技術。

Nmap 是網路探索與安全稽核工具。它的服務辨識流程可能先建立 TCP 連線、等待服務自行回覆，再依服務情況送出探測。官方所稱的 NULL probe（空探測），在這個情境是連線建立後不先送應用層探測內容、先等回應。它仍然會建立網路連線，不能當成完全不接觸目標的被動蒐集。

相較之下，分析一份原本已合法取得的封包紀錄，而不另外連到目標，是不同的觀察方式。無論採哪一種，都要遵守授權、資料使用與保留範圍。

4｜Nmap 的 SERVICE 欄位，證據從哪裡來？

先分清楚兩種來源：

1. 依連接埠對照常見名稱：工具可能根據連接埠與協定的對照表，顯示常見服務名稱。這是分類線索，不是已驗證程式身分。

2. 依實際回應辨識：啟用 Nmap 的 `-sV` 後，工具會嘗試使用回應與特徵資料庫判別服務及版本。這比只看入口號碼多了一層證據，但仍要檢查結果與測試條件。

下列只供理解參數，不是要求掃描外部主機：

nmap -sV -p 8080 <已明確授權的隔離實驗主機>

`-sV` 表示服務／版本辨識；`-p 8080` 限定連接埠 8080。尖括號內容是說明文字，不能直接當成位址執行。要實作，應先確認目標、服務、測試時段、探測方式及停止條件都在授權內。

版本探測會和服務互動，不能保證零影響；部分設備可能把探測內容當成實際工作。初學練習不覆寫工具的預設排除設定，也不使用包含其他功能的 `-A` 來代替本課的 `-sV`。

工具可能得到完整匹配，也可能只有部分線索。Nmap 的 softmatch（初步服務匹配）可協助縮小後續探測範圍；它不等於確認了精確版本，也不是可自行換算成「九成正確」的分數。辨識不到時，保留「未能確認」比猜填版本更有用。

版本辨識與 OS Fingerprinting（作業系統指紋辨識）也要分開。前者主要看應用服務回應；後者如 Nmap 的 `-O`，會利用網路協定堆疊的回應特徵推測作業系統。服務回應中的平台線索可以保留，但不能直接代替作業系統查核。下一單元才會深入 OS 指紋。

5｜為什麼看到版本，還不能直接宣布有漏洞？

Vulnerability（弱點）是可能被利用的安全缺陷。要確認某個弱點是否適用，除了版本線索，還需要核對產品、套件來源、修補紀錄、設定與成立條件。

兩個常見原因：

A. 你看到的可能是前面的代理

Reverse Proxy（反向代理）是代替後端服務接收用戶端請求的前端。Backend／Origin（後端／來源伺服器）則是後方實際處理部分工作的服務。

用戶端 → 反向代理 → 後端應用程式
          ↑ 這裡可能產生或調整回應標頭

因此，從外部看到的 `Server` 字串，可能描述前端，也可能是轉送或修改過的資訊。它不能單獨證明後端套件的精確版本。HTTP 規範也允許不提供 `Server` 欄位，並建議避免透露不必要的細節。

B. 舊版號可能已回補安全修正

Backport（回補修正）是把新版中的特定修正帶回較舊的維護版本，而不一定改成相同的上游主版本號。Upstream（上游）可理解為原始軟體專案；作業系統供應商可能另外維護自己的套件版本與修補紀錄。

所以，一個看似舊的字串，可能對應已修補的供應商套件。反過來，看不到版本也不代表安全。下一步是用設備端的完整套件版本及供應商公告核對，而不是單靠字串排序做結論。

6｜完整合成案例：把推測變成可追查紀錄

假設你受託盤點隔離教學環境中的 TCP 8080。以下全部是教學資料：

觀察一：8080/tcp open
觀察二：HTTP 回應含 Server: ExampleWeb/1.2
觀察三：架構文件顯示前方有反向代理
管理端資料：後端套件為 example-app 4.0-vendor3
修補狀態：尚待核對供應商公告與安裝紀錄

比較兩種紀錄方式：

- 跳太快：「後端使用 ExampleWeb 1.2，而且有漏洞。」這把前端回應、後端產品與漏洞三件事混在一起。

- 可查核：「在指定測試位置與時間，TCP 8080 接受連線；HTTP 回應自述 ExampleWeb/1.2。架構文件顯示有反向代理，這個字串尚不能用來確認後端版本。管理端列出 example-app 4.0-vendor3；下一步核對執行中服務與套件、供應商修補公告及設定。」

這裡也承接 M03 的章後重點：Port State（連接埠狀態）是觀測結果，不是入侵結果。`open`、可讀取 Banner、成功辨認產品，都不等於已取得登入權限或證明能利用弱點。

7｜管理者如何防護，又如何留下驗收證據？

服務識別資訊的管理，應和實際維護一起做：

隱藏 Banner 是資訊揭露管理，不是修補的替代品。另外，更新套件後仍應確認執行中的程序是否已使用新版本；只看到磁碟上有新套件，還不足以確認服務已重新載入。

一筆有用的辨識紀錄，至少包括：授權範圍、目標與傳輸協定／連接埠、來源位置、使用的主機名稱、時間與時區、工具版本及參數、原始回應、觀察到的產品字串、可支持的推論、內部核對資料，以及待確認事項。分享時移除帳密、工作階段資訊與不必要的個資。

8｜今天的安全練習與小檢核

今天不需要對任何主機發送封包。用第 6 節的合成資料，自己寫三行：

1. 觀察：我實際取得了哪些回應或文件？

2. 推論：這些線索目前支持什麼？

3. 待確認：還需要哪份管理端資料，才能完成版本與修補查核？

再試著回答四題：

1. 掃描結果出現 `443/tcp open https`，在不知道服務名稱來源時，為什麼不能直接填上網頁伺服器產品與版本？

2. Nmap 建立 TCP 連線後，只等待服務開場訊息，為什麼仍不是完全不接觸目標的被動蒐集？

3. 外部回應寫 `ExampleWeb/1.2`，但前方有反向代理、供應商又可能回補修正。確認後端是否受某弱點影響時，你至少要補哪三類證據？

4. 管理者把版本 Banner 隱藏後，可以把「弱點已修復」標成完成嗎？應該如何分開驗收？

今天帶走的觀念：入口號碼 → 回應線索 → 內部核對 → 修補判定。每一步都保留證據與限制，就能把服務辨識用在真正的盤點與防護上。

來源與查核範圍

本單元沿用指定主稿的 M03-05「Service Version & Banner Grabbing」與 M03 章後觀測結果原則；技術補充查核日期：2026-11-03。官方文件是持續更新頁面，未以網頁內容冒稱特定已安裝工具版本。

- Nmap：服務與版本辨識

- Nmap：版本辨識技術與探測流程

- Nmap：探測資料庫與 softmatch

- Nmap：作業系統辨識

- RFC 9110：HTTP Server 欄位（2022，§10.2.4）

- Red Hat：安全修正的 Backport 政策

參考答案會隨網站教材發布，正式頁核驗後再提供解答網址；這裡先保留題目供你練習。公布答案不代表你已作答或學會。

參考解答：1. 入口編號與服務身分

`open` 描述這次測試取得的連接埠狀態。`https` 可能只是依埠號對照的常見名稱，也可能來自額外的服務辨識；先查明產生方式。即使取得與 HTTPS 相符的回應，也要進一步核對產品、完整版本及部署位置。比較穩妥的記錄是保留原始輸出與探測方法，將尚未驗證的產品、版本列為待確認。

參考解答：2. 已建立連線就已接觸目標

TCP 連線建立會與目標交換網路封包，服務也可能留下連線紀錄。NULL probe 的「空」是尚未先送應用層探測內容，不是完全沒有互動。因此仍需取得授權並考慮服務影響；分析已合法取得的既有流量、沒有發出新連線，才是另一種被動觀察方式。

參考解答：3. 補齊後端與修補證據

至少取得三類資料：第一，代理與後端的架構及回應產生位置，釐清字串在描述誰；第二，後端實際執行的程式、完整套件版本與供應商修訂號；第三，供應商安全公告、回補與安裝紀錄，以及弱點適用的設定條件。必要時確認服務已重新載入修補版本。把外部回應和內部證據分開記錄，再判斷是否受影響。

參考解答：4. 分開驗收資訊揭露與修補

隱藏版本可以標記為「已減少版本資訊揭露」，前提是調整後的實際回應已驗證。但「弱點已修復」需要另一組證據：套件與公告對照、修補安裝結果、執行中版本與必要設定檢查，並於授權範圍內完成相應驗證。兩項工作可以一起安排，不能互相代替。