M03-08 · IDS／防火牆影響與掃描防護

CEH v13｜M03-08：IDS／防火牆影響與掃描防護

完整白話文教學：如何判斷網路攻擊是否真的被擋下？

本章最重要的觀念：掃描不到服務、偵測到可疑行為，以及成功阻擋攻擊，是三件不同的事情。

想像你是醫院的資安工程師。有一天，主管問你：

我們昨天進行了滲透測試，Nmap 顯示連接埠被過濾，而且 IDS 也發出了警報。這是不是代表我們的防火牆成功阻擋了攻擊？

你不能直接回答「是」。

因為你還不知道：

1. Nmap 沒收到回應，是防火牆阻擋，還是網路發生問題？

2. IDS 雖然發出警報，但它有沒有能力阻擋封包？

3. 防火牆是否真的執行了阻擋動作？

4. 攻擊流量有沒有抵達真正的伺服器？

5. 這次測試成功，是否代表其他來源與服務也安全？

這就是 M03-08 要教你的核心能力：從網路封包、掃描結果與資安設備紀錄，建立有證據支持的安全判斷。

一、先記住今天的結論

1.1 資安工程師必須區分三件事情

先想像你正在檢查一台醫院的伺服器。

伺服器位址是：

`192.0.2.10`（文件示範用 IP）

它提供一項 HTTPS 測試服務，使用 TCP Port 8443。

你使用 Nmap 掃描後，得到：

PORT      STATE       SERVICE
8443/tcp  filtered    https-alt

接著，IDS 顯示：

Alert: Possible Port Scan

這兩項證據代表什麼？

第一件事：掃描結果（Scan Result）

Nmap 告訴你：

我嘗試確認這個連接埠的狀態，但沒有取得足夠的回應，因此無法判定它究竟有沒有開啟。

這就是 `filtered`。

它是掃描器的觀察結果，不是防火牆實際執行了哪項動作的證明。

第二件事：偵測結果（Detection Result）

IDS 告訴你：

我觀察到一項符合可疑掃描特徵的活動，已經產生告警。

但這不代表流量被阻擋。

IDS 可以像監視器一樣，把事件記錄下來，卻不一定能介入連線。

第三件事：防護結果（Prevention Result）

如果你進一步查到：

Firewall Log:
Source: 198.51.100.25
Destination: 192.0.2.10
Port: 8443
Action: DROP
Rule: FW-17

這才是防火牆有執行阻擋動作的直接紀錄。

不過，仍要確認這筆紀錄確實對應到本次測試，並檢查實際封包路徑及服務端紀錄。

三種證據的差異

關鍵觀念：看見什麼，就先記錄什麼；不能把尚未證實的推論寫成事實。

二、從大樓的門禁、監視器與保全理解

這一節要了解三項非常重要的技術：

• Firewall：防火牆
• IDS：Intrusion Detection System，入侵偵測系統
• IPS：Intrusion Prevention System，入侵防禦系統

2.1 Firewall：防火牆就是大樓的門禁系統

想像你管理一棟研究大樓。

大樓內有三個區域：

• 一樓：一般民眾可以進入。
• 二樓：只有研究人員可以進入。
• 三樓：只有系統管理員可以進入。

你會怎麼控制？

最簡單的做法，就是在入口設置門禁。

網路防火牆也是類似的概念。

它可以依據不同條件，決定哪些網路流量可以通過。

例如：

這張表代表一套網路存取政策。

防火牆在收到封包時，會依照設定的規則，決定是否放行。

防火牆可以檢查什麼？

常見條件包括：

① Source IP（來源 IP）

封包是誰送過來的？

② Destination IP（目的 IP）

封包打算送去哪裡？

③ Protocol（通訊協定）

封包使用 TCP、UDP，還是其他協定？

④ Port（連接埠）

它要連到伺服器的哪一項服務？

⑤ Connection State（連線狀態）

這個封包是否屬於已建立或符合政策的連線？

部分新一代防火牆（NGFW）還能檢查應用程式、使用者身分及其他特徵，但實際能力取決於產品、部署及加密流量的可見性。

因此，防火牆不只是「阻擋 IP 的工具」，而是一個執行網路存取政策的控制點。

2.2 IDS：入侵偵測系統就是監視器

