阿摩線上測驗
13. 關於 MITRE ATT&CK 中的網路服務阻斷（Network Denial of Service）技術（Technique）對策，下列何項錯誤？
(A) 可分析應用程式日誌（Application Log）內容來偵測此技術
(B) 可觀察網路流量（Network Traffic）狀態來偵測此技術
(C) 可觀察感應器健康（Sensor Health）狀態來偵測此技術
(D) 可透過網路流量過濾（Filter Network Traffic）來緩解此技術
答案：登入後查看
統計： A(328), B(22), C(206), D(38), E(0) #3102144
統計： A(328), B(22), C(206), D(38), E(0) #3102144
詳解 (共 3 筆)
hiiii
#6320543
在 MITRE ATT&CK 架構中，「Network Denial of Service（T1498）」主要是針對在網路層所進行的阻斷攻擊。根據官方文件與一般資安實務，偵測與緩解此技術時，通常會著重於「網路層」或「主機層」的行為，例如流量分析、設備/系統資源使用率、連線狀態、以及透過封包或流量過濾來阻擋惡意流量。
以下逐一探討題目所列的對策，並說明哪一項是最不正確（或最不常見、最不適用）的偵測/防禦作法：
(A) 可分析應用程式日誌（Application Log）內容來偵測此技術
- 討論：
- 「網路層阻斷攻擊」(Network DoS) 的重點在於大量惡意流量對網路頻寬或設備資源（例如防火牆、路由器、負載均衡器）造成阻塞、耗盡，使合法流量無法正常到達目的主機。
- 應用程式層級的日誌（例如 web server、應用伺服器的 log）有時也能看到大量無效連線或錯誤（如大量 4xx/5xx 錯誤碼），尤其當攻擊方式同時涉及高階層的資源耗用（屬於 Layer 7 攻擊的一部分）。
- 但若是純粹針對「網路頻寬或封包洪水」（Layer 3/4）的攻擊，應用程式很可能根本收不到那些封包（或只收到極少部分），這些狀況未必都能在應用程式日誌中直接反映。
- 換句話說，純粹用「應用程式日誌」來偵測「網路層」DoS 未必準確，也不是主要手段。 它可以在某些情況下提供線索，但並不是 Network DoS 的主要偵測方法。
(B) 可觀察網路流量（Network Traffic）狀態來偵測此技術
- 討論：
- 監控網路流量（例如使用 NetFlow、sFlow、IDS/IPS 的封包分析）是最直接的方式；大量異常連線、瞬間流量飆高、或同樣來源 IP 的大規模連線，都是常見可疑跡象。
- 對應 MITRE ATT&CK T1498，此為標準作法，可及時偵測到洪水攻擊或其他網路層異常流量。
(C) 可觀察感應器健康（Sensor Health）狀態來偵測此技術
- 討論：
- 這通常是針對 工控系統（ICS）或 OT 環境 的狀況，若網路阻斷造成感應器（Sensor）資料無法及時傳回，或感測器離線（健康度下降），也可能透露出遭到阻斷攻擊的線索。
- 在一般企業 IT 環境，如果有部署「監控網路裝置健康度」或「監控代理程式/感測器」的機制，也可能因為網路不通、設備脫機，而偵測到可疑的連線阻斷。
- 因此，「觀察感應器或監控代理的狀態」在特定情境（尤其 ICS/工控）確實可能是偵測網路阻斷的輔助方式。
(D) 可透過網路流量過濾（Filter Network Traffic）來緩解此技術
- 討論：
- 網路層阻斷攻擊最常見的緩解方式之一，就是在邊界設備進行流量過濾或限制（例如黑洞路由、ACL、DDoS 防護服務、流量清洗），避免惡意大流量直接湧入內部網路或主機。
- 這是業界針對 DoS/DDoS 攻擊最常用的緩解手段，因此完全正確。
哪一項最不適宜？
綜合上面說明：
- (B) 與 (D) 明顯是標準且主要的偵測/防禦方法。
- (C) 在特定環境（尤其 ICS 或需要監控裝置健康度的場合）也確實可行。
- (A) 分析應用程式層的日誌對「網路層阻斷攻擊」的幫助有限，因為若是在網路層就被阻斷了，大量封包可能連應用程式都碰不到；就算有些封包進來，應用程式日誌中只會看到有限的錯誤資訊，通常不是偵測 Network DoS 的關鍵做法。
因此，題目問「哪一項錯誤（或最不適宜）」？
答案是 (A) 解析度相對最低，並非偵測「網路層阻斷攻擊」的主要手段。
0
0
