nginx.conf
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