假設有人反覆嘗試進入大樓的不同樓層。

監視器可以觀察這個人：

• 一分鐘內嘗試了很多扇門。
• 不斷更換要進入的區域。
• 在不尋常的時間出現。
• 行為符合事先設定的異常條件。

監視系統於是發出警報。

網路 IDS 的原理很相似。

它會觀察自己能取得的網路流量，檢查是否出現值得注意的活動。

例如：

10:00:01  TCP connection attempt → Port 21
10:00:02  TCP connection attempt → Port 22
10:00:03  TCP connection attempt → Port 80
10:00:04  TCP connection attempt → Port 443
10:00:05  TCP connection attempt → Port 3389

IDS 可能判斷：

短時間內出現多個不同連接埠的連線嘗試，符合某項掃描偵測規則。

於是產生告警：

[ALERT]
Category: Potential Network Scan
Source: 198.51.100.25
Destination: 192.0.2.10

但是要注意：

IDS 的主要工作是偵測與通報，不一定具有直接阻擋這些封包的能力。

如果 IDS 透過交換器的流量鏡像（Port Mirroring / SPAN）取得封包副本，它可能看見流量，卻不位於真正的封包傳輸路徑上。

換句話說：

監視器拍到有人闖入，不代表監視器本身有把人攔下來。

有些 IDS 會整合其他設備，透過自動化機制觸發阻擋，但那是額外的回應機制，不能因為看見 IDS 告警就假設已發生。

2.3 IPS：入侵防禦系統就是能實際攔截的保全

現在假設大樓不只有監視器，還有保全人員。

保全發現有人違反存取政策時，可以直接阻止通行。

這就接近 IPS 的概念。

IPS 能根據偵測結果與既定規則，採取防護動作。

例如：

Source: 198.51.100.25
Destination: 192.0.2.10
Detected: Policy violation
Action: DROP

代表它可能在封包抵達目的地之前，直接丟棄封包。

但是這裡有個非常重要的網路架構觀念：

IPS 為什麼通常需要部署在流量路徑上？

你可以想像兩種架構。

架構 A：被動式 IDS

外部電腦
    │
    ▼
  防火牆
    │
    ▼
  交換器 ─────► IDS
    │         （收到流量副本）
    ▼
  伺服器

這裡的 IDS 透過鏡像接收資料。

它可以分析流量，但封包並不需要經過 IDS 才能抵達伺服器。

架構 B：串接式 IPS

外部電腦
    │
    ▼
  防火牆
    │
    ▼
   IPS
    │
    ├── 符合允許條件 → 放行
    │
    └── 符合阻擋條件 → 丟棄
    │
    ▼
  伺服器

IPS 位於實際流量路徑上，可以在封包通過時執行防護。

這種方式稱為 Inline（串接式部署）。

不過，現代防火牆可能直接整合 IPS 功能，因此不一定存在兩台獨立設備。

小結：三者最重要的差異

要判斷防護是否成功，不能只看設備名稱，還必須看設備的位置、運作模式與實際動作。

這也符合 NIST 對防火牆及入侵偵測與防禦系統的基本區分。NIST Computer Security Resource Center

三、防火牆如何改變你看到的入口狀態

這一節要與之前學習的 M03-03「TCP Connect、SYN 掃描」以及 M03-07「Nmap」連在一起理解。

3.1 先回憶 TCP 三向交握

假設你的電腦想連線到一台 Web Server。

正常 TCP 連線建立過程是：

你的電腦                    Web Server
    │                           │
    │ ─────── SYN ────────────► │
    │                           │
    │ ◄───── SYN-ACK ────────── │
    │                           │
    │ ─────── ACK ────────────► │
    │                           │
    │       連線建立完成         │

白話文就是：

1. SYN：我想和你建立連線。

2. SYN-ACK：我收到了，我也同意開始建立連線。

3. ACK：收到你的確認。

但如果中間有防火牆，事情就會有所不同。

3.2 Allow：防火牆允許流量通過

假設你要連線到 TCP Port 443。

防火牆規則允許這段流量：

你的電腦
   │
   │ SYN
   ▼
[Firewall]
   │
   │ Allow
   ▼
[Web Server]
   │
   │ SYN-ACK
   ▼
你的電腦

如果是 SYN 掃描，掃描器收到有效的 SYN-ACK，通常就能判定：

