Section 8: web安全監控

網絡安全基礎知識

為什麼選擇網絡？

從桌面應用到網絡應用的轉變已經持續了幾十年。20世紀90年代，由於速度和網絡連接的限制，桌面應用是主流。隨着網絡技術的進步，21世紀初，動態網絡應用得到了更廣泛的應用，涵蓋了電子郵件、社交媒體和銀行業務等領域。2010年代， 雲計算和軟件即服務（SaaS ）蓬勃發展，如今，幾乎所有事情都可以通過瀏覽器完成。

從安全角度來看

向Web應用程序的轉變帶來了諸多顯著優勢，包括更高的可訪問性、更快的更新速度、更好的兼容性以及更低的用户資源佔用。試想一下，您可以通過瀏覽器瀏覽在線市場和社交網絡、玩遊戲、編輯圖像和視頻，甚至運行虛擬機。然而，這些優勢也帶來了安全方面的權衡。網絡越強大、覆蓋範圍越廣，攻擊者可利用的機會也就越多。

Web應用程序是攻擊者最常利用的入口點之一，因為它們始終可用且暴露在外。它們通常連接到後端系統，例如數據庫和其他基礎設施，這為攻擊者提供了極具破壞性的攻擊機會。一個存在漏洞的Web應用程序通常是更大規模攻擊序列的第一步。讓我們來看看Web應用程序所有者及其用户面臨的風險。

真實案例

2017年，由於Apache漏洞 ，Equifax公司近1.5億美國人的敏感客户數據遭到泄露。攻擊者利用該漏洞，得以訪問存儲寶貴客户數據的內部數據庫。
Capital One在2019年也遭遇過類似規模的數據泄露事件，當時配置錯誤的Web應用程序防火牆（WAF）導致超過1億客户的敏感個人和財務信息泄露。此次配置錯誤使得內部人員能夠訪問公司的雲基礎設施和數據庫。

員能夠訪問公司的雲基礎設施和數據庫。

請回答以下問題。

過去二十年間，應用程序是否從桌面端轉移到了網頁端（yea/nay）？

Yea

誰最終負責確保Web應用程序中用户數據的安全？

Web App Owner

Web 基礎架構

當您訪問網站時，您的瀏覽器會向網絡服務器發送請求。服務器處理該請求，驗證訪問權限，並向用户返回響應。該響應可以是網頁、圖像，也可以是搜索結果或您的帳户信息等數據。這種請求-響應循環是網絡運行的基礎。攻擊者可以通過向服務器發送大量請求、繞過訪問控制，甚至誘騙服務器執行惡意命令來濫用此請求-響應循環。

Web服務的組成部分

例如，任何像tryhackme.com這樣的網絡服務都需要三個主要組件才能運行。

• 應用程序：決定網站外觀和功能的代碼、圖像、樣式和圖標。
• Web服務器：該組件託管應用程序。它監聽請求並向用户返回響應。
• 主機：運行 Web 服務器和應用程序的底層操作系統，  Linux 或 Windows。

接下來，我們將研究可用於保護這三個組件的安全措施。

Web服務器

當您訪問網站時，您的網絡瀏覽器會向網絡服務器發送請求，如上所述。網絡服務器監聽傳入的請求並返回相應的響應。網絡服務器位於網站和應用程序的前端，是互聯網基礎架構的關鍵組成部分。由於它們公開暴露並處理所有傳入的網絡請求，因此網絡服務器也成為攻擊者的常見目標。

以下是一些您最常遇到的網絡服務器。

• Apache：最流行的網絡服務器，用於託管簡單的網站和博客，最常見的是 WordPress。
• Nginx：高性能Web應用程序的行業標準。Netflix、Airbnb和GitHub等公司都在使用 它。
• Internet 信息服務 (IIS)：微軟開發的 Web 服務器，常用於企業環境。

請回答以下問題。

你的網絡瀏覽器向服務器發送什麼信息才能接收網頁？

Request

最常用於託管 WordPress 網站的網絡服務器是什麼？

apache

運行 Web 服務器和應用程序的操作系統和環境叫什麼？

Host Machine

保護網絡

最佳實踐

在保護網站和 Web 應用程序時，可以使用多種安全措施。一些解決方案提供可見性，而另一些則可以主動阻止或限制攻擊，這通常被稱為緩解措施。回顧任務 3，我們討論了任何 Web 服務的三個基本組成部分：應用程序、Web 服務器和主機，現在讓我們來考察每個組件可用的保護措施。

保護應用程序

• 安全編碼：避免使用不安全的函數，確保正確處理錯誤，並刪除敏感信息。
• 輸入驗證與清理：驗證並清理用户輸入，以防止注入攻擊。
• 訪問控制：根據用户角色限制訪問權限。

保護Web服務器

• 日誌記錄：使用訪問日誌詳細記錄所有網絡請求。
• Web應用程序防火牆（WAF）：根據定義的規則過濾和阻止有害流量。
• 內容分發網絡 (CDN)：減少對服務器的直接暴露，並使用集成的 WAF。

保護主機

• 最小權限原則：使用低權限用户來提供服務。
• 系統加固：禁用不必要的服務並關閉未使用的端口。
• 防病毒：添加終端級保護，阻止已知惡意軟件。

所有三個組件的安全提示

• 強身份驗證：不要讓任何人訪問您的代碼、管理面板或主機。
• 補丁管理：確保您的應用程序依賴項、Web 服務器和主機都是最新的。

日誌記錄

Web 服務器可以為收到的每個請求創建日誌。我們稱這些日誌為訪問日誌，它們在安全方面極其重要，因為它們會跟蹤與服務器的每次交互信息，包括客户端的 IP 地址、時間戳、請求的頁面或數據、服務器的響應狀態以及用户代理。這些字段在調查中發揮着重要作用，可以幫助分析人員檢測潛在的惡意活動並追蹤攻擊者的行為。

讓我們來看一系列可能在訪問日誌中出現的正常事件，以便了解我們可以觀察到的數據類型。
請注意，GET請求用於從服務器檢索資源，例如特定的網頁。
POST請求用於向服務器提交數據，例如登錄憑據。

1. 用户通過客户端 IP10.10.10.100訪問網站的主頁/index.html。
2. 接下來，他們導航到登錄頁面 /login.html。
3. 然後他們輸入自己的憑證並提交表格， POST 請求即表示提交成功。
4. 最後，他們通過以下方式訪問他們的帳户頁面 /myaccount.html：

雖然這一系列事件在意料之中，並不異常，但你可以看出這些日誌的詳細程度可以幫助分析人員和事件響應人員重建可能的攻擊序列。

請回答以下問題。

網絡安全中哪個概念是指阻止或限制威脅造成的損害？

Mitigation

哪些安全控制措施包括確保所有軟件和組件都是最新版本？

