crs-setup.cnf
#SecDefaultAction指令后的規則都繼承這一設置，除非為某條規則指定了一個特定的動作，或者指定了新的SecDefaultAction。特別注意到，未經處理的disruptive動作是不允許的，但是在SecDefautlAction中一不小心就會繼承了使用disruptive動作。
#SecDefaultAction必須指定一個disruptive動作和處理階段，而且不能包含元數據動作
SecDefaultAction "phase:1,log,auditlog,pass" SecDefaultAction "phase:2,log,auditlog,pass"
SecAction \
"id:900990,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_setup_version=302"
ModSecurity 2.x允許把規則置於下述五個階段之一：
請求頭(REQUEST_HEADERS) 階段
這個階段的規則會在apache完成請求頭的讀取后立即被執行（post-read-request階段），這時，還沒有讀取請求體，意味着不是所有的參數都可用。如果你必須讓規則盡早運行，應把規則放在這個階段（在apache使用這個請求做某些事前），在請求體被讀取前做些事情，從而決定是否緩存這個請求體，或者決定你將希望這個請求體如何被處理（如是否以XML格式解析或不解析）。
請求體(REQUEST_BODY) 階段
這是通用輸入分析階段，大部分傳統的應用規則不在這兒，這個階段你肯定能收到參數（只有讀取過請求體后），在請求體階段，ModSecurity支持三種編碼類型。
l application/x-www-form-urlencoded - used to transfer form data
l multipart/form-data - used for file transfers
l text/xml - used for passing XML data
大部分WEB應用還沒有使用其它的編碼方法。
響應頭(RESPONSE_HEADERS) 階段
發生在響應頭被發送到客戶端之前，如果你想觀察響應發生前就在這兒運行，如果你想使用響應頭來決定你是否想緩存響應體也行。注意一些響應狀態碼（如404）在請求環的早期就被apache管理着，我也無法觸發預期。加上apache在后面的勾子上雙增加了一些響應頭（如日期、服務器和連接信息等），這些我們無法觸發和審查。在代理配置模式下或使用phase:5(logging)工作的較好。
響應體(RESPONSE_BODY) 階段
這是通用輸出分析階段，這里你能運行規則截斷響應體（當然提供緩存）。這個階段你想檢查輸出的HTML信息公布、錯誤消息和失敗的驗證文字。
記錄(LOGGING) 階段
在日志發生前運行的一個階段，放在這個階段的規則只能影響日志記錄器如何執行，這個階段可以檢測apache記錄的錯誤消息，在這個階段你不能拒絕或阻斷連接，因為太遲了，這個階段也允許檢測其它的響應頭，如那在phase:3或者phase:4階段中不可用的。注意在這個階段，你應當小心不要繼承破壞性的動作到規則中，這樣的情況在ModSecurity2.5.0及其以后的版本中被當作配置錯誤。
圖-1是標准的apache請求流程，5個ModSecurity處理階段顯示其中。因此，在rule的部分即可指定你要處理的哪一部份進行處理。
圖-1