denial (status:404).

For example:
SecRule ARGS "<script>" log,deny,status:404

Transaction Lifecycle

modsecurity生命週期
Transaction Lifecycle
In ModSecurity, every transaction goes through 5 steps, or phases. In each of the phases,ModSecurity will do some work at the beginning (e.g., parse data that has become avilable),invoke the rules specified to work in that phase, and perhaps do a thing or two after thephase rules have finished. At first glance, it may seem that 5 phases are too many, but there’s a reason why each of the phases exist. There is always one thing, sometimes several, that can
only be done at a particular moment in the transaction lifecycle.

分五個步驟：

Request Headers (1)
The request headers phase is the first entry point for ModSecurity. The principalpurpose of this phase is to allow rule writers to assess a request before the costlyrequest body processing is undertaken. Similarly, there is often a need to influencehow ModSecurity will process a request body, and this phase is the place to do it. Forexample, ModSecurity will not parse an XML request body by default, but you caninstruct it do so by placing the appropriate rules into phase 1. (If you care about XMLprocessing, it is described in detail in Chapter 12, Handling XML).

Request Body (2)
The request body phase is the main request analysis phase and takes place immediatellyafter a complete request body has been received and processed. The rules in thisphase have all the available request data at their disposal.

Response Headers (3)
The response headers phase takes place after response headers become available, butbefore a response body is read. The rules that need to decide whether to inspect aresponse body should run in this phase.

Response Body (4)
The response body phase is the main response analysis phase. By the time this phasebegins, the response body will have been read, with all its data available for the rulesto make their decisions.

Logging (5)
The logging phase is special, in more ways than one. First, it’s the only phase fromwhich you cannot block. By the time this phase runs, the transaction will havefinished, so there’s little you can do but record the fact that it happened. Rules in thisphase are run to control how logging is done.

處理流程例子：

POST /?a=test HTTP/1.0
Content-Type: application/x-www-form-urlencoded

Content-Length: 6
b=test
The response is entirely unremarkable:
HTTP/1.1 200 OK
Date: Sun, 17 Jan 2010 00:13:44 GMT
Server: Apache
Content-Length: 12
Connection: close
Content-Type: text/html
Hello World!

ModSecurity is first invoked by Apache after request headers become available, but beforea request body (if any) is read. First comes the initialization message, which contains theunique transaction ID generated by mod_unique_id. Using this information, you should beable to pair the information in the debug log with the information in your access and auditlogs. At this point, ModSecurity will parse the information on the request line and in therequest headers. In this example, the query string part contains a single parameter (a), soyou will see a message documenting its discovery. ModSecurity will then create a transactioncontext and invoke the REQUEST_HEADERS phase:
[4] Initialising transaction (txid SopXW38EAAE9YbLQ).
[5] Adding request argument (QUERY_STRING): name "a", value "test"
[4] Transaction context created (dcfg 8121800).
[4] Starting phase REQUEST_HEADERS.

Assuming that a rule didn’t block the transaction, ModSecurity will now return control toApache, allowing other modules to process the request before control is given back to it.In the second phase, ModSecurity will first read and process the request body, if it is present.In the following example, you can see three messages from the input filter, which tell youwhat was read. The fourth message tells you that one parameter was extracted from therequest body. The content type used in this request (application/x-www-form-urlencoded)is one of the types ModSecurity recognizes and parses automatically. Once the request bodyis processed, the REQUEST_BODY rules are processed.
[4] Second phase starting (dcfg 8121800).
[4] Input filter: Reading request body.
[9] Input filter: Bucket type HEAP contains 6 bytes.
[9] Input filter: Bucket type EOS contains 0 bytes.
[5] Adding request argument (BODY): name "b", value "test"
[4] Input filter: Completed receiving request body (length 6).
[4] Starting phase REQUEST_BODY.

The filters that keep being mentioned in the logs are parts of ModSecurity that handle requestand response bodies:
[4] Hook insert_filter: Adding input forwarding filter (r 81d0588).
[4] Hook insert_filter: Adding output filter (r 81d0588).

There will be a message in the debug log every time ModSecurity sends a chunk of data tothe request handler, and one final message to say that there isn’t any more data in the buffers.
[4] Input filter: Forwarding input: mode=0, block=0, nbytes=8192…
(f 81d2228, r 81d0588).
[4] Input filter: Forwarded 6 bytes.
[4] Input filter: Sent EOS.
[4] Input filter: Input forwarding complete.Shortly thereafter, the output filter will start receiving data, at which point the

RESPONSE_HEADERS rules will be invoked:
[9] Output filter: Receiving output (f 81d2258, r 81d0588).
[4] Starting phase RESPONSE_HEADERS.
Once all the rules have run, ModSecurity will continue to store the response body in its
buffers, after which it will run the RESPONSE_BODY rules:
[9] Output filter: Bucket type MMAP contains 12 bytes.
[9] Output filter: Bucket type EOS contains 0 bytes.
[4] Output filter: Completed receiving response body (buffered full - 12 bytes).
[4] Starting phase RESPONSE_BODY.

Again, assuming that none of the rules blocked, the accumulated response body will beforwarded to the client:
[4] Output filter: Output forwarding complete.Finally, the logging phase will commence. The LOGGING rules will be run first to allow them toinfluence logging, after which the audit logging subsystem will be invoked to log the transactionif necessary. A message from the audit logging subsystem will be the last transactionmessage in the logs. In this example, ModSecurity tells us that it didn’t find anything ofinterest in the transaction and that it sees no reason to log it:
[4] Initialising logging.
[4] Starting phase LOGGING.
[4] Audit log: Ignoring a non-relevant request.