Patch Management

防禦系統

內容分發網絡（CDN）

CDN將緩存內容存儲在距離用户更近的服務器上，並通過這些服務器提供緩存內容，從而降低延遲。想象一下，您有一個位於中心位置的主服務器。該主服務器向全球各地的邊緣服務器提供信息，以便您的客户能夠更快、更安全地訪問數據。除了速度之外，CDN 還能在安全性方面發揮作用，它充當用户和源服務器之間的緩衝區。

安全福利

• IP地址掩碼：隱藏源服務器IP地址，使攻擊者更難鎖定目標。
• DDoS防護：CDN 可以吸收大量流量，從而降低拒絕服務攻擊的效果。
• 強制使用 HTTPS：大多數 CDN 默認強制使用TLS加密通信。
• 集成式 WAF：許多 CDN，包括 Cloudflare CDN、  Amazon CloudFront 和 Azure Front Door，都集成了 Web 應用程序防火牆。

從本質上講，CDN 使 Web 應用程序能夠更高效、更安全地向客户提供數據。

Web應用程序防火牆（WAF）

WAF（ Web應用防火牆）是一種強大的工具，可以作為網站和Web應用程序的另一層保護。它們會檢查傳入的HTTP流量，並根據安全規則阻止或記錄潛在的有害請求。可以把它想象成酒吧或夜店的保安。每個想要進入的人（Web請求）都必須經過保安（防火牆）的檢查。任何不符合標準要求的人（任何請求）都將被拒絕。

讓我們仔細看看作為防禦者我們可以使用的 WAF 類型，然後深入瞭解它們的功能。

• 基於雲的（反向代理）：位於 Web 服務器前端。這類 WAF 易於部署且具有出色的可擴展性。
• 基於主機：軟件直接部署在 Web 服務器上，併為每個應用程序提供控制。
• 基於網絡的：位於網絡邊界的物理或虛擬設備。更適合企業環境。

功能
如上所述，WAF（Web應用防火牆）會檢查HTTP請求，以檢測異常、攻擊或已知的可疑模式。以下列出了一些常用的方法，以及可能被阻止的請求示例。

上表並不詳盡，因為檢測方法不斷髮展，並且可以根據 Web 應用程序所有者的具體需求創建自定義規則。

下圖是 Cloudflare 控制面板的截圖tryhackme.thm，重點展示了安全面板。圖中顯示了過去 24 小時內的所有請求，包括被集成 Web 應用防火牆攔截的請求。

防病毒軟件（AV）

人們常常誤解殺毒軟件是一種萬能的保護措施，但它們的主要目的是保護終端設備（例如台式機、筆記本電腦和服務器）免受已知惡意文件和程序的侵害。大多數殺毒軟件都依賴於基於特徵碼的檢測，這意味着它們會將文件與已知惡意軟件或模式的數據庫進行比對。

雖然網絡攻擊通常針對應用層而非主機，但正如任務 3 中所述，殺毒軟件在主機保護中仍然發揮着重要作用。它們可以幫助檢測惡意文件上傳，例如 Web Shell、後滲透工具和其他惡意軟件。殺毒軟件只是更廣泛的縱深防禦策略中的一層，應與其他安全措施結合使用，以提供更強大的保護。

請回答以下問題。

哪種類型的Web應用程序防火牆與應用程序本身運行在同一系統上？

Host-Based

哪種常見的WAF檢測技術通過將傳入請求與已知的惡意模式進行匹配來實現？

Signature-Based

檢測網絡攻擊

通過日誌和網絡流量分析，探索網絡攻擊及其檢測方法。

客户端攻擊

客户端攻擊依賴於利用用户行為或用户設備的漏洞。這些攻擊通常會利用瀏覽器漏洞或誘騙用户執行不安全操作，從而獲取賬户訪問權限並竊取敏感信息。由於用户設備上可能存儲着重要數據，因此客户端攻擊一旦成功，就可能導致數據丟失。隨着對動態、多功能 Web 應用程序的需求不斷增長，企業正在集成更多第三方插件，這不僅擴大了瀏覽器的攻擊面，也為客户端攻擊提供了更多機會。

想象一下，你正在瀏覽自己最喜歡的電商網站，點擊了一張感興趣的產品圖片。你渾然不知，攻擊者已在頁面中隱藏了一個惡意窗口，該窗口會在後台加載另一個網站。這個隱藏的網站運行惡意代碼，竊取你的登錄會話 cookie。一切看起來都很正常，但攻擊者現在卻能冒充你並訪問你的賬户！

SOC 侷限性

分析人員可用的工具，例如服務器端日誌和網絡流量捕獲，幾乎無法提供用户瀏覽器內部活動的可見性。如上所述，客户端攻擊發生在用户系統上，這意味着攻擊者可以在不生成安全運營中心 ( SOC)可檢測到的可疑HTTP請求或網絡流量的情況下執行惡意代碼、竊取信息或操縱環境。 因此， 如果沒有額外的瀏覽器端安全控制或端點監控，從SOC 的角度來看，檢測這些攻擊通常很困難，甚至是不可能的。

常見的客户端攻擊

• 跨站腳本攻擊 ( XSS ) 是 最常見的客户端攻擊，攻擊者在受信任的網站上運行惡意腳本，並在用户的瀏覽器中執行。如果您的網站有一個未過濾輸入的評論框，攻擊者可以發佈類似這樣的評論： Hello <script>alert('You have been hacked');</script>。當訪客加載頁面時，腳本會在他們的瀏覽器中運行，並彈出窗口。在實際攻擊中，攻擊者可能竊取 cookie 或會話數據，而不是無害的彈出窗口。
• 跨站請求偽造 ( CSRF )：瀏覽器被誘騙代表受信任的用户發送未經授權的請求。
• 點擊劫持：攻擊者在合法內容上疊加不可見的元素，使用户誤以為自己正在與安全的內容進行交互。

請回答以下問題。

哪一類攻擊依賴於利用用户的行為或設備漏洞？

Client-Side

最常見的客户端攻擊是什麼？

XSS

服務器端攻擊

服務器端 攻擊依賴於利用Web服務器、應用程序代碼或支持網站或Web應用程序的後端系統中的漏洞。客户端攻擊操縱用户與網站的交互，而服務器端攻擊則側重於利用系統本身的漏洞。攻擊者通過利用缺陷和漏洞、服務器邏輯、錯誤配置或輸入處理，可以獲得訪問權限、竊取信息並對正在運行的服務造成損害。

您最常用的網站很可能包含許多允許用户輸入信息的表單。這些表單可能是需要輸入用户名或密碼的登錄表單，也可能是用於搜索歷史訂單或特定產品的搜索表單。試想一下，如果網站處理其中一個表單的輸入時出現錯誤，會造成怎樣的後果？這種漏洞可能使攻擊者能夠訪問存儲在後端數據庫中的敏感客户信息或財務信息。