443/tcp open

不過，`open` 不等於你已經登入系統，也不等於服務存在已知漏洞。

它只代表這次掃描得到足以支持連接埠開啟狀態的回應。

3.3 Drop：防火牆直接丟棄封包

現在把防火牆政策改成：

Source: External Network
Destination Port: 443
Action: DROP

封包傳輸過程可能變成：

你的電腦
   │
   │ SYN
   ▼
[Firewall]
   │
   ✕ 直接丟棄
   │
   ▼
[Web Server]
  沒收到 SYN

從你的電腦角度來看：

你送出了 SYN，但是一直沒有收到預期的回覆。

於是掃描器等待一段時間，必要時重新嘗試。

最後可能得到：

443/tcp filtered

但這裡有個容易考錯的地方。

沒有回覆，不代表一定是防火牆丟棄。

其他可能性包括：

• 網路發生封包遺失。
• 路由發生問題。
• 回傳封包被其他設備阻擋。
• 目標或中間設備沒有正常回應。

因此，Nmap 的 `filtered` 只能作為觀察結果，不能單獨確認阻擋原因。

3.4 Reject：防火牆主動拒絕並回覆

Reject 和 Drop 有什麼差別？

你可以把它想成：

Drop：不理你。

有人敲門，門禁直接不回應。

Reject：明確告訴你不能進來。

有人敲門，門禁回答：「拒絕進入。」

在網路上，Reject 可能透過 TCP RST 或 ICMP 錯誤訊息回覆。

例如：

你的電腦
   │
   │ SYN
   ▼
[Firewall]
   │
   │ REJECT
   │
   └────────► TCP RST

如果掃描器收到 TCP RST，在典型 SYN 掃描中可能判定：

443/tcp closed

但如果收到的是代表管理政策禁止通訊的 ICMP 訊息，則可能判定為：

443/tcp filtered

這取決於掃描方式與實際收到的訊息。

所以千萬不要把它簡化成：

Drop 就是 filtered；Reject 就是 closed。

這個說法並不完全正確。

Nmap 狀態判讀整理

這六種是 Nmap 官方定義的狀態。它們描述的是掃描器從特定觀測位置看到的狀態，而不是服務永遠不變的客觀屬性。nmap.org

為什麼內網顯示 open，外網顯示 filtered？

假設你在實驗室有一台 NAS。

同一個服務：

NAS：192.168.1.100
Port：443

從實驗室內網存取：

實驗室電腦
    │
    ▼
內網交換器
    │
    ▼
NAS:443
    │
    └── SYN-ACK

結果：open

從外部網路存取：

外部電腦
    │
    ▼
邊界防火牆
    │
    └── DROP
         │
         ✕
        NAS

結果：filtered

兩個結果完全可能同時正確。

因為兩部電腦經過不同的網路路徑，適用不同的防火牆政策。

這也是為什麼在滲透測試報告中，除了 Port 狀態，還要記錄來源位置、時間及掃描方法。

本節最重要的一句話：掃描結果具有觀測位置與測試條件的限制。

四、偵測到、發出告警、阻擋成功，分別怎麼確認？

這一節是整章最重要的技術部分。

我們已經知道 Firewall、IDS 與 IPS 的功能不同。

現在要進一步理解：

IDS／IPS 究竟如何判斷一個封包有問題？又如何決定要不要阻擋？

4.1 Signature：特徵式偵測

Signature 可以翻譯為「特徵規則」。

想像你是刑事偵查人員，現在要辨識一種已知的犯罪手法。

你可能建立一套判斷條件：

如果出現某些已知行為特徵，就標記為需要調查的事件。

IDS 也可以這樣運作。

例如，系統設定一條規則：

假設性偵測條件：

來源 IP：同一個來源
目的地：同一台伺服器
觀察時間：短時間內
行為：嘗試連接多個不同 Port

符合條件：
產生「疑似 Port Scan」告警

這就是特徵式偵測的基本概念。

它不一定需要知道攻擊者是誰，只需要判斷觀察到的行為是否符合規則。

但缺點是：

如果新的攻擊方法不符合既有規則，就可能無法被偵測。

此外，正常管理活動也可能符合規則。

例如，資安人員進行合法 Nmap 掃描，依然可能被 IDS 判定為疑似掃描行為。

