6 個自行檢測網站主機 WAF 防火牆的指令

駭客在網址列加上參數或特殊字符是常見的網站攻擊模式，我們可以用同樣的方式來測試基本的 Web 應用防火牆 (WAF) 是否能有效阻擋潛在攻擊。常見的測試方法包括模擬 SQL 注入、跨站腳本 (XSS)、檔案包含攻擊 (LFI/RFI) 和命令注入等。成功的 WAF 會攔截這些惡意請求並返回錯誤代碼（通常是 403 Forbidden）。這些測試簡單易行，不需要額外工具，但只能檢測到基本的防禦能力，無法完全覆蓋所有安全風險，並且可能產生誤報，應謹慎使用。

WAF 就像是你家裡看門的保全人員，幫你阻擋從外面進來的歹徒（駭客），所以我們就用一些演練試試看他能不能阻全歹徒，如果這個演練你家的保全都沒有反應甚至讓對方進來的話，你就應該考慮換一個保全了。

內容目錄

什麼是 WAF Web Application Firewall 應用程式防火牆

WAF（Web Application Firewall 應用防火牆）和傳統防火牆（Firewall）都是用來保護網路資源的工具，但它們的保護對象和工作層級不同。以下是它們的主要差異和適用場合：

1. 工作層級的差異

傳統防火牆（Firewall）：
- 工作在 OSI 模型的第3層（網路層）和第4層（傳輸層）。
- 主要用來控制網路流量的進出，通過 IP 地址、連接埠和通信協定（如 TCP、UDP）來決定是否允許或拒絕數據封包。
- 傳統防火牆通常用於阻擋未經授權的流量和攻擊（如 DDoS 攻擊）。
WAF 應用程式防火牆（Web Application Firewall）：
- 工作在 OSI 模型的第7層（應用層），專門針對 Web 應用程式的流量進行過濾和保護。
- WAF 通常用來防護常見的 Web 應用程式攻擊，例如 SQL 注入、跨站腳本攻擊（XSS）、跨站請求偽造（CSRF）、以及其他與 HTTP/HTTPS 通信協定相關的威脅。
- WAF 更深入應用層，分析 HTTP/HTTPS 請求和回應的內容，以判斷是否存在攻擊行為。

2. 防護範圍與目標

傳統防火牆：
- 防護目標是整個網路基礎設施，如伺服器、網路設備等。
- 主要針對來自外部網路的攻擊，阻止非法訪問網路資源。
- 適合防護網路層和傳輸層的攻擊，例如：IP Spoofing（IP 偽造）、DDoS、端口掃描等。
WAF：
- 防護目標是 Web 應用程式，專注於應用層的安全。
- 目標是防止駭客利用 Web 應用程式的漏洞發起的攻擊，例如：SQL 注入、XSS 攻擊等。
- 適合防護與 Web 應用程式相關的攻擊，確保 Web 應用的數據不被篡改或盜取。

3. 適用場合

傳統防火牆的適用場合：
- 企業內部網路安全：用來控制內部網路與外部網路（如網際網路）的流量，防止未經授權的訪問和攻擊。
- 資料中心或伺服器防護：用來防止來自互聯網的大規模攻擊（例如 DDoS 攻擊）影響伺服器性能。
- 網路隔離：允許內網系統之間的網路隔離，防止內部攻擊擴散。
WAF 的適用場合：
- Web 應用程式安全：特別適合用來保護有 Web 應用程式的伺服器，防止應用層攻擊。
- 電子商務網站：保護交易系統免受 SQL 注入和其他攻擊，確保數據安全。
- API 保護：WAF 可以用來保護 Web API，確保數據接口不被惡意攻擊者利用。

4. 防護技術與策略

傳統防火牆：
- 根據預設規則（白名單或黑名單）來允許或拒絕數據包。
- 可以基於源 IP、目的 IP、連接埠號、通信協定等設定過濾規則。
- 適合粗粒度的安全控制，針對整個網路層面的流量進行分析。
WAF：
- 透過深入檢查 HTTP/HTTPS 請求中的內容，來識別和阻擋惡意流量。
- 能夠檢測和阻止與 Web 應用程式漏洞相關的攻擊，防止攻擊者利用漏洞進行數據竊取或篡改。
- 可以基於具體的應用程式行為來設定防護規則，例如驗證輸入、驗證 Session 或 Cookie 的安全性。