捕獲服務器端攻擊

對於防禦者而言，應對服務器端攻擊的一大優勢在於，只要知道從哪裏入手，攻擊就會留下痕跡。發送到應用程序的每個 Web 請求都會被服務器處理，並記錄在日誌或其他監控系統中。這些請求也會在網絡中傳輸，這意味着網絡流量可以揭示可疑行為。在接下來的任務中，我們將從日誌和網絡流量兩方面識別服務器端攻擊。

常見的服務器端攻擊

• 暴力破解攻擊是指攻擊者反覆嘗試不同的用户名或密碼，試圖未經授權訪問賬户。攻擊者通常使用自動化工具快速發送這些請求，從而能夠嘗試大量的憑據和常用密碼。  2021年， T-Mobile 遭遇了一起由暴力破解攻擊引發的數據泄露事件，導致超過5000萬T-Mobile用户的個人身份信息（ PII ）被泄露。
• SQL 注入（SQLi）攻擊是指攻擊網站背後的數據庫。當應用程序使用字符串拼接而非參數化查詢來構建查詢時，SQLi漏洞就會發生，攻擊者可以利用該漏洞篡改預期的SQL命令，從而訪問或操縱數據。2023年，MOVEit中的SQLi被利用，影響了超過2700家機構，其中包括美國政府機構、英國廣播公司（BBC）和英國航空公司。
• 命令注入是一種常見的攻擊，當網站未經檢查就將用户輸入傳遞給系統時，攻擊者可以偷偷植入命令，使服務器以與應用程序相同的權限運行這些命令。

請回答以下問題。

哪一類攻擊依賴於利用Web服務器中的漏洞？

Server-Side

哪種服務器端攻擊允許攻擊者濫用表單來轉儲數據庫內容？

SQLi

基於日誌的檢測

日誌是檢測網絡攻擊的有力工具。發送到網絡服務器的每個請求都會在其訪問日誌和錯誤日誌中留下痕跡。防禦者可以通過查看日誌條目來發現掃描、漏洞利用或其他攻擊的模式。在本任務中，您將回顧訪問日誌格式的基礎知識，瞭解各種攻擊如何在網絡服務器訪問日誌中體現，然後在真實的攻擊場景中練習您的技能。
訪問日誌格式
以下是一個訪問日誌示例條目。根據上下文，每個字段都可以指示良性流量或惡意流量。雖然並非所有訪問日誌都遵循此格式，但它們通常包含以下信息：

日誌字段	示例指標
1. 客户端 IP 地址	已知惡意或超出預期地理範圍
2. 時間戳和請求頁面	在不尋常的時間提出的請求或在短時間內重複提出的請求
3. 狀態碼	反覆404出現“找不到頁面”的提示。
4. 響應大小	反應幅度明顯小於或大於正常值
5. 推薦人	不符合常規網站導航的引用頁面
6. 用户代理	過時的瀏覽器版本或常見的攻擊工具（例如sqlmap，wpscan）

日誌中的攻擊

接下來，我們將分析一個簡化的攻擊序列示例。日誌條目序列僅顯示攻擊者的請求；然而，在實際場景中，良性流量會佔據日誌條目的絕大部分，因此，培養敏鋭的洞察力，在正常活動中識別惡意模式至關重要。此外，需要注意的是，在下面的示例中，SQL注入攻擊中的查詢字符串已被記錄，因此您可以查看完整的SQL注入有效載荷。

1. 攻擊者使用目錄模糊測試來檢測潛在的可利用目錄和表單。200響應代碼表示攻擊者已成功找到目標。
2. 接下來，攻擊者利用login.php暴力破解攻擊找到的表單。請注意POST快速連續的重複請求。最後一個POST請求的響應代碼不同，302 Found在本例中，該代碼表示​​登錄嘗試成功。然後，頁面重定向到用户的帳户頁面/account。
3. 攻擊者一旦獲得賬户訪問權限，就會嘗試對錶單進行兩次 SQL 注入攻擊。如果應用程序動態構建 SQL 查詢' OR '1'='1而不是使用參數化查詢，攻擊者就可以轉儲數據庫。1' OR 'a'='a``/search
   

日誌限制

訪問日誌雖然很有用，但它們並非總能完整記錄請求的內容，尤其是請求體 POST 或 GET 請求內容。例如，登錄嘗試在訪問日誌中可能顯示為：

10.10.10.100 [12/Aug/2025:14:32:10] "POST /login HTTP/1.1" 200 532 "/home.html" "Mozilla/5.0"

上述示例日誌顯示了請求方法、請求的頁面和狀態碼，但沒有顯示請求中提交的實際憑據或有效負載。重要的是，訪問日誌不會記錄實際的POST請求體數據（例如提交的憑據），因此調查人員只能看到請求已發生。 GET請求可能會記錄完整路徑和查詢字符串，但某些日誌格式根本不會包含這些信息。這完全取決於所使用的服務器軟件和日誌記錄配置。

調查

小型在線銀行平台TryBankMe遭遇數據泄露。攻擊者入侵了該平台，並在暗網論壇上泄露了敏感的客户數據。管理層認為入侵始於公司公共網站，而找出具體入侵途徑則需要您自行探索。
首先打開access.log桌面上的文件。 
你的任務是分析日誌，並追溯攻擊者的步驟，以揭示此次入侵是如何發生的。祝你好運！

請回答以下問題。

攻擊者在執行目錄模糊測試時的用户代理是什麼？

直接看目錄爆破的時候用的ua是什麼即可

FFUF v2.1.0

攻擊者對哪個頁面進行了暴力破解攻擊？

# 統計一下即可知道
cut -d' ' -f7 access.log | sort -nr | uniq -c
/login.php

攻擊者在表單上使用的完整、解碼後的/changeusername.phpSQLi 有效載荷是什麼？
拿到/account/changeusername.php?q=%25%27+OR+%271%27%3D%271解碼即可

%' OR '1'='1

基於網絡的檢測

網絡流量分析使分析人員能夠檢查客户端和服務器之間交換的原始數據。通過捕獲和檢查數據包，分析人員可以更詳細地觀察攻擊行為，包括底層傳輸協議和應用程序數據本身。網絡捕獲比服務器日誌更詳細，揭示了每個請求和響應背後的數據。例如，這可能包括完整的HTTP標頭、POST 請求體、Cookie 以及上傳和下載的文件。

依賴加密的協議，例如 HTTPS 和SSH，限制了在無法訪問解密密鑰的情況下可以查看的數據包有效載荷內容。在本示例中，我們將重點關注HTTP流量。

網絡流量攻擊

