ModSecurity 2 是一款重要的 Web 應用程式防火牆 (WAF),用於保護 Apache HTTP 伺服器,提供即時監控和基於規則的過濾。 ModSecurity 安裝在 Debian 12 或 11 Linux 伺服器上,有助於防止 SQL 注入、跨站點腳本 (XSS) 和其他攻擊。 Digitalwave ModSecurity 儲存庫簡化了安裝,確保您使用最新的穩定版本。
為了增強安全性,OWASP 核心規則集 (CRS) 提供了常見漏洞的預先設定規則。設定它允許管理員透過最少的手動配置來加強防禦。本指南將向您展示如何使用 Digitalwave 儲存庫在 Debian 上安裝 ModSecurity 2 並設定 OWASP CRS 以獲得最佳保護。
更新 Debian 系統軟體套件以安裝 ModSecurity 2
我們的第一步是確保我們的 Debian 系統得到更新。這樣做可以使所有現有軟體包保持最新狀態,確保最佳效能,並最大限度地降低安全風險。透過執行以下命令來實現此目的:
sudo apt update && sudo apt upgrade
更新系統後,檢查是否安裝了 Apache。如果沒有,請使用以下命令進行安裝:
sudo apt install apache2
導入 ModSecurity 模組 PPA
設定所需的儲存庫
我們清單中的下一個任務是安裝 ModSecurity Apache 模組。 Debian 預設儲存庫中的可用版本可能不是最新的,使用它可能會立即導致錯誤。相反,我們將匯入第三方儲存庫來安裝最新的 Apache ModSecurity 模組。這個第三方儲存庫由 Digitalwave 維護,以其穩定的二進位檔案而聞名。
首先安裝一組必要的軟體包:
sudo apt install apt-transport-https lsb-release ca-certificates curl -y
然後我們繼續導入 ModSecurity 2 Module PPA 儲存庫 GPG金鑰:
curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor | sudo tee /usr/share/keyrings/digitalwave-modsecurity.gpg > /dev/null
取得 GPG 金鑰後,將儲存庫新增至您的系統:
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc) main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
echo "deb [signed-by=/usr/share/keyrings/digitalwave-modsecurity.gpg] http://modsecurity.digitalwave.hu/debian/ $(lsb_release -sc)-backports main" | sudo tee -a /etc/apt/sources.list.d/digitalwave-modsecurity.list
優先考慮新的 Apache 模組 PPA 儲存庫
儲存庫就位後,現在需要調整 APT 策略,以優先考慮與 ModSecurity 相關的特定軟體包的儲存庫。以下命令可以完成此操作:
cat << EOF | sudo tee -a /etc/apt/preferences.d/99modsecurity
Package: *nginx*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF
接下來,執行 APT 更新以反映新匯入的來源:
sudo apt update
此外,若要確認首選項,您可以透過以下方式確認此政策變更:
sudo apt-cache policy libapache2-mod-security2 modsecurity-crs libmodsecurity3
安裝 ModSecurity 2 模組
現在儲存庫已準備就緒,繼續安裝 libapache2-mod-security2 模組:
sudo apt install libapache2-mod-security2
安裝後,必須啟用該模組。使用以下命令來實現此目的:
sudo a2enmod security2
重新啟動 Apache 服務
最後,我們重新啟動 Apache 服務以確保所有變更生效,並且新新增的 ModSecurity 模組已正確整合:
sudo nano /etc/apache2/mods-enabled/security2.conf
在 Apache HTTP 上啟用 ModSecurity 2 模組
存取 ModSecurity 設定文件
Apache ModSecurity 的設定檔可以在 /etc/apache2/mods-enabled/security2.conf 中找到。使用 Nano 文字編輯器(或您首選的文字編輯器)透過以下命令存取此文件:
sudo nano /etc/apache2/mods-enabled/security2.conf
尋找顯示以下內容的行:
IncludeOptional /etc/modsecurity/*.conf
確保此行未註釋,因為它包含 /etc/modsecurity 目錄中的其他必要設定檔。預設情況下應該取消註釋。
修改 ModSecurity 2 配置
我們需要將 modsecurity.conf 建議的設定檔重命名為 modsecurity.conf 以使其處於活動狀態。這可以透過以下命令來完成:
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
現在,讓我們打開這個新命名的設定檔:
sudo nano /etc/modsecurity/modsecurity.conf
預設情況下,ModSecurity 規則引擎在此文件中設定為「DetectionOnly」。這意味著它將識別並記錄潛在的惡意行為而不阻止它。若要變更此設定並啟用 ModSecurity 的封鎖功能,請找到 SecRuleEngine 行(第 7 行附近)並將DetectionOnly 替換為On。
從:
SecRuleEngine DetectionOnly
到:
SecRuleEngine On
調整 Apache 的日誌設定
在設定檔的更下方,您將找到 SecAuditLogParts 行(大約第 224 行)。該行的預設設定不太正確;需要對其進行調整以準確記錄所有交易資訊。
改變:
SecAuditLogParts ABDEFHIJZ
到:
SecAuditLogParts ABCEFHJKZ
完成這些修改後,儲存變更並退出編輯器。
重新啟動 Apache 以應用更改
此程序的最後一步是重新啟動 Apache 服務,以便我們對 ModSecurity 配置的變更生效。這是使用以下命令完成的:
sudo systemctl restart apache2
安裝 ModSecurity2 的 OWASP 核心規則集
ModSecurity 本身並不能保護您的網路伺服器。它需要一個規則集來識別潛在威脅並阻止惡意活動。 OWASP(開放 Web 應用程式安全專案)核心規則集 (CRS) 是各種 Web 伺服器和 Web 應用程式防火牆 (WAF) 使用的備受推崇的規則集。部署此規則集可為您的伺服器提供強大的保護,抵禦網路上出現的一系列威脅。
在繼續之前,必須透過造訪以下連結來驗證您是否擁有最新版本的 OWASP CRS: OWASP 發布標籤頁。此步驟可確保您為伺服器下載並安裝最新的安全措施。
為 OWASP CRS 建立父目錄
首先,讓我們使用 mkdir 指令來建立 OWASP 的主父目錄:
sudo mkdir /etc/apache2/modsec/
下載 Debian 上的 OWASP CRS 檔案
接下來,我們將使用 wget 指令來取得 OWASP CRS 3.3.4 存檔,這是撰寫本文時的穩定版本。請記住,您應該使用前面提到的連結驗證版本。
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v3.3.4.zip
每晚建置可能會提供更多最新的安全措施,但可能會因其開發狀態而導致問題。對於新用戶,建議使用穩定版本以避免潛在的併發症。
注意:您應該經常檢查更新;穩定的規則不會每週更改,而是每季更改一次,或除非需要緊急更新。
擷取檔案
下載存檔後,我們可以將其解壓縮到我們之前創建的目錄中:
sudo tar xvf v3.3.4.tar.gz -C /etc/apache2/modsec
請記住根據您下載的 OWASP CRS 版本更改命令。
配置規則集
OWASP CRS 有一個範例設定文件,您應該重新命名,同時保留原始檔案作為備份。您可以使用“cp 命令”來執行此操作:
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf.example /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
注意:請記得將 /coreruleset-3.3.4/ 替換為您選擇的 OWASP CRS 的確切版本。
啟用規則
若要啟動規則,請開啟 /etc/apache2/mods-enabled/security2.conf 檔案:
sudo apt install unzip -y
然後,插入以下兩行:
Include /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
Include /etc/apache2/modsec/coreruleset-3.3.4/rules/*.conf
注意:再次確保將 /coreruleset-3.3.4/ 替換為您選擇的 OWASP CRS 的確切版本,因為您將下載的 coreruleset 很可能會比指南的範例更新。
此外,註解掉或刪除以下行:
IncludeOptional /usr/share/modsecurity-crs/*.load
完成後,儲存並退出文件:
重新啟動 Apache 以應用更改
最後一步是重新啟動 Apache 服務以確保變更生效:
sudo systemctl restart apache2
OWASP 核心規則集與 ModSecurity 2 入門
OWASP 核心規則集 (CRS) 是一個綜合工具,具有眾多可自訂的選項。其預設配置為大多數伺服器提供即時安全性增強功能,而不會影響真正的訪客或搜尋引擎最佳化 (SEO) 機器人。我們將在本節中討論 CRS 的幾個重要方面,但探索設定檔以全面了解所有可用選項總是有益的。
調整CRS配置
我們首先打開 crs-setup.conf 文件,其中大部分 CRS 設定都可以更改:
sudo nano /etc/apache2/modsec/coreruleset-3.3.4/crs-setup.conf
了解 CRS 評分系統
ModSecurity 以兩種不同的模式運作:
- 異常評分模式:建議大多數使用者使用,此模式會在每次規則配對時分配「異常分數」。處理入站和出站規則後,將檢查異常分數,並在必要時觸發中斷操作。此操作通常採用 403 錯誤的形式。此模式提供了準確的日誌訊息,並為設定攔截策略提供了更大的靈活性。
- 自包含模式:在此模式下,只要符合規則,就會立即套用操作。雖然它可以減少資源使用,但它提供的靈活性較低,並且產生的稽核日誌資訊較少。當滿足第一條規則並執行指定的操作時,規則匹配程序停止。
了解偏執狂程度
OWASP CRS 定義了四個偏執等級:
- 偏執等級 1:預設等級適合大多數使用者。
- 偏執 2 級:適用於進階使用者。
- 偏執狂等級 3:針對專家使用者。
- 偏執4級:僅在特殊情況下建議使用。
較高的偏執程度可以啟用額外的規則,提高安全性,並增加因誤報而阻止合法流量的可能性。選擇符合您的專業知識和安全需求的偏執程度至關重要。
在您的伺服器上測試 OWASP CRS
為了確保 OWASP CRS 在您的伺服器上正常運行,請使用 Internet 瀏覽器存取下列 URL。請記得將“yourdomain.com”替換為您的實際網域:
https://www.yourdomain.com/index.html?exec=/bin/bash
如果您收到 403 Forbidden 錯誤,OWASP CRS 將如預期運作。如果沒有,則設定過程中可能存在錯誤,需要您注意;最常見的問題可能是忘記將“DetectionOnly”更改為“On”或類似的內容。
解決誤報和自訂排除規則
使用 ModSecurity 和 OWASP 核心規則集 (CRS) 管理誤報可能是一項持續的任務。然而,這些系統針對各種威脅提供的強大防禦能力使得這項工作變得至關重要。為了最大限度地減少最初的誤報,建議設定較低的偏執程度。
透過以較低的偏執程度運行規則集幾週甚至幾個月,您可以減少大量誤報的可能性。這種方法讓您有時間熟悉警報和適當的回應,然後逐漸提高偏執程度以獲得更嚴格的安全性。
使用 OWASP、ModSecurity 2 管理 Debian 上已知應用程式中的誤報
ModSecurity 包括將某些可能無意觸發誤報的操作列入白名單的功能。例如:
#SecAction \
# "id:900130,\
# phase:1,\
# nolog,\
# pass,\
# t:none,\
# setvar:tx.crs_exclusions_cpanel=1,\
# setvar:tx.crs_exclusions_dokuwiki=1,\
# setvar:tx.crs_exclusions_drupal=1,\
# setvar:tx.crs_exclusions_nextcloud=1,\
# setvar:tx.crs_exclusions_phpbb=1,\
# setvar:tx.crs_exclusions_phpmyadmin=1,\
# setvar:tx.crs_exclusions_wordpress=1,\
# setvar:tx.crs_exclusions_xenforo=1"
若要為 WordPress、phpBB 和 phpMyAdmin 等應用程式製定白名單,請取消註解對應行並保留 (1) 值。若要防止將未使用的服務列入白名單,請將數值調整為 (0)。
更新後的配置可能如下所示:
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_phpbb=1,\
setvar:tx.crs_exclusions_phpmyadmin=1,\
setvar:tx.crs_exclusions_wordpress=1"
在本例中,無關的選項已被刪除,為您所需的配置留下了正確的語法。
在 CRS 實施之前建立規則排除
若要建立自訂排除,請先使用下列指令重新命名「REQUEST-900-EXCLUSION-RULES-BEFORE-CRS-SAMPLE.conf」檔案:
sudo cp /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/coreruleset-3.3.4/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
請記住,每個排除規則必須有一個唯一的“idnumber”,以避免 Apache2 服務測試期間發生錯誤。
例如,某些“REQUEST_URI”可能會導致誤報。以下範例說明了涉及 Google PageSpeed 信標和 WordPress 的 WPMU DEV 外掛程式的兩個此類案例:
SecRule REQUEST_URI "@beginsWith /wp-load.php?wpmudev" "id:1544,phase:1,log,allow,ctl:ruleEngine=off"
SecRule REQUEST_URI "@beginsWith /ngx_pagespeed_beacon" "id:1554,phase:1,log,allow,ctl:ruleEngine=off"
這些規則會自動允許以指定路徑開頭的任何 URL。
您也可以將特定 IP 位址列入白名單:
SecRule REMOTE_ADDR "^195\.151\.128\.96" "id:1004,phase:1,nolog,allow,ctl:ruleEngine=off"
SecRule REMOTE_ADDR "@ipMatch 127.0.0.1/8, 195.151.0.0/24, 196.159.11.13" "phase:1,id:1313413,allow,ctl:ruleEngine=off"
在第一條規則中,單一 IP 位址被列入白名單,而第二條規則使用「@ipMatch」指令進行更廣泛的子網路比對。若要封鎖子網路或 IP 位址,只需將「允許」替換為「拒絕」即可。這種靈活性可讓您建立詳細的黑名單和白名單,可與 Fail2Ban 整合以增強安全策略。
使用 OWASP、ModSecurity 2 停用 Debian 上的特定規則
另一種方法是停用導致持續誤報的特定規則,而不是將整個路徑列入白名單。儘管這種方法需要更多的測試,但它提供了長期的好處。
例如,如果「/admin/」區域中的規則 941000 和 942999 為您的團隊觸發誤報,您可以在 ModSecurity 日誌中找到規則 ID,並使用「RemoveByID」命令僅停用這些特定 ID:
SecRule REQUEST_FILENAME "@beginsWith /admin" "id:1004,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"
監控日誌並識別模式
使用 Apache、ModSecurity 和 OWASP 處理誤報時,持續日誌監控至關重要。它有助於識別觸發誤報的模式,讓您可以建立自訂規則來解決這些問題。
例如,如果特定規則始終導致誤報,您可以建立排除規則來處理這些特定實例。這種量身定制的方法可確保更有效地管理誤報。
透過定期檢查日誌並調整規則,您可以為應用程式維護一個更安全、更有效率的環境。
ModSecurity 2 的日誌輪換
由於 Web 交易的動態特性,ModSecurity 日誌可能會快速成長,因此有效的日誌管理至關重要。日誌輪替是管理這些日誌的有用工具,儘管 ModSecurity 中預設未配置它。本節將引導您專門為 ModSecurity 設定日誌輪替。
建立 ModSecurity 輪換文件
首先,您需要為 ModSecurity 日誌輪轉建立專用檔案。為此,請使用以下命令建立並開啟名為 modsec 的新檔案:
sudo nano /etc/logrotate.d/modsec
配置旋轉文件
在新建立的 ModSecurity (modsec) 設定檔中,新增以下內容:
/var/log/modsec_audit.log
{
rotate 31
daily
missingok
compress
delaycompress
notifempty
}
此配置將日誌保留 31 天,但您可以修改該數字以滿足您的需求。例如,將其更改為“旋轉 7”將保留一周的日誌。
「daily」指令確保日誌每天輪換,而「compress」則透過壓縮舊日誌來節省空間。 「delaycompress」選項將壓縮延遲到第二個循環週期,而「missingok」則可以在日誌檔案不存在時防止錯誤。此外,「notifempty」可確保不輪換空日誌檔案。
提示:建議每日日誌輪轉,以避免處理過大的日誌文件,這會使分析更加耗時。
結論
現在,您已使用 Digitalwave 儲存庫在 Debian 12 或 11 伺服器上安裝了 ModSecurity 2,並配置了 OWASP 核心規則集。有了這些工具,您的伺服器就可以阻止許多常見的 Web 應用程式威脅。
請記得定期更新 CRS 並監控任何誤報或遺漏的漏洞。一致的測試和調整是維持強大的安全設定的關鍵。