因此，偵測規則命中，不代表發現了真正的惡意攻擊者。

4.2 Anomaly：異常式偵測

另一種方法是 Anomaly Detection（異常偵測）。

我們用醫院的網路系統舉例。

假設某台醫療設備平常的通訊模式是：

08:00 → 連線到院內 API
08:05 → 上傳一筆資料
08:10 → 上傳一筆資料
08:15 → 上傳一筆資料

系統已經知道這是正常行為。

但突然有一天：

03:00 → 連線到陌生外部 IP
03:01 → 嘗試連接 100 個不同 Port
03:02 → 大量傳送資料

異常偵測系統可能判斷：

這和過去觀察到的正常模式差異很大，值得進一步調查。

它不一定需要事先知道這是哪一種攻擊。

不過，異常不等於惡意。

例如醫院正在進行系統升級、設備維護或資料遷移，也可能產生不尋常流量。

Signature 與 Anomaly 比較

實際產品可能結合多種偵測方法，而不是只能選一種。

4.3 False Positive 與 False Negative

這裡要學會兩個資安領域的重要概念。

False Positive：誤報

實際上是正常活動，系統卻判斷為異常。

例如：

真實情況：
資安人員正在進行授權掃描

IDS 判斷：
疑似惡意 Port Scan

結果：
False Positive

前提是我們已經確認這項行為屬於合法、預期且不需要依該規則處置的活動。

False Negative：漏報

實際上存在應該被偵測的異常，系統卻沒有發出告警。

例如：

真實情況：
存在符合偵測目標的惡意活動

IDS 判斷：
未發現異常

結果：
False Negative

不過，這兩種分類都需要有可信的真實標記（Ground Truth）。不能因為沒有告警，就直接認定發生了漏報；必須先確認確實存在應被偵測的事件。

在實際資安工作中，這與 AI 模型的分類問題相似：

• False Positive：增加調查成本，可能干擾正常工作。
• False Negative：可能讓真正的威脅未被發現。

4.4 Suricata：如何決定告警或阻擋？

Suricata 是一套開源網路威脅偵測與防禦引擎。

它可以透過規則（Rules），分析網路流量。

以 Suricata 的規則語法來說，規則通常具有三個主要部分：

Action + Header + Rule Options

白話文：

要做什麼？
    +
檢查哪一類流量？
    +
什麼條件下算符合規則？

其中最重要的是 Action。

但有個非常重要的限制：

寫了 `drop` 規則，不等於設備一定已經實際阻擋流量。

如果 Suricata 只是以被動 IDS 模式監看封包，沒有部署在可執行阻擋的位置，實際行為就可能不同。

而且，Suricata 的告警限制、規則門檻與動作之間存在不同的交互關係。

例如某些設定只限制告警次數，卻仍繼續執行阻擋；其他門檻設定則可能影響動作何時開始生效。

因此不能從「只看見一則告警」推論「只處理了一個封包」。

這些差異可以在 Suricata 官方的規則文件中確認。教材引用的是 9.0.0-dev 開發版文件；實務上必須以現場安裝版本為準。docs.suricata.io

圖解：Firewall、IPS、IDS 的實際角色

注意圖中的兩條路徑：

藍色箭頭： 實際封包傳送路徑。

綠色虛線： IDS 收到的鏡像封包。

如果 IPS 丟棄了某個封包，伺服器可能不會收到；至於 IDS 能不能看到該封包，還要看鏡像點在哪裡。

五、沒有告警時，先找可見範圍與紀錄缺口

5.1 為什麼「沒有警報」不代表「沒有攻擊」？

假設你在醫院建立了 IDS。

管理員每天登入監控介面，看見：

Security Alerts: 0

這代表醫院今天沒有受到任何網路攻擊嗎？

不代表。

因為 IDS 必須真的觀察到相關活動，才有機會分析與告警。

我們可以把偵測流程拆成四個階段：

網路流量
    │
    ▼
① 感測器是否看得到？
    │
    ▼
② 偵測引擎是否正常分析？
    │
    ▼
③ 規則是否符合並產生事件？
    │
    ▼
④ 告警是否成功傳送與顯示？
    │
    ▼
管理員看到警報

只要中間任何一個環節出現問題，管理員就可能看不到警報。