我們先回顧一下上一個任務中的攻擊序列，並比較它在 Wireshark 中的顯示效果。您可以使用多種不同的過濾器來突出顯示您感興趣的字段。下面，我們10.10.20.200使用過濾器篩選了目標 IP 地址和 User-Agent http.user_agent。

回憶一下事件經過。

1. 使用目錄模糊測試查找有效的目錄或表單
2. 暴力破解嘗試，數據包 13 成功登錄
3. SQL注入嘗試

現在我們已經分析了事件順序，接下來讓我們查看數據包詳情，以收集更多攻擊證據。首先，我們來看一下暴力破解嘗試。如果您還記得，日誌顯示我們多次POST請求該login.php表單。現在我們可以看到攻擊者嘗試登錄時使用的實際用户名和密碼。查看最後一次表單請求（數據包 13），我們知道這次請求成功了，可以看到攻擊者找到了有效的密碼password123。這個密碼非常不安全，尤其是對於管理員帳户而言！

接下來，我們來更詳細地分析一下攻擊中的第一次 SQL 注入嘗試。通過檢查 HTTP 數據包，我們可以清楚地看到攻擊者使用的有效載荷以及攻擊結果。在本例中，有效載荷' OR '1'='1允許轉儲 Users 表，並以明文形式向攻擊者顯示用户的 First name 和 Surname！請注意，我們還可以使用 Wireshark 分析 MySQL 協議流量，並顯示有效載荷和返回結果。

調查仍在進行中。

雖然您的日誌分析發現了一些攻擊證據，但您無法確定是哪個用户受到了攻擊，也無法確定實際竊取了哪些數據。幸運的是，我們有攻擊發生時的網絡流量抓包數據。請深入查看traffic.pcap用户桌面上的文件，繼續您的調查。在查看網絡流量時，請牢記您之前調查中的攻擊順序。祝您一切順利！
尖端： 
在 Wireshark 中使用http過濾器，僅查看HTTP流量。
您還可以右鍵單擊任何數據包 → 跟蹤HTTP流，以重建客户端和服務器之間的完整請求和響應。

請回答以下問題。

攻擊者在暴力破解攻擊中成功識別出的密碼是什麼？

因為他輸入完這個密碼後就跳轉頁面了

astrongpassword123

攻擊者利用 SQL 注入在數據庫中找到了什麼 flag？

THM{dumped_the_db}

Web應用程序防火牆

Web 應用防火牆 (WAF) 通常是網站和 Web 應用的第一道防線。到目前為止，我們主要關注的是檢測和分析惡意活動。現在，我們將重點轉向一種最有效的緩解工具。WAF 充當 Web 應用的守門人，它會檢查完整的請求數據包，類似於 Wireshark，但它能夠解密TLS流量並在其到達服務器之前進行過濾。

規則

WAF（Web應用防火牆）會檢查並根據預定義的規則決定是否允許Web請求或完全阻止它。我們來看一下幾種防火牆規則。

假設您注意到重複出現帶有特定 User-Agent 字符串的GET請求。SQLMap是一款用於檢測和利用SQL注入漏洞的自動化工具。在分析網絡流量後，您發現這些請求包含 SQLi 有效載荷。/changeusername``sqlmap/1.9

您可以創建一條規則來阻止任何與 User-Agent 字符串匹配的內容sqlmap：

If User-Agent contains "sqlmap"
then BLOCK

這是一個簡單的例子，現代的Web應用防火牆（WAF）會自動檢測並阻止已知的可疑用户代理。不過，您可以根據具體的應用程序或威脅場景定製此類規則，從而在不影響網站正常流量的情況下阻止惡意活動。

挑戰-應對機制

WAF並非總是需要直接攔截可疑請求。例如，它們可以使用驗證碼（CAPTCHA）來驗證請求是否來自真實用户而非機器人。考慮到惡意機器人流量佔全球網絡流量的37%，這項功能尤為重要。這種方法尤其適用於那些更有可能攔截合法網絡流量的防火牆規則。

整合已知指標和威脅情報

許多現代 Web 應用防火牆 (WAF) 解決方案都內置了旨在緩解OWASP Top 10安全風險的規則集，我們之前已經介紹過其中一些風險。WAF 還利用威脅情報源自動阻止來自已知惡意 IP 地址和可疑用户代理的請求。它們會定期更新以應對新出現的威脅，包括來自已知APT組織的威脅和最近發現的 CVE 漏洞。瞭解一下Cloudflare 如何基於全球威脅情報，維護來自殭屍網絡、VPN、匿名器和惡意軟件等來源的精心整理的 IP 列表。

請回答以下問題。

WAF（網絡接入過濾器）檢測和過濾哪些內容？

Web Requests

創建自定義防火牆規則，阻止任何User-Agent匹配項"BotTHM"。

IF User-Agent CONTAINS "BotTHM" THEN block

檢測 Web Shell

Web Shell 概述

什麼是 Web Shell？

要有效檢測 Web Shell，重要的是要了解它們是什麼，攻擊者如何部署它們，以及它們利用的漏洞。

Web Shell 是一種上傳到目標 Web 服務器的惡意程序，它使攻擊者能夠遠程執行命令。Web Shell 通常既可以作為初始訪問手段（通過文件上傳漏洞），也可以作為持久化機制。

一旦獲得對被入侵服務器的訪問權限，攻擊者就可以使用 web shell 沿着攻擊鏈移動，執行偵察、提升權限、橫向移動和竊取數據。

以下是一個名為 web shell 的簡單示例awebshell.php，它可以通過 Web 界面遠程運行命令。請注意，該 Web shell 位於/uploads目標服務器 10.10.10.100 的目錄中。

Web Shell部署

攻擊者要上傳並執行 Web Shell，需要利用文件上傳漏洞、系統配置錯誤或事先獲得系統訪問權限。當應用程序未能驗證文件類型、擴展名、內容或目標位置時，就會出現這些漏洞。Web Shell 通常用作初始訪問途徑，但如果攻擊者已經攻破系統並希望保持長期訪問權限，它們也可以作為持久化機制。

想象一下，有一個簡單的網站，允許用户上傳寵物照片。該網站旨在存儲圖片。然而，如果開發過程中安全措施不足，攻擊者可能會上傳類似 Web Shellshell.php或Web Shellmydog.aspx的惡意程序，從而獲得對服務器的命令執行權限。

野外實例

Hafnium 和 ProxyLogon
Hafnium是一個總部位於中國的 APT 組織，他們.aspx向 Windows Exchange 服務器上傳了 web shell，這些 web shell 位於諸如 . 之類的目錄中\inetpub\wwwroot\aspnet_client\。他們還被發現修改了.aspx諸如 . 之類的目錄中的現有文件\install_path\FrontEnd\HttpProxy\owa\auth\。

