modSecurity規則學習（一）——配置文件

環境：modSecurity3.0，nignx1.13.8

modSecurity配置文件

1、nginx.conf

server {
        listen       81;
        modsecurity on; //啟動modsecurity插件
        location / {
            modsecurity_rules_file /usr/local/nginx/conf/modsecurity.conf;      //modsecurity配置
            root   html;
            index  index.html index.htm;
        }
    }

2、modsecurity.conf

#SecRuleEngine是接受來自ModSecurity-CRS目錄下的所有規則的安全規則引擎。因此，我們可以根據需求設置不同的規則。要設置不同的規則有以下幾種。
#SecRuleEngine On：將在服務器上激活ModSecurity防火牆。它會檢測並阻止該服務器上的任何惡意攻擊。
#SecRuleEngine Detection Only：如果這個規則是在whitelist.conf文件中設置的，它只會檢測到所有的攻擊，並根據攻擊產生錯誤，但它不會在服務器上阻止任何東西。
#SecRuleEngine Off:：這將在服務器上上停用ModSecurity的防火牆。
SecRuleEngine DetectionOnly
#SecRequestBodyAccess是否允許ModeSecurity訪問request bodies(post請求內容)；備注：如果你計划檢查POST_PAYLOAD 就使用這個指令，這個指令必須和"phase:2"處理階段動作和REQUEST_BODY 變量/位置一起使用，這三部分任一一個沒有配置，你就無法檢查請求體。
SecRequestBodyAccess On
#SecRule是ModSecurity主要的指令，用於分析數據並根據結果執行動作，SecRule VARIABLES OPERATOR [ACTIONS]；
#VARIABLES描述哪個變量被檢查，舉個例子，下述規則會拒絕URI中含有單詞dirty的事務。每條規則可以指定一個或多個變量,如SecRule ARGS|REQUEST_HEADERS:User-Agent dirty
#OPERATOR描述如何進行檢查
#[ACTIONS]可選的,描述當操作進行成功的匹配一個變量時具體怎么做。
#XML內容情況下啟動XML解析
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
#json內容情況下啟動XML解析
SecRule REQUEST_HEADERS:Content-Type "application/json" "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

#配置ModSecurity允許的最大請求體的緩存區大小，第一條是有上傳文件的，默認1G，第二條是沒有文件的上傳的限制，默認128K;#：配置ModSecurity 允許的最大請求體的緩存區大小，除了請求中正在傳送的文件大小。
這項指令便於在受到某些使用大尺寸請求進行DoS 攻擊時減少影響。提供上傳文件服務的WEB 應用必須配置SecRequestBodyLimit 為一個很大的值。由於大文件直接進行磁盤文件存取，不會加大內存的消耗。
但是，仍然有可能有人利用超大請求體限制和發送大量大小的非上傳請求。該指令消除這一漏洞。
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
#SecRequestBodyLimitAction  Reject：拒絕、Process Partial：呈現請求的第一部分    #當請求超過SecRequestBodyLimit策略中配置的設置時該做什么。 默認情況下拒絕大於集合的請求。
SecRequestBodyLimitAction Reject
SecRule REQBODY_ERROR "!@eq 0" "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:400, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
#設置PCRE庫中的匹配限制。
SecPcreMatchLimit 1000
#在PCRE庫中設置匹配限制遞歸，提高效率。
SecPcreMatchLimitRecursion 1000
SecRule TX:/^MSC_/ "!@streq 0" "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
#允許ModSecurity訪問response body，您應該啟用此指令以識別錯誤和數據泄漏問題。 啟用這個指令會增加內存消耗和響應延遲。
SecResponseBodyAccess On
#備注：如果你計划檢查HTML 的響應，需要使用這個指令。這個指令必須和"phase:4"處理階段動作和REQUEST_BODY 變量/位置一起使用，這三部分任一一個沒有配置，你就無法檢查請求體。

#設置返回體的MIME資源的媒體類型 SecResponseBodyMimeType text/plain text/html text/xml
#配置允許緩存的最大響應體大小，默認512K SecResponseBodyLimit 524288
#配置SecResponseBodyLimit，控制如果request body 大小超過上面限制的情況，默認時ModSecurity拒絕超過指定長度的響應體，
#然而一些WEB站點，會產生一些非常長的響應為適當限制帶來難度。
#這類網站不得不極大的提高關注度，把限制放到了首位（控制內存消耗）。
#有能力選擇的是發生站點限制時，管理員能選擇僅僅檢查響應的第一部分，這部分可融入理想的限制，並讓其通過。
#可以證明未經檢查就允許部分響應是個漏洞，理論上這是對的，但僅適用於攻擊者控制輸出的案例（如它可以任意的長）。
#不管怎樣，在這種情況下，無論如何是阻止不了漏洞的。攻擊者在數據回送前可以壓縮，打亂或者甚至是加密，因為可以穿越任意監控設備。 SecResponseBodyLimitAction ProcessPartial|Reject
#ModSecurity存放持久化數據（如ip 地址數據，session 數據等）路徑，initcol、setsid和setuid需要用到這個指令 SecDataDir /tmp/
#配置攔截文件存儲的目錄 #SecUploadDir /opt/modsecurity/var/upload/
#配置是否保存事務處理后的攔截文件 #SecUploadKeepFiles RelevantOnly #SecUploadFileMode 0600
#調試日志路徑，1~3級別一直用於產生apache/nginx的錯誤日志，因為你可以在產品中一直使用0級別做為默認的日志級別，級別4-9用於調試，