5. 範例

傳統防火牆範例：
- 某公司防火牆規則設定：阻擋所有來自 IP 範圍外部的 SSH 連接，僅允許內部 IP 段的機器進行連接。
WAF 範例：
- 某電子商務網站的 WAF 規則：當檢測到含有潛在 SQL 注入字串（如 1=1 或 ‘ OR ‘1’=’1’）的查詢參數時，立即拒絕該請求。

我們總結一下兩者的差異

傳統防火牆 側重於網路層級的流量控制和防護，適用於阻止網路攻擊、未經授權的連接等威脅。
WAF 則專注於應用層的保護，主要防護針對 Web 應用程式的攻擊，如 SQL 注入和 XSS。
適用情境 上，企業通常會同時部署兩者，以提供從網路層到應用層的全方位防護。

以下是我們可以自行檢測網站主機 WAF 是吾有效的指令：

1. SQL Injection 測試

測試方法：在網址列中加入可能導致 SQL 注入的字符串，這是 WAF 最常見的攔截測試。
範例：https://yourwebsite.com/product.php?id=1' OR '1'='1'
期待結果：如果 WAF 正常工作，這樣的請求應該會被攔截或返回 HTTP 403 Forbidden 錯誤。沒有 WAF 的話，網站可能會返回資料庫錯誤或正常的頁面。
延仰閱讀：OWASP SQL Injection

2. Cross-Site Scripting (XSS) 測試

測試方法：嘗試插入腳本代碼，這類攻擊也是 WAF 應該攔截的典型範例。
範例：https://yourwebsite.com/search?q=<script>alert(1)</script>
期待結果：如果 WAF 有效，這樣的腳本代碼應該會被攔截，或者被網站過濾。沒有防護的話，這可能會顯示一個彈出窗口或觸發瀏覽器的 XSS 警告。
延仰閱讀：OWASP Cross Site Scripting (XSS)

3. 本地檔案包含（LFI/RFI）測試

測試方法：通過在 URL 中嘗試包含檔案，來測試 WAF 是否能攔截本地或遠程檔案包含攻擊。
範例：https://yourwebsite.com/index.php?page=../../etc/passwd
期待結果：WAF 應該攔截這類試圖存取敏感檔案的請求。如果沒有 WAF，可能會顯示「檔案不存在」等錯誤。
延仰閱讀：HITCON 透過 LFI 引入 PHP session 檔案觸發 RCE

4. Command Injection 命令注入測試

測試方法：網站上如果有類似「Ping 測試」的功能，駭客可能會試圖在主機名稱或 IP 輸入框中插入惡意命令，藉此測試 WAF 是否能攔截命令注入攻擊。
範例：https://yourwebsite.com/ping.php?host=127.0.0.1;ls
期待結果：WAF 應該攔截此類命令注入攻擊。如果 WAF 沒有工作，可能會顯示伺服器目錄列表或回傳錯誤訊息。
延仰閱讀：國立台灣大學 Command Injection運作原理與解說

5. 特殊字符測試

測試方法：嘗試在網址列中加入常見的攻擊相關特殊字符，如 –, <, >, &, |, ‘, “, 等。
範例：https://yourwebsite.com/?input=>
期待結果：WAF 應該攔截這些可能的攻擊字符或返回錯誤。如果沒有防護，可能會導致頁面異常。
延仰閱讀：OWASP Special Element Injection

6. HTTP Header 攻擊測試

測試方法：嘗試修改 HTTP Header，模擬常見的攻擊來測試 WAF 是否會攔截。
範例：使用工具如 curl 來手動添加惡意的 HTTP Header。curl -H "User-Agent: () { :; }; echo; echo hacked" https://yourwebsite.com
期待結果：WAF 應該阻擋這類類似「Shellshock」的攻擊。如果 WAF 沒有生效，伺服器可能會被影響。
延仰閱讀：iT邦幫忙 HTTP Header Injection – HTTP Header 注入