這裡可以延伸成四種問題。

問題 A：流量根本沒有經過感測器

例如：

                ┌────► IDS
交換器 ──────────┤
                └────► Server A

另一條網路路徑 ─────────► Server B
                           （IDS 看不到）

如果攻擊流量走向 Server B，而 IDS 只能監看 Server A 的流量：

IDS 就不會因為沒看見的封包而產生對應的偵測結果。

這就是 Visibility（可見範圍）的問題。

問題 B：感測器有收到流量，但資料不完整

例如網路設備負載過高，鏡像流量發生遺失。

原本傳送了 1,000 個封包，但 IDS 只觀察到其中一部分。

那麼 IDS 做出的判斷，自然可能不完整。

因此，除了告警數量，還應該關注感測器健康狀態、封包遺失及資料收集情況。

問題 C：流量被加密

假設使用 HTTPS。

Client
   │
   │ HTTPS / TLS
   ▼
Firewall
   │
   ▼
IDS
   │
   ▼
Web Server

如果 IDS 沒有取得明文資料的能力，就無法直接閱讀加密的應用程式內容。

不過，它仍可能觀察到部分網路中繼資料，例如 IP、Port、封包大小、時間特徵，以及依協定和設定可見的部分握手資訊。

所以：

加密不等於 IDS 完全看不到流量，而是限制它能看見哪些內容。

問題 D：IDS 已經偵測到，但警報沒有顯示

假設：

Suricata
   │
   ▼
Log Collector
   │
   ▼
SIEM
   │
   ▼
Security Dashboard

SIEM 是 Security Information and Event Management，安全資訊與事件管理系統。

它負責集中、關聯與分析各種安全紀錄。

如果 Suricata 產生事件，但日誌收集系統發生問題：

管理員仍可能在 SIEM 看不到警報。

這不一定代表 IDS 沒有偵測到。

實務上怎麼檢查？

建議按照以下順序：

這也是實際部署 SOC（Security Operations Center，資安監控中心）時，非常重要的工作。

因為 SOC 的價值不只是有多少告警，而是能不能可靠地發現、理解與處理真正需要關注的事件。

六、完整例子：同一台測試服務，兩種來源

這一節將前面學到的知識整合起來。

我們用教材中的人工設計情境，模擬一次資安驗證。

6.1 情境設定

假設醫院內有一台測試伺服器：

Server: 192.0.2.10
Service: HTTPS
Port: TCP 8443

系統管理員設定：

管理網段允許連線，外部測試網段不允許連線。

現在有兩台電腦：

我們的工作不是攻擊這台伺服器，而是驗證：

網路存取政策是否真的按照預期運作？

6.2 第一次測試：管理網段 A

時間：09:00。

A 對 TCP 8443 進行經授權的連線測試。

掃描結果：

8443/tcp open

接著檢查伺服器紀錄：

09:00
Connection from A
Destination Port: 8443

兩項證據可以相互支持：

• A 的掃描結果顯示 open。
• 伺服器紀錄顯示來自 A 的對應連線。

這符合預期的允許政策。

但仍應確認應用程式是否能正常提供服務。因為 Port open，不代表使用者一定能完成登入或正常執行業務。

6.3 第二次測試：外部網段 B

時間：09:02。

B 對同一個服務進行測試。

掃描結果：

8443/tcp filtered

如果你只看到這一行：

還不能判斷為什麼 B 無法取得預期回應。

接下來檢查防火牆紀錄：

09:02
Source: B
Destination: Server
Protocol: TCP
Port: 8443

Rule: FW-17
Action: DROP

再檢查 IDS：

09:02
Signature: Possible Port Scan
Action: ALERT

最後查看伺服器紀錄：

09:02
No matching connection from B

現在我們有四組不同來源的證據。

如果能確認這些紀錄的時間、來源、目的地、Port 與封包路徑相互對應，就可以形成比較可靠的推論。

這次測試的 B 流量受到 FW-17 阻擋，與預期政策一致。

注意，我們沒有說 IDS 阻擋了攻擊。

因為 IDS 的 Action 是 `alert`。

也沒有宣稱整台伺服器安全。

因為我們只驗證了特定來源、時間與服務。

6.4 為什麼還需要確認 NAT 和時間？

這裡要補充兩項實務技術。