不建議在產品中使用這么高級別的日志，過度的日志記錄會顯著服務器的性能。

#SecDebugLog /opt/modsecurity/var/log/debug.log #SecDebugLogLevel 3
#配置審計日志引擎的開啟與否；On － 默認情況下記錄所有事務的日志；RelevantOnly - 默認只記錄事務中由warning或error觸發的日志，或者記錄一些特意考慮過的狀態碼 SecAuditEngine RelevantOnly
#記錄由規則標記的事務，以及觸發服務器錯誤(由5xx或4xx確定，不包括404， #級別響應狀態代碼)。#備注：必須將SecAuditEngine 設置為RelevantOnly，其參數是個正則表達式。
#這個指令最主要的目的是允許你配置審計產生特殊HTTP 響應狀態碼的唯一事務，這個指令通常用於減少審計日志文件的總體大小。記住一點，如果使用了這個參數，那么返回狀態碼是200 的成功攻擊事件不會記錄。
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

#定義每個事務中記錄到審計日志中的部分。默認：ABCFHZ.
可用的審計日志部分:
A - 審計日志標題(強制的)
B - 請求標題
C - 請求體(目前僅針對請求體存在，並且ModSecurity已經配置成攔截)
D - 為中間人響應頭保留，暫未實現
E - 中間人響應體(目前僅對配置了攔截響應體和配置審計日志引擎記錄有效)。中間人響應體和實際的響應體相同，除非ModSecurity攔截了中間人響應體，這種情況下，實際響應體會包含出錯信息（可能是apache的默認錯誤信息，也可能是出錯文檔頁面）。
F - 最終響應頭(除了日期和服務器標題以外的被apache添加的近期內容傳遞信息)。
G - 為實際響應體保留，暫未實現。
H - 審計日志索引
I - 這C部分的替換，使用multipart/form-data編碼時，在所有的異常情形下會記錄與C相同的數據，在這種情況下，會記錄假的application/x-www-form-urlencoded內容，這包含參數的相關信息，但不是這個文件的。如果你不想用文件（通常很大）來存儲你的審計日志，這是很方便的。
J - 保留。實現后，這部分會包含文件使用multipart/form-data編碼上傳的信息。
K - 這部分包含一個完整的列表，按順序匹配（每行一個），這些規則是完全合格的，從而表明繼承默認的動作和操作，從2.5.0開始支持。
Z - 最終分界，意味着是條目的最后(強制的)
SecAuditLogParts ABIJDEFHZ
#配置使用審計日志記錄機制的類型Serial|Concurrent,Serial - 所有的審計日志條目都被存儲在主審計日志記錄文件中，隨意使用是很方便，但是它很慢，因為任何時候只有一個文件被打開也只能寫入一條審計日志條目。
Concurrent - 審計日志條目被存儲於不同的文件中，每個事務一個，如果你要把審計日志數據發送到遠程ModSecurity控制主機上就使用Concurrent日志模式。
SecAuditLogType Serial
#審計日志路徑
SecAuditLog /var/log/modsec_audit.log

#指定的字符做為application/x-www-form-urlencoded內容的分隔符，默認是&，非常少的情況下應用會使用分號(;)。
這個指令用於后台WEB應用在使用非標准的參數分隔符,如果沒有在每一個WEB應用中合理設置這個指令，
那么ModSecurity可能無法適當的分析所有的參數，並且規則匹配的效果可能會顯著的降低。 SecArgumentSeparator &
#選擇當前配置文本中使用的cookie格式，0 - 使用version 0 (Netscape) cookies，這是大部分應用使用的，也是默認值；1 - 使用version 1 cookies SecCookieFormat 0
#定義將由urlDecodeUni變換函數用於在規范化期間映射Unicode代碼點的文件的路徑，並指定要使用的代碼點。 SecUnicodeMapFile unicode.mapping 20127
#控制狀態報告功能。 使用基於DNS的報告將軟件版本信息發送到ModSecurity項目團隊。 SecStatusEngine On #Load OWASP Config Include crs-setup.conf #Load all other Rules Include rules/*.conf