本篇簡要介紹ModSecurity Transaction Lifecycle，也即ModSecurity的事務生命周期，
Transaction Lifecycle
In ModSecurity, every transaction goes through ?ve steps, or phases. In each of the phases, ModSecurity will perform some work at the beginning (e.g., parse data that has become avail- able), invoke the rules speci?ed to work in that phase, and perhaps perform a task or two after the phase rules have ?nished. At ?rst glance, it may seem that ?ve phases are too many, but there’s a reason that each phase exists. There is always one task, sometimes several, that can only be performed at a particular moment in the transaction lifecycle.
在ModSecurity中，每個事務都經過五個步驟或階段，在每個階段中，ModSecurity都將在開始時執行一些作業（例如，決議可用的資料），呼叫指定在該階段中作業的規則，并可能在階段規則完成后執行一兩個任務，乍一看，似乎階段太多了，但是每個階段都存在一個原因，總是有一個任務，有時是幾個，只能在事務生命周期的特定時刻執行，
Request headers (1)
The request headers phase is the ?rst entry point for ModSecurity. The principal pur- pose of this phase is to allow rule writers to assess a request before the costly request body processing is undertaken. Similarly, there is often a need to in?uence how Mod- Security will process a request body, and in this phase is the time to do it. For example, ModSecurity will not parse an XML or JSON request body by default, but you can in- struct it do so by placing the appropriate rules into phase 1.
請求頭階段是ModSecurity的第一個入口點，此階段的主要目的是允許規則撰寫器在執行代價高昂的請求正文處理之前評估請求，類似地，經常需要影響Mod-Security如何處理請求主體，在這個階段是時候這樣做了，例如，默認情況下，ModSecurity不會決議XML或JSON請求體，但您可以通過在階段1中放置適當的規則來指示其進行相應的操作，
Request body (2)
The request body phase is the main request analysis phase and takes place immediately after a complete request body has been received and processed. The rules in this phase have all the available request data at their disposal. Afterward, the web server will either generate the response itself (in embedded mode) or forward the transaction to a back- end web server (in reverse proxy mode).
請求正文階段是主要的請求分析階段，在接收和處理完完整的請求正文之后立即進行，這個階段的規則擁有所有可用的請求資料，之后，web服務器將生成回應本身（在嵌入式模式下）或將事務轉發到后端web服務器（在反向代理模式下），
Response headers (3)
The response headers phase takes place after response headers become available but before a response body is read. The rules that need to decide whether to inspect a re- sponse body should run in this phase.
回應頭階段發生在回應頭可用之后，但在讀取回應體之前，需要決定是否檢查回應主體的規則應該在這個階段運行，
Response body (4)
The response body phase is the main response analysis phase. By the time this phase begins, the response body will have been read and all its data made available for the rules to make their decisions.
回應體階段是主要的回應分析階段，到這個階段開始時，回應體已經被讀取，并且所有的資料都可以供規則做出決定，
Logging (5)
The logging phase is special. It’s the only phase from which you cannot block. By the time this phase runs, the transaction will have ?nished, so there’s little you can do but record the fact that it happened. Rules in this phase are run to control how logging is performed or to save information in persistent storage.
日志記錄階段是特殊的，這是你唯一無法阻止的階段，到這個階段運行時，事務將完成，所以除了記錄它發生的事實之外，您幾乎無能為力，此階段中的規則用于控制如何執行日志記錄或將資訊保存在持久性存盤中，
圖示
ModSecurity 事務生命周期的5個階段圖示如下，
The End.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/5370.html
標籤：訊息安全
下一篇：Zabbix安裝部署實踐