NAT：Network Address Translation

NAT 是網路位址轉換。

假設 B 原本的來源 IP 是：

198.51.100.25

經過 NAT 設備後，防火牆看到的來源可能變成：

203.0.113.50

如果你只用原始 IP 搜尋防火牆紀錄，就可能找不到對應事件。

因此，要先弄清楚：

原始來源 IP
    │
    ▼
NAT
    │
    ▼
轉換後 IP
    │
    ▼
Firewall Log

這也是為什麼網路調查不能只根據單一 IP 進行比對。

時間同步

假設掃描器的時間是：

09:02:00

但防火牆時間是：

09:07:00

如果兩台設備沒有正確校時，你可能誤以為這些事件不相關。

因此，需要確認時區、NTP 校時及可能的時間誤差。

圖解：掃描結果與資安紀錄如何交叉驗證

這張圖的核心是：

先觀察，再交叉驗證，最後只做證據能支持的結論。

這樣的工作方法不只適用 CEH，也適用於滲透測試報告、資安事件調查、系統稽核，以及網路數位鑑識。

七、防護工作的重點：降低暴露、保留偵測、驗證效果

這一節要開始從「掃描工具使用者」轉換成「資安架構設計者」的思維。

前面我們學會如何判斷網路流量被阻擋的證據。

但更重要的問題是：

如果你負責醫院、企業或實驗室的網路安全，究竟應該如何設計防護措施？

7.1 第一層：降低攻擊面（Attack Surface Reduction）

假設你負責管理實驗室的三台 NAS。

這三台 NAS 提供：

• 檔案共享服務
• HTTPS 管理介面
• SSH 遠端管理
• 資料備份服務

如果你直接把所有服務都開放到網際網路：

Internet
    │
    ├── NAS 1：443、22、445
    │
    ├── NAS 2：443、22、445
    │
    └── NAS 3：443、22、445

外部使用者就可能從網路上接觸這些服務。

即使你有 IDS，仍然存在暴露風險。

比較合理的做法是：

先確認哪些服務真的需要對外開放。

例如：

Internet
    │
    ▼
身分驗證與存取控制
    │
    ▼
Firewall
    │
    ├── 已授權管理員 → NAS 1
    │
    ├── 已授權研究人員 → NAS 2
    │
    └── 已授權備份服務 → NAS 3

這裡最重要的是：

不要單純依賴 IDS 發現攻擊，而是從架構上減少未授權使用者接觸系統的機會。

不過，身分驗證入口本身也要設計成最小權限。不能因為某人通過第一道登入，就讓他同時取得所有 NAS 的管理權限。

這與 Cloudflare Access、Zero Trust（零信任）和網路分段的存取控制觀念有關。

7.2 第二層：保留偵測能力

降低暴露後，還需要監測。

假設你設定了一套防火牆：

外部來源 → NAS 管理介面 → DROP

但如果防火牆規則意外改變了，你希望能及早知道。

因此需要：

• 保留防火牆事件紀錄。
• 監測重要的連線與服務活動。
• 確認 IDS／IPS 正常運作。
• 對重要設定變更建立稽核紀錄。
• 確認告警真的能送到管理員使用的監控系統。

需要注意，並不是每個被拒絕的封包都必須產生即時警報。

大量低價值告警可能造成 Alert Fatigue（告警疲勞），讓管理員忽略真正重要的事件。

比較好的方式是依據風險，決定哪些事件要保留、彙整、關聯分析或立即通報。

7.3 第三層：驗證防護措施真的有效

這是本章最重要的工程實務。

我們不能只完成防火牆設定，就宣稱系統安全。

需要進行有授權、有預期結果的驗證。

假設你的目標是：

只允許管理網段連入 NAS 的 TCP 8443，其他來源都不能直接連入。

你可以建立一份驗證矩陣。

這四個測試各自回答不同問題。

T1 驗證合法管理流量有沒有被錯誤阻擋。

T2 驗證未授權流量是否被限制。

T3 驗證資安控制是否破壞正常業務。

T4 驗證監控系統是否有能力觀察到指定的測試活動。

防護有效，不只是惡意或未授權流量進不來，還包括合法使用者能正常工作。

測試前要有明確的計畫

一份基本驗證計畫至少需要：