使用 PowerShell 來替代 curl

在 Windows 系統上，雖然可以安裝和使用 curl 工具，但如果不想安裝 curl，可以考慮使用 PowerShell 提供的內建工具來達到類似的效果。以下是幾個可以替代 curl 的 PowerShell 指令，來進行 HTTP 請求或模擬簡單的 WAF 測試。

PowerShell Invoke-WebRequest這是 PowerShell 提供的強大指令，能夠發送 HTTP 請求並檢查回應。
- 範例 1：模擬簡單的 GET 請求Invoke-WebRequest -Uri "https://yourwebsite.com"
  - 用途：檢查網站是否能正常訪問，並返回 HTTP 狀態碼和回應內容。
- 範例 2：帶有自定義 User-Agent 的請求可以模擬不同的請求標頭來測試 WAF 防護。Invoke-WebRequest -Uri "https://yourwebsite.com" -Headers @{ "User-Agent"="() { :; }; echo hacked" }
  - 用途：模擬 Shellshock 式攻擊，測試 WAF 是否攔截不安全的請求標頭。
- 範例 3：模擬 POST 請求如果需要進行 POST 請求測試，例如發送惡意資料，使用 Invoke-WebRequest 的 -Method 和 -Body 參數。Invoke-WebRequest -Uri "https://yourwebsite.com/login.php" -Method POST -Body @{ "username" = "admin"; "password" = "password' OR '1'='1" }
  - 用途：模擬 SQL 注入攻擊，測試 WAF 是否攔截惡意的 POST 請求。
PowerShell Invoke-RestMethod這個指令與 Invoke-WebRequest 相似，但專門用來處理 REST API 回應，因此更適合處理 JSON 和 XML 結果。
- 範例：Invoke-RestMethod -Uri "https://yourwebsite.com/api" -Method GET
  - 用途：可以用來測試網站的 API 或特定端點。

測試注意事項

錯誤碼：如果 WAF 正常運行，通常會返回 HTTP 403 Forbidden，或者 HTTP 406 Not Acceptable 等阻擋代碼，您可以在瀏覽器看到錯誤訊息。
日誌記錄：如果您的網站有網頁伺服器的存取日誌 Access Log，應該能看到 WAF 攔截這些惡意請求的記錄，包括來源 IP 、時間以及使用者代理 User Agent 等。
不要在生產環境中測試：進行這些測試前，請確認您是在安全環境下進行，以免對網站或伺服器造成影響。
誤報 False Positives：一些 WAF 設置可能會過於嚴格，導致合法請求被誤判為惡意攻擊，這時需要微調 WAF 的規則。
被防火牆封鎖的風險：一般的防火牆防護機制可能會在你持續幾次的 403 Forbidden 之後，就封鎖這個 IP 位址，如果被封鎖了那恭喜你的防火牆功能正常，而要解除封鎖桌機或連家裡 WIFI 的手機你只要把上網的數據機重開，手機用行動網路上網就把行動網路關閉再重開，這樣你就會換一個上網的 IP，這樣就不會被封鎖了。

總結

這些測試可以幫助您快速確認 WAF 是否在運作以及其基本的防護效果。不需要額外的工具，只需通過瀏覽器的 URL 欄或命令行工具如 curl 就能模擬簡單的攻擊嘗試。

在 Windows 系統中，使用 PowerShell 的 Invoke-WebRequest 或 Invoke-RestMethod 指令可以很容易地替代 curl，來進行網站 WAF 測試和安全檢查。這些工具不僅簡單易用，而且不需要額外安裝第三方軟件。

如果您的網站對這些指令都無感，甚至在存取記錄中都找不到 HTTP 403 Forbidden 的回應的話，那最好換一家安全性比較高的主機供應商，畢竟給網站一個安全無虞主機環境才能遠離網站被駭的風險。