一旦 Web Shell 成功部署，Hafnium 就會繼續執行命令、進行偵察、轉儲憑據、通過新用户帳户進一步建立持久性、橫向移動、竊取數據，並掩蓋其蹤跡以逃避檢測。

Conti勒索軟件攻擊
者利用了Microsoft Exchange中類似的漏洞，將aspnetclient_log.aspx文件上傳到與Hafnium相同的\aspnet_client\目錄。在首次上傳Web Shell後的幾分鐘內，他們又上傳了一個備份Web Shell，並繪製出了網絡中計算機、域控制器和域管理員的分佈圖。

請回答以下問題。

Web Shell 與 MITRE ATT&CK 持久化子技術中的哪一項相關？

T1505.003

針對 Microsoft Exchange 的 Web Shell 通常使用什麼文件擴展名？

.aspx

Web Shell 的結構分析

合法函數濫用：
Web shell 依賴於對程序中合法函數的濫用。PHP
中的系統執行函數，例如 setup()、setup() 、 setup() 和  setup()，可以被濫用以獲取命令執行權限。shell_exec()``exec()``system()``passthru()

幕後揭秘：
這是一個用 PHP 編寫的簡單 Web Shell。讓我們來看看它的功能。

1. 檢查cmdURL 中是否存在該參數。?cmd=whoami
2. 將用户提供的命令存儲在變量中$cmd
3. 使用以下命令執行命令 shell_exec()
4. 顯示輸出
5. 用户界面的HTML代碼
6. 執行命令
7. 輸出

Web shell 的複雜程度和功能各不相同。它們可以是簡單的單行命令程序，通過 URL 執行命令；也可以是功能齊全的界面，具有圖形用户界面 (GUI)、密碼保護和內置文件管理器。

Web Shell 的實際應用

我們已在目標機器上部署了一個 Web Shell http://MACHINE_IP:8080/files/awebshell.php。
您可以通過瀏覽器或命令行直接訪問它，使用命令行工具curl。
如果您通過命令行訪問 Shell，請務必對命令進行 URL 編碼（/awebshell.php?cmd=<encoded_command>）。​​Cyber chef可以提供幫助。
例如： ls -la會變成ls%20-la

請回答以下問題。

進入 shell 並運行 whoami命令確定您有權訪問哪個帳户。

www-data

ls列出目錄內容並使用and命令查找 flag cat。

THM{W3b_Sh3ll_Usag3}

基於日誌的檢測

Web服務器日誌

Web shell 依賴於對 Web 服務器的濫用，因此 Web 服務器日誌自然是我們尋找證據的起點。我們將探討在Apache和 Nginx 等常用 Web 服務器中應該關注哪些方面。瞭解正常行為和可疑行為之間的區別有助於發現惡意活動。

雖然 Web 服務器日誌的格式因服務而異，但訪問日誌通常遵循類似的結構，幷包含以下信息。

遠程日誌名稱字段通常用連字符 (-) 表示，因為它是一個遺留字段，現在很少使用。但是，為了兼容性，它仍然會出現在訪問日誌中。同樣，已驗證用户字段通常也顯示為連字符，除非服務器要求事先進行身份驗證，在這種情況下，它可能包含實際的用户名。

網絡指標

非常規HTTP方法 和 請求模式

• 頻繁的 GET 請求可能意味着攻擊者正在探測上傳 shell 的有效位置。
• 在重複 GET 請求後，向有效的上傳位置發出 POST 請求
• 對同一文件重複發出 GET 或 POST 請求可能表明存在 Web Shell 交互。

需要了解的請求方法。

讓我們利用目前討論過的指標，逐步分析一個潛在的 Web Shell 攻擊序列。
請注意，每個請求都使用相同的客户端 IP 和用户代理。響應代碼和時間戳也需要記錄下來。
200 OK
404 Not Found

可疑的用户代理和 IP 地址
用户代理用於識別向 Web 服務器發出請求的客户端，並提供有關瀏覽器、設備和操作系統的信息。

• 修改後的用户代理：Mozilla/4.0+(+Windows+NT+5.1)縮寫為Mozilla/4.0
• 過時的用户代理：Mozilla/4.0 (compatible; MSIE 6.0)MSIE 6.0 發佈於 2001 年
• 被列入黑名單的用户代理：curl/1.XX.X例如wget/1.XX.X
• 可疑的IP地址：網絡通常只接收內部流量，因此外部IP地址會被視為可疑地址。