另外，不要為了方便測試而關閉 IDS／IPS，然後用關閉防護後的結果證明防護有效。

如果要比較開啟與關閉防護的差異，必須在核准且受控的環境中分別測試，並清楚標記各自的測試條件。

7.4 如何寫出專業的驗證結論？

假設我們完成了第六節的測試。

不好的結論：

防火牆成功阻擋攻擊，系統安全。

問題是：

這個結論的範圍太大，證據不足以支持。

比較專業的結論是：

在核准的測試時間內，使用指定外部測試來源 B，對測試伺服器 TCP 8443 進行連線驗證。掃描結果顯示 filtered，防火牆 FW-17 記錄了對應的 DROP 動作，服務端未發現相應連線紀錄。經比對來源、目的地、時間與網路路徑後，證據支持本次測試流量受到預期政策限制。此結果不代表其他服務、來源或時間條件均已驗證。

這種寫法有三個優點：

1. 有明確的測試範圍。

2. 有可以回溯的證據。

3. 沒有超出證據範圍的安全宣稱。

在正式滲透測試報告、醫療資安稽核與事件調查中，這種區分非常重要。

八、安全練習：只讀上面的人工紀錄

這一節的目的，是讓你練習判讀證據，而不是再學一個掃描指令。

不需要安裝工具，也不需要連線任何真實設備。

8.1 練習情境

請重新觀察以下人工紀錄：

[Record 1]

Time: 09:00
Source: A
Destination: Test Server
Port: TCP 8443
Nmap Result: open

[Record 2]

Time: 09:02
Source: B
Destination: Test Server
Port: TCP 8443
Nmap Result: filtered

[Record 3]

Time: 09:02
Firewall Rule: FW-17
Source: B
Destination: Test Server
Port: TCP 8443
Action: DROP

[Record 4]

Time: 09:02
IDS Event: Potential Port Scan
Action: ALERT

[Record 5]

Time: 09:02
Server Log:
No matching connection from B

這些都是練習用的合成紀錄。

8.2 你的第一個任務：區分證據來源

請將五筆紀錄分類：

你需要知道：

「誰產生了這份紀錄」，會影響它能證明的事情。

例如掃描端能描述收到的回覆，但不能單憑輸出證明防火牆內部執行了哪條規則。

8.3 第二個任務：區分事實與推論

請把以下三個問題分開：

問題 A：我們實際觀察到什麼？

只記錄掃描結果和設備紀錄，不加入推測。

問題 B：這些觀察支持什麼解釋？

檢查紀錄是否在時間、來源、目的地及動作上相互吻合。

問題 C：還有哪些事情沒有被證明？

例如：

• 是否涵蓋其他連接埠？
• 其他來源是否適用同樣政策？
• 防護是否在其他時段也有效？
• 日誌是否完整？

這就是「證據、推論、限制」三層結構。

建議使用的紀錄模板

【測試資訊】
測試目的：
授權範圍：
測試時間與時區：
來源：
目標：
Protocol / Port：

【觀察結果】
掃描端：
防火牆：
IDS / IPS：
服務端：

【分析】
已確認的事實：
證據支持的推論：
仍存在的不確定性：

【結論】
本次測試是否符合預期政策：

【後續工作】
還需要補充或核實什麼：

這份模板也能延伸到真實資安事件紀錄與技術報告。

九、小檢核：確認自己是否真正理解

這一節對應教材中的四道檢核題。

請先用自己的話回答，再展開文末的參考解答核對。

題目一：Alert 與阻擋

你使用 Nmap 掃描某個服務，得到：

8443/tcp filtered

同時 IDS 顯示：

Action: ALERT

請回答：

這是否足以證明 IDS 成功阻擋連線？為什麼？如果證據不足，你會再查什麼？

題目二：不同來源，為什麼結果不同？

同一台伺服器的 TCP 443：

電腦 A → open

電腦 B → filtered

請解釋為什麼兩個結果可能同時正確。

題目三：沒有告警代表什麼？

資安主管發現：

IDS Dashboard
Total Alerts: 0

但你不確定監測系統是否正常。

請提出兩個優先檢查的問題，並解釋原因。

題目四：如何設計合理的測試？

某工程師提出：

我們先關閉所有 IPS 防護，再使用 Nmap 掃描。只要沒有發現問題，就可以證明 IPS 設定有效。