查詢字符串
是 URL 的一部分，用於將值與參數關聯起來。`example.php?query=somequery

• 異常長的或可疑的查詢字符串，尤其是包含類似cmd=“或”之類的關鍵字。exec=
• 編碼後的查詢字符串 經過 Base64 編碼後?query=whoami會變成這樣。Cyber ​​chef是一個優秀的工具，可以解碼 Base64 以及許多其他形式的編碼和混淆。?query=d2hvYW1p

缺少引薦來源網址
引薦來源網址顯示用户在鏈接到當前頁面之前訪問的網址。

• 缺少引用頁可能表明存在 Web Shell 活動。
• 來源網址缺失可能存在一些合理原因（例如，瀏覽器出於隱私考慮會屏蔽來源網址，或者直接訪問某個網址）。

包含上述部分特徵的可疑網絡請求示例。

1. 已知的惡意或不受信任的IP地址。
2. 時間戳異常。可能已超出正常工作時間。
3. 向惡意文件發送帶有搜索查詢字符串的 POST 請求。
4. 沒有來源網址。因此，此頁面是直接訪問的。（但這並非總是有效的指示因素）
5. 可疑的用户代理字符串，通常與網絡瀏覽器無關。

審計

這是一個 Linux 原生實用程序，用於跟蹤和記錄事件，從而創建審計跟蹤。可以為其創建規則auditd，以確定哪些內容會被記錄到日誌中audit.log。規則可以高度配置，以匹配特定條件，例如特定程序何時運行或特定目錄中的文件何時被修改。在下面的示例中，ausearch使用 cd 命令搜索與web_shell規則匹配的任何日誌。

Ausearch 在審計日誌中的應用

user@tryhackme$ ausearch -k web_shell
time->Wed Jul 23 06:20:36 2025  // A log matching the web_shell rule
"name = /uploads/webshell.php"
"OGID = www-data"

網絡與審計相關性

有效檢測 Web Shell 需要關聯多個日誌源。將 Web 訪問日誌和錯誤日誌與 auditd 結合使用，可以提供更深入的洞察，並確認文件是否被創建、修改或執行，以及是由哪個用户或進程執行的。WebPOST日誌中的可疑請求可以關聯到包含syscallcreat或execvesyscall 的審計事件，表明某個腳本寫入了文件或運行了命令。結合這些信息，有助於我們更清晰地瞭解攻擊過程。

利用SIEM平台

安全信息和事件管理 ( SIEM ) 平台的一些優勢包括：

• 集中式日誌收集和關聯，這在處理多種不同類型的日誌時尤其有用。
• 可以創建有針對性的查詢來發現惡意活動的跡象，包括 web shell。
• 使分析人員能夠更高效地搜索和分析日誌。

請回答以下問題。

URL 中哪一部分將值與參數關聯起來，並且可以作為 web shell 活動的有效指標？

query strings

auditd 系統調用中，哪個可以確認在向某個服務器發出可疑的 POST 請求後，文件是否已寫入磁盤/upload.php？

creat

超越日誌

文件系統分析

攻擊者的Web Shell必定存儲在某個地方。分析Web服務器文件對於識別已上傳的Web Shell或定位被修改以包含Web Shell有效載荷的文件至關重要。
需要注意的是，某些平台（例如WordPress和Django）將頁面內容存儲在數據庫中，而不是文件系統中，因此惡意代碼可能被注入到文章、主題或設置中，而不會出現在常規的文件系統搜索中。

以下是一些常見的 Web 服務器目錄，Web shell 通常放置在這些目錄中：

• Apache：/var/www/html/大多數Linux發行版的默認服務器
• Nginx：/usr/share/nginx/html/許多Linux系統中的默認配置

即使配置了自定義根路徑，攻擊者仍然可以猜測或掃描常見的上傳目錄，例如 /etc/uploads/、/etc/uploads/ /uploads/或/images/ /etc/ uploads/，/admin/就像我們在任務 3 中看到的那樣。如果文件權限配置不安全，
臨時目錄（例如 /etc/ uploads /tmp /）也可能被濫用。

攻擊者可能利用可疑或隨機的文件名
來逃避檢測。請警惕那些與標準應用程序文件名不同的文件名。

• 監控具有可執行擴展名的文件，例如.php&.jsp
• 警惕使用雙重擴展名來偽裝惡意文件image.jpg.php

您可以使用一些實用命令find來搜索最近修改過的腳本。在下面的示例中，我們使用 --date 選項搜索/var/www目錄中.php在兩個特定日期之間修改過的文件-newerct。另一個實用工具 wp_config.php``grep可以用來追蹤eval(文件中可疑的函數，例如 wp_config.php。在下面的示例中，我們使用它來搜索 WordPress 目錄wp-content。

使用 find 和 grep 命令查找特定文件

user@tryhackme$ find /var/www -type f -name "*.php" -newerct "2025-07-01" ! -newerct "2025-08-01"
/var/www/html/uploads/awebshell.php          // Web shell created between the dates above.

user@tryhackme$ grep -r "eval(" wp-content
/wp-content/uploads/awebshell2.php :eval(b64_dd($['cmd']));  // Web shell containing eval(

網絡流量分析

網絡流量分析使分析人員能夠超越日誌的侷限，通過檢查客户端和服務器之間交換的數據，更深入地瞭解攻擊者的行為。通過檢查數據包有效載荷，可以更詳細地觀察攻擊者的行為。
日誌分析中分析師需要關注的許多指標也可以應用於網絡流量分析。

• 非常規HTTP方法和請求模式
• 可疑的用户代理和 IP 地址
• 編碼有效載荷
• 請求體中的惡意代碼或命令
• 意外的協議或端口
• 意外的資源使用
• Web 服務器進程生成命令行工具

數據包捕獲提供了對確認攻擊至關重要的重要細節。例如，在顯示POST /upload.php請求的 PCAP 文件中，您可能會看到一個PHP Web Shell（webshell.php），其源代碼清晰地顯示在有效載荷中。這種細節有助於進一步驗證攻擊嘗試。
一些有用的 Wireshark HTTP 過濾器。

• http.request.method == “METHOD”
  查找重複或異常的請求可能很有用。
• http.request.uri contains “.php”
  有助於查找可疑或已修改的文件
• http.user_agent 
  用於查找異常或過時的用户代理

Wireshark HTTP過濾器完整列表。
在 Wireshark 中查看與任務 3 相同的攻擊鏈。

Wireshark 中的攻擊序列流程。

Wireshark 中的數據包顯示了指示器和 shell 有效載荷。

請回答以下問題。

你會使用什麼命令來查找 目錄.php中的文件/var/www/？

find /var/www/ -type f -name "*.php"

你會使用哪個 Wireshark 過濾器來專門搜索PUT請求？

http.request.method == "PUT"

調查

調查/var/log/apache2/access.log

查看日誌時，請注意以下事項：

• 重複或可疑的請求（尤其是對.php文件的請求）
• 異常請求模式（查找不同的響應代碼）
• 不尋常的用户代理（例如curl/0.00.0）

這也是使用諸如 grep篩選訪問日誌文件之類的工具的好機會。 
例如，cat /var/log/apache2/access.log | grep "404"它可以幫助突出顯示包含 404錯誤響應的日誌。

請回答以下問題。

攻擊者最有可能使用的IP地址是什麼？

203.0.113.66

攻擊者成功識別的第一個目錄是什麼？

/wordpress

.php攻擊者用來上傳 Web Shell 的文件名是什麼？

upload_form.php

攻擊者使用新上傳的 Web Shell 執行的第一個命令是什麼？

whoami

攻擊者通過 Web Shell 獲取訪問權限後，使用命令將第二個文件下載到服務器上。這個文件的名稱是什麼？

linpeas.sh

攻擊者在 Web Shell 中隱藏了一個秘密。
利用cat此方法分析 Web Shell 代碼並找到 flag。

THM{W3b_Sh3ll_Int3rnals}

檢測 Web DDoS 攻擊

DoS 和 DDoS 攻擊

拒絕服務 ( DoS ) 攻擊的核心在於癱瘓網站或應用程序，使其無法正常使用。一旦發生這種情況，用户將無法登錄、購物或訪問服務，企業也會遭受經濟損失和信任危機。

你是否曾經嘗試訪問自己喜歡的網站，卻發現它一直加載不出來，或者反覆出現驗證碼？該網站可能正遭受拒絕服務攻擊，攻擊者會用大量流量淹沒它，迫使防禦者緊急應對以維持其可用性。

DoS攻擊可以針對系統的不同層級發起。然而，在本次會議中，我們將重點關注OSI模型的應用層（第7層） ，網站和Web應用程序通常是攻擊目標。

拒絕服務（DoS）

任何DoS攻擊，無論規模大小，只要能阻止Web服務按預期運行，都被視為成功。我們先來看看即使是簡單的定向攻擊是如何導致網站無法訪問的。

想象一下，你的網站是一個銷售自行車零件的熱門電商網站，網站上有一個搜索表單。這個表單接收用户輸入，查詢數據庫，並返回匹配結果。如果應用程序未能正確驗證或處理輸入，攻擊者就可以提交意外或格式錯誤的數據，導致應用程序在處理請求時卡頓或崩潰。這樣一來，一個簡單的搜索框就可能被濫用，發起拒絕服務攻擊。如果表單沒有正確過濾或驗證搜索內容，攻擊者還可以向同一個搜索表單發送大量請求，甚至發送一個大規模的單次請求，從而造成拒絕服務攻擊。

分佈式拒絕服務（DDoS）

基本DoS攻擊的侷限性在於它依賴於單台機器和單條互聯網連接。雖然一台計算機可以發出大量請求，但其影響範圍受限於其CPU、內存、帶寬和網絡性能。

為了擴大攻擊規模，攻擊者轉向分佈式拒絕服務 ( DDoS ) 攻擊，並利用殭屍網絡——一支由他們控制的、已被入侵的設備組成的大軍。這些計算機、物聯網設備甚至服務器通常都感染了惡意軟件，並由攻擊者秘密控制。一旦接到指令，這些殭屍網絡就會向目標網站或 Web 應用程序發起大量流量攻擊，其攻擊效率遠超單台機器。

現在想象一下你的自行車零件網站。它很受歡迎，每天流量穩定，但它的設計並非為了承受短時間內數百萬次的請求。攻擊者指示其殭屍網絡攻擊你的網站，突如其來的流量迅速耗盡了你的資源，導致網站癱瘓。

拒絕服務攻擊的類型

讓我們來探討幾種拒絕服務攻擊類型。這些攻擊可以由單個攻擊者發起（DoS 攻擊），也可以通過殭屍網絡進行分佈式拒絕服務攻擊（DDoS 攻擊）。

請回答以下問題。

哪一類攻擊依賴於中斷網絡服務的可用性？

Denial-of-Service

攻擊者利用被入侵的機器網絡發起 DDoS 攻擊，我們該如何稱呼這個網絡？

Botnet

攻擊動機

既然您已經瞭解了攻擊者如何發起DoS和DDoS攻擊，接下來我們來看看他們為什麼要這樣做。乍一看，短暫的網絡服務中斷似乎無關緊要，但對於依賴持續可用性的組織而言，後果可能十分嚴重，導致收入損失、用户不滿以及聲譽受損。

可能的攻擊動機

注：這並非攻擊者動機的完整列表。根據其資源和目標，攻擊者可以同時實現多個目標，也可以追求其他目標。

例子

2015年除夕夜，BBC遭遇DDoS攻擊，導致其網站癱瘓。由於請求超時或返回內部錯誤信息，網站讀者數小時內無法訪問文章。聲稱對此次攻擊負責的黑客組織“新世界黑客”（New World Hacking）表示，他們發動此次DDoS攻擊只是為了測試自身攻擊能力。

2023年，微軟遭遇大規模的七層DDoS攻擊，導致Azure、OneDrive和Outlook服務中斷。黑客組織“匿名者蘇丹”（Anonymous Sudan）聲稱對此次攻擊負責。攻擊者利用HTTP洪水攻擊和Slowloris等技術癱瘓了微軟的Web服務器，給全球微軟用户造成了嚴重影響。

請回答以下問題。

攻擊者的哪種動機旨在使客户對公司失去信心？

# 名譽損失
Reputational Damage

2023 年針對微軟的 DDoS 攻擊最可能的動機是什麼？

# 黑客行動主義
Hacktivism

日誌分析

在調查拒絕服務攻擊時，Web 服務器日誌是重要的證據來源。無論是Apache、NGINX 還是 Microsoft IIS，所有主流 Web 服務都會以某種標準化的日誌格式記錄 Web 請求。通過檢查這些日誌，分析人員和響應人員可以發現有助於區分正常用户流量和惡意活動的模式。本文將探討潛在 DoS和DDoS攻擊的一些關鍵指標，並重點介紹依賴日誌進行檢測的優勢和侷限性。

從之前的任務中，我們知道拒絕服務攻擊通常依賴於向目標發送大量的HTTP請求，但也可以利用專門構造的 Web 請求來停止服務。

請查看以下指標：

分析人員應尋找構成DDoS攻擊圖景的多層次信號。例如，假設攻擊者控制着一個全球殭屍網絡，目標是單個網站。您可能會看到來自不同地理區域的大量IP地址的請求。這些請求可能會使用相同的User-Agent字符串或不同的User-Agent字符串來攻擊多個資源密集型端點，以使其看起來更合法。維護一份常用指標的監控列表，以便隨時關注，對於分析人員來説是一項非常有價值的工具。

目標資源

如果攻擊者意圖破壞我們之前討論過的Web服務，他們很可能會重點攻擊那些每次請求消耗服務器資源最多或對維持網站功能至關重要的端點。像/login搜索表單這樣的頁面是主要目標，因為每次請求都會迫使服務器查詢數據庫、驗證輸入並返回結果。這使得處理這些請求的成本遠高於處理產品頁面或圖片等靜態內容。

常用目標端點及原因：

• /login涉及身份驗證過程
• /search需要複雜的數據庫查詢
• /api端點——動態內容分發的關鍵
• /register或者/signup- 需要數據庫寫入和驗證
• /contact或者/feedback- 需要數據庫條目，並可能觸發電子郵件通知
• /cart或者/checkout——需要會話管理、庫存檢查和支付處理

對數樣本

讓我們來看一個精簡版的訪問日誌示例，瞭解一下 DoS 攻擊在事件發生後可能呈現的情形。

1. 正常用户流量——每隔幾秒鐘，用户就會請求一個頁面並按預期收到響應。
2. DoS攻擊- 從[此處插入IP地址]開始10:01:10，可以看到該IP地址203.0.113.55開始向[此處插入IP地址]發送重複GET請求。/login.php
3. 網絡服務器宕機- 用户請求頁面時收到503響應，表明服務不可用。

這段日誌片段經過高度精簡，而 DoS 或 DDoS 攻擊可能會同時向日志中發送成百上千個請求。

動手實踐

您的自行車零件網站遭受了拒絕服務攻擊。請打開access.log用户桌面上的文件開始調查。日誌中包含正常用户流量和攻擊者流量的混合數據。在梳理日誌時，請注意對同一頁面的重複請求，並牢記您在此任務中學到的指標。祝您好運！

請回答以下問題。

攻擊者的IP地址是什麼？

203.12.23.195

攻擊者反覆向哪個頁面發起請求？

/login

攻擊發生後，合法用户會收到什麼錯誤代碼？

503

利用安全信息和事件管理 (SIEM)

安全信息和事件管理 ( SIEM ) 平台通過整合多個日誌源並查詢有用字段，顯著提高了日誌分析的效率。用户無需在日誌文件中滾動瀏覽無窮無盡的原始條目，即可按 IP 地址、用户代理或響應代碼篩選和排序日誌。這種功能使得識別流量模式變得更加容易。

在下面的截圖中，您可以看到Splunk根據十分鐘內對服務器的所有請求創建的時間圖表。

1. 正常用户請求——每分鐘向各個頁面發出少量請求
2. 拒絕服務攻擊——/login.php在一分鐘內
3. 請求頁面

通過查看相同的請求，但按用户代理（useragent）和 IP 地址（clientip）字段進行篩選，您可以查看有關請求來源的更多詳細信息。

動手實踐

這次，您的網站疑似遭受了DDoS攻擊。您將使用Splunk來調查發生了什麼！

使用桌面上的快捷方式打開 Splunk 實例，或直接訪問它。http://10.81.143.222:8000

在本練習中，您將分析在疑似攻擊期間收集的 Web 訪問日誌。這些日誌包含正常用户流量和潛在惡意請求的混合數據。首先，打開Splunk中的 “搜索與報告” 應用，並在主索引中運行搜索。在圖形用户界面 (GUI)的左側，您將看到從日誌文件中提取的字段。這些字段在您的調查過程中將非常有用。index="main"

最常被問到的問題是什麼uri？

/search

哪個clientip目標收到的請求最多uri？

203.0.113.7

攻擊你網站的殭屍網絡使用了多少個IP地址？

index=main 
| search clientip="203.0.113.*" 
| dedup clientip
| stats count(clientip)

60

useragent攻擊流量最常使用哪種方式？

Java/1.8.0_181

使用該timechart命令可視化請求。
攻擊期間每秒發出的請求峯值是多少？

index=main| timechart span=1s count by request

207

攻擊發生後，哪個合法（非攻擊性）實體clientip獲得了第一個響應狀態？503

10.10.0.27

防禦

攻擊者不斷尋找可利用的弱點，但防禦者擁有各種工具和方法來保持系統的韌性。本文將探討可用於預防和緩解攻擊的策略，以確保我們的網站和Web應用程序儘可能免受拒絕服務攻擊。

應用層防禦

安全開發實踐
安全的網站始於安全的代碼。搜索框和表單必須驗證輸入，以防止濫用。不妨把搜索表單想象成一位圖書管理員，根據用户的請求查找書籍。如果圖書管理員有明確的規則，例如“只搜索標題不超過 50 個字符的書籍”，他們就能快速響應。如果沒有這些規則，就可能有人要求圖書管理員搜索過長或包含特殊字符的奇怪標題，從而拖慢他們的速度，並延誤其他用户的請求。同樣，Web 應用程序也需要輸入驗證，以防止攻擊者提交旨在使系統過載的特殊查詢。

挑戰
阻止自動化流量的一種方法是在授予訪問權限前要求用户完成驗證。這可以是驗證碼（CAPTCHA），用户需要解決一些難題，例如點擊圖片或勾選複選框。對人類用户來説，這只是很小的一步，但對機器人來説，它可以阻止或減緩攻擊。

網站還可以使用 JavaScript 驗證，這些驗證會在後台靜默運行，以確認訪問者是真實用户還是自動化流量。合法用户通常不會注意到這些驗證，但自動化工具和殭屍網絡往往無法通過，因此這些驗證可以有效地過濾惡意流量。

網絡和基礎設施防禦

內容分發網絡（CDN）

CDN 通過緩存內容並從距離用户最近的邊緣服務器提供內容來幫助管理服務器負載。這降低了延遲，使源服務器只需處理一小部分請求，而 CDN 則處理大部分請求。因此，CDN 承擔了大部分緩解DDoS攻擊的責任。它們還提供負載均衡功能，將流量分配到各個服務器，確保沒有單個服務器過載，並在某個服務器不可用時重新路由請求。

以下是Cloudflare CDN 控制面板中顯示的16 TB DDoS攻擊示例。

1. 30 天總帶寬- 這顯示的是過去 30 天的總流量。如果您的網站通常每月流量只有幾百 GB，突然達到 16 TB 則表明存在異常情況。
2. CDN邊緣服務器緩存的總帶寬——這表示CDN邊緣服務器成功傳輸的流量總量。幾乎所有帶寬都被緩存，表明Cloudflare在攻擊流量導致後端服務器過載之前就將其吸收。
3. DDoS攻擊導致流量激增——圖表中的峯值是DDoS攻擊的特徵。如果沒有CDN，大量請求將直接衝擊源服務器。

除了吸收流量之外，CDN 還為分析人員提供強大的可視化功能，包括網站流量的直觀圖表和診斷信息。這使您可以按地理位置、流量和來源模式快速細分請求，從而幫助區分惡意流量和合法用户流量。

Web應用程序防火牆（WAF）

CDN通常會集成WAF來保護客户的服務器。WAF會檢查傳入流量，並根據情況允許、質疑或阻止請求。WAF基於整合了已知攻擊指標和威脅情報的規則運行。現代WAF解決方案已經非常擅長緩解DoS和DDoS攻擊，因為它們知道該注意哪些方面。此外，還可以開發自定義規則來輔助防禦定向威脅。

例如，您可以實施一條限速防火牆規則，將請求次數限制為/login.php每分鐘五次。如果發起請求的 IP 地址請求頁面超過五次，則會在一段時間內阻止其再次發起請求，或者要求其進行驗證以證明該請求是人類發起的。

大規模緩解措施

現代防禦解決方案不僅可以攔截拒絕服務攻擊，還能利用其龐大的分佈式基礎設施來吸收和平衡海量流量。2023年，谷歌成功緩解了一次峯值流量高達每秒3.98億次的DDoS攻擊。Cloudflare聲稱成功緩解了有史以來規模最大的DDoS攻擊，該攻擊峯值流量達到11.5 Tbps，持續時間僅35秒。這些案例表明，服務提供商如何利用全球網絡和流量過濾技術，防止即使是規模最大的攻擊也導致關鍵服務中斷。

繞過安全措施

儘管 CDN、緩存和 WAF 提供了強大的保護，但攻擊者常常試圖繞過這些防禦措施。一種常見的技術是附加隨機查詢參數。例如，您的 CDN 可能在某個 URL 處提供緩存頁面/products，但如果攻擊者在查詢參數後附加一個隨機字符串（例如/products?a=abcd，則您的 CDN 無法提供緩存頁面），則源服務器將被迫響應。同樣，更改用户代理、偽造引用頁面或從不同的地理區域發起請求也可以幫助攻擊者繞過 WAF 的過濾規則。

請回答以下問題。

什麼樣的安全挑戰可以通過要求用户解決一個簡單的謎題來阻止機器人？

# 驗證
captcha

CDN的哪項功能可以將流量分散到多個服務器上以防止過載？

# 負載均衡
load-balancing