這項測試設計有什麼問題？

應該如何改善，才能真正驗證防護能力？

十、Q&A：常見觀念釐清

以下是本章的教學補充問答；與實際學習者提問紀錄分開。

Q1：既然 Firewall 可以阻擋流量，為什麼還需要 IPS？

因為兩者關注的控制條件可能不同。

傳統防火牆主要依據存取政策控制流量，IPS 則能依據威脅特徵與偵測規則，對符合條件的活動採取防護。

例如：

防火牆允許使用者連線到公開網站的 TCP 443。

但流量可能包含符合某項惡意活動特徵的內容。

這時，若 IPS 位於可檢查且阻擋該流量的位置，就可能執行額外的防護。

不過，現代 NGFW 往往已經整合 IPS 功能，因此不一定需要購買兩套獨立設備。

Q2：IPS 阻擋了所有 Port Scan，就代表伺服器安全嗎？

不代表。

即使掃描無法確認某些服務，仍可能存在：

• 已公開且合法開放的服務漏洞。
• Web 應用程式弱點。
• 不當身分驗證或授權。
• 已遭入侵的內部設備。
• 錯誤設定。
• 未涵蓋的網路路徑。

Port Scan 只是資安評估的一部分。

Q3：防火牆記錄 DROP，卻同時有 IDS 告警，合理嗎？

合理，但要看設備位置。

假設架構是：

外部來源
    │
    ├────► IDS（防火牆前的鏡像）
    │
    ▼
Firewall
    │
    └── DROP

IDS 可以在防火牆丟棄封包之前，先觀察到對應的流量副本。

但如果 IDS 只能監看防火牆後方的流量，而防火牆已經丟棄封包，就不能直接假設 IDS 看見的是同一個被丟棄的封包。

它可能看見其他相關封包，或透過其他方式收到事件。

這也是為什麼你必須了解實際網路架構，而不能只看兩套設備的 Dashboard。

Q4：沒有防火牆 DROP 紀錄，就代表封包沒有被阻擋嗎？

也不代表。

有些防火牆可以設定不記錄特定類型的封包。

因此：

沒有找到日誌，與設備沒有執行動作，並不是同一件事。

需要確認日誌政策、實際規則、事件收集狀況及其他可用證據。

十一、將 M03-08 與之前學過的 CEH 知識串起來

最後，我們把這一章放回整個 M03 網路掃描學習架構。

這些技術其實可以整合成一條完整的知識主線：

【理解網路協定】
   IP / TCP / UDP / Port
          │
          ▼
【發現網路設備】
   ICMP / ARP
          │
          ▼
【觀察服務狀態】
   SYN / TCP Connect / UDP
          │
          ▼
【利用工具取得資訊】
   Nmap
          │
          ▼
【解讀網路回覆】
   open / closed / filtered
          │
          ▼
【理解防護機制】
   Firewall / IDS / IPS
          │
          ▼
【交叉核對證據】
   Scanner / Firewall / IDS / Server
          │
          ▼
【形成專業結論】
   觀察 → 推論 → 限制 → 改善

因此，你在 CEH M03 學到的，其實不只是怎麼使用 Nmap。

你正在學習一套完整的網路安全分析方法：

從封包的產生、傳輸與回應，理解系統如何運作，再利用不同來源的證據驗證防護是否有效。

這套方法同樣可以用在企業網路、醫院系統、實驗室 NAS、雲端基礎設施及資安事件調查。

這一章最需要記住的五個英文術語

進一步閱讀：官方技術文件

這幾份資料可以協助你從白話文進一步學習到正式技術規範：

• Nmap — Port Scanning Basics：完整說明六種 Port 狀態。
• Suricata — Rules Format：理解 `alert`、`drop`、`reject` 等規則動作。
• Suricata — Thresholding Keywords：理解告警次數、門檻與實際動作的差異。
• NIST SP 800-41 Rev.1：防火牆與防火牆政策的基本架構。
• NIST SP 800-94：入侵偵測與防禦系統的基礎原理。這是較早期的正式指南，適合作為概念參考，而非最新部署指南。

建議先回答第九節的題目一，再用參考解答核對證據與限制；閱讀或展開答案不代表已完成學習驗收。

下載本版中英 SVG 圖解 ZIP