○構文
SecRequestBodyAccess On/Off
　
・リクエストボディをバッファーして、ModSecurityによって処理するか指定。
　
・HTTP POSTリクエストのリクエストボディのデータをチェックします。
　
・信頼性のあるブロッキングを実施するためにリクエストをバッファリングする必要があります。

○構文
SecRule VARIABLES OPERATOR [ACTIONS]
　
・ACTIONSが指定されていない場合は、デフォルトのアクションリストが使用されます。
　
・デフォルトのアクションのリストは、SecDefaultActionで設定できます。
　
・デフォルトのアクションリストは、phase:2,log,auditlog,pass
　
①VARIABLES
　
このルールの検証対象を指定
下記がサポートされています。
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Variables
ARGS、ARGS_COMBINED_SIZE、ARGS_GET、ARGS_GET_NAMES、ARGS_NAMES、ARGS_POST、ARGS_POST_NAMES、AUTH_TYPE、DURATION、ENV、FILES、FILES_COMBINED_SIZE、FILES_NAMES、FULL_REQUEST、FULL_REQUEST_LENGTH、FILES_SIZES、FILES_TMPNAMES、GEO、HIGHEST_SEVERITY、INBOUND_DATA_ERROR、MATCHED_VAR、MATCHED_VARS、MATCHED_VAR_NAME、MATCHED_VARS_NAMES、MODSEC_BUILD、MULTIPART_CRLF_LF_LINES、MULTIPART_FILENAME、MULTIPART_NAME、MULTIPART_STRICT_ERROR、MULTIPART_UNMATCHED_BOUNDARY、OUTBOUND_DATA_ERROR、PATH_INFO、PERF_COMBINED、PERF_GC、PERF_LOGGING、PERF_PHASE1、PERF_PHASE2、PERF_PHASE3、PERF_PHASE4、PERF_PHASE5、PERF_RULES、PERF_SREAD、PERF_SWRITE、QUERY_STRING、REMOTE_ADDR、REMOTE_HOST、REMOTE_PORT、REMOTE_USER、REQBODY_ERROR、REQBODY_ERROR_MSG、REQBODY_PROCESSOR、REQUEST_BASENAME、REQUEST_BODY、REQUEST_BODY_LENGTH、REQUEST_COOKIES、REQUEST_COOKIES_NAMES、REQUEST_FILENAME、REQUEST_HEADERS、REQUEST_HEADERS_NAMES、REQUEST_LINE、REQUEST_METHOD、REQUEST_PROTOCOL、REQUEST_URI、REQUEST_URI_RAW、RESPONSE_BODY、RESPONSE_CONTENT_LENGTH、RESPONSE_CONTENT_TYPE、RESPONSE_HEADERS、RESPONSE_HEADERS_NAMES、RESPONSE_PROTOCOL、RESPONSE_STATUS、RULE、SCRIPT_BASENAME、SCRIPT_FILENAME、SCRIPT_GID、SCRIPT_GROUPNAME、SCRIPT_MODE、SCRIPT_UID、SCRIPT_USERNAME、SDBM_DELETE_ERROR、SERVER_ADDR、SERVER_NAME、SERVER_PORT、SESSION、SESSIONID、STREAM_INPUT_BODY、STREAM_OUTPUT_BODY、TIME、TIME_DAY、TIME_EPOCH、TIME_HOUR、TIME_MIN、TIME_MON、TIME_SEC、TIME_WDAY、TIME_YEAR、TX、UNIQUE_ID、URLENCODED_ERROR、USERID、USERAGENT_IP、WEBAPPID、WEBSERVER_ERROR_LOG、XML
　
②OPERATOR
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Operators
このルールの検証対象をどのようにチェックするかを指定。
下記がサポートされています。
　
beginsWith、contains、containsWord、detectSQLi、detectXSS、endsWith、eq、ge、geoLookup、gsbLookup、gt、inspectFile、ipMatch、ipMatchF、ipMatchFromFile、le、lt、pm、pmf、pmFromFile、rbl、rsub、rx、streq、strmatch、validateByteRange、validateDTD、validateHash、validateSchema、validateUrlEncoding、validateUtf8Encoding、verifyCC、verifyCPF、verifySSN、within
　
③ACTIONS
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#Actions
下記がサポートされています。
　
accuracy、allow、append、auditlog、block、capture、chain、ctl、deny、deprecatevar、drop、exec、expirevar、id、initcol、log、logdata、maturity、msg、multiMatch、noauditlog、nolog、pass、pause、phase、prepend、proxy、redirect、rev、sanitiseArg、sanitiseMatched、sanitiseMatchedBytes、sanitiseRequestHeader、sanitiseResponseHeader、severity、setuid、setrsc、setsid、setenv、setvar、skip、skipAfter、status、t、tag、ver、xmlns

SecRuleで指定するアクションは５つのグループに分ける事が出来ます。
　
①Disruptiveアクション
　
・ModSecurityに何らかの動作を引き起こすアクション。
　
多くの場合は、トランザクションのブロックを意味しますが、それがすべてではありません。
　
例えば、”allow”アクションはDisruptiveに分類されるが、ブロッキングの反対というわけではありません。
　
Disruptiveアクションは、一つのルール、またはチェイン内に１Disruptiveアクションのみ作用します。複数のDisruptiveアクションがある場合は最後の一つのみが作用します。
　
・Disruptiveアクションは、SecRuleEngineの設定値が”DetectionOnly”の場合は実行されません。
　
・”allow”アクションを使用するexception/whitelistingルールを作成している場合は、ctl:ruleEngine=Onアクションを追加しなければなりません。
　
②Non-disruptiveアクション
　
・作用はするが、ルールプロセスフローに影響は与えません。
　
・variableをセットしたり、その値を変更するといった目的で使用されるアクション。
　
③Flowアクション
　
・ルールフローに影響を与えるアクション。（skip、skipAfterなど）
　
④Meta-dataアクション
　
・ルールについてより詳細な情報を供給する場合に使用。（id、rev、severity、msgなど）
　
⑤Dataアクション
　
・アクションというより、他のアクションによって使用するためにデータを保持するためのコンテナとしての役割。
　
“status”アクションは、”blocking”アクションで判定するためにスタータス情報を保持します。

①URLエンコーディング
　
SecRule REQUEST_URI_RAW “@validateUrlEncoding” “id:192″
　
●このルールの検証対象：REQUEST_URI_RAW
　
・ドメイン名、クエリー文字を含むフルリクエストURL（例、http://www.example.com/index.php?p=X）
　
●どのようにチェックするか？@validateUrlEncoding
　
（リファレンスを読んでもよく分からなかったのでとりあえず無理やり直訳しました。）
　
・ModSecurityは、リクエストパラメータ内のURLエンコードされたキャラクタを自動でデコードします。
　
しかし、何度もURLエンコードされるリクエストパラメータもあります。
　
このオペレータは、raw inputまたはURLエンコードされたインプットに対して使用します。
　
例えば、あるアプリはクッキーをURLエンコードしますが、標準に従っていません。標準ではないので、ModSecurityはそういうエンコードを確認したり解析したりしません。
　
●アクション：”id:nnn”
　
・ルールまたはチェインに一意のIDを割り当てます。
　
1-99,999　ローカル、内部で使用する
　
②マルチパートフォーム
　
SecRule MULTIPART_STRICT_ERROR “!@eq 0” \
“phase:2,t:none,log,deny,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_SEMICOLON_MISSING}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IQ %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
IH %{MULTIPART_FILE_LIMIT_EXCEEDED}'”
　
●このルールの検証対象：MULTIPART_STRICT_ERROR
　
・この変数は、下記変数がセットされている場合に１にセットされます。
　
REQBODY_PROCESSOR_ERROR
MULTIPART_BOUNDARY_QUOTED
MULTIPART_BOUNDARY_WHITESPACE
MULTIPART_DATA_BEFORE
MULTIPART_DATA_AFTER
MULTIPART_HEADER_FOLDING
MULTIPART_LF_LINE
MULTIPART_MISSING_SEMICOLON
MULTIPART_INVALID_QUOTING
MULTIPART_INVALID_HEADER_FOLDING
MULTIPART_FILE_LIMIT_EXCEEDED
　
・上記変数は、multipart/form-dataリクエストボディ内のイレギュラーな挙動（規約通りの場合も含む）を検知した場合にセットされます。
　
・この変数をチェックするルールは常に含めるべきです。
　
・このルールが検知された場合にブロックするか警告のみにするか、false positives（安全なパケットも検出）の割合を考慮して決めます。
　
●どのようにチェックするか？　”!@eq 0″
　
・上記変数のリストが0になっているかチェック
　
●アクション：”phase:2,t:none,log,deny,msg:・・
　
・phase
ルールまたはチェインを利用可能なプロセスフェーズに割り当てる。
2 – request
4 – response
5 – logging
　
・t:none
ルール内のマッチングの前に変数の値を変換する関数を指定。
t:noneを指定してデフォルトに従うことを推奨
　
・log
このルールにマッチした場合にログに記録するかどうか指定
　
・deny
ルールの処理を停止し、トランザクションをインターセプトする。
　
・msg
ログに記録されるメッセージにカスタムメッセージを割り当てる。
　
③マルチパートboundary
　
multipart/request-body部のboundaryに関するルール設定です。
　
SecRule MULTIPART_UNMATCHED_BOUNDARY “!@eq 0” “phase:2,t:none,log,deny,msg:’Multipart parser detected a possible unmatched boundary.'”
　
●このルールの検証対象：MULTIPART_UNMATCHED_BOUNDARY
　
・multipart/request-body部を解析中に、boundaryであるはずの部分がそうでなかった場合に検知するようです。
　
オンラインマニュアルの下記部分の意味が分からなかったのでそのまま転記しました。
Such an event may occur when evasion of ModSecurity is attempted.
　
●どのようにチェックするか？　”!@eq 0″
　
・上記変数のリストが0になっているかチェック
　
●アクション：”phase:2,t:none,log,deny,msg:・・
　
・phase
ルールまたはチェインを利用可能なプロセスフェーズに割り当てる。
2 – request
4 – response
5 – logging
　
・t:none
ルール内のマッチングの前に変数の値を変換する関数を指定。
t:noneを指定してデフォルトに従うことを推奨
　
・log
このルールにマッチした場合にログに記録するかどうか指定
　
・deny
ルールの処理を停止し、トランザクションをインターセプトする。
　
・msg
ログに記録されるメッセージにカスタムメッセージを割り当てる。
　
④PCRE_LIMITS_EXCEEDED
　
PCREライブラリのmatchリミットの超過などの内部エラーを検知するルールです。
　
SecRule TX:/^MSC_/ “!@streq 0” “phase:2,t:none,deny,msg:’ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'”
　
●このルールの検証対象：TX:/^MSC_/
　
・TX変数には、トランザクション実行中の一時変数としてデータなどが保持されます。
　
・内部エラーが発生した際に、このTX変数にフラグが設定されます。
　
・先頭が”MSC_”のフラグをチェックしています。
　
・現時点では、”MSC_PCRE_LIMITS_EXCEEDED”というフラグがあり、”SecPcreMatchLimit”（PCREライブラリのmatchリミット）を超過するとフラグがセットされます。
　
●どのようにチェックするか？　”!@streq 0″
　
・上記変数のリストが0になっているかチェック
　
●アクション：”phase:2,t:none,log,deny,msg:・・
　
・phase
ルールまたはチェインを利用可能なプロセスフェーズに割り当てる。
2 – request
4 – response
5 – logging
　
・t:none
ルール内のマッチングの前に変数の値を変換する関数を指定。
t:noneを指定してデフォルトに従うことを推奨
　
・log
このルールにマッチした場合にログに記録するかどうか指定
　
・deny
ルールの処理を停止し、トランザクションをインターセプトする。
　
・msg
ログに記録されるメッセージにカスタムメッセージを割り当てる。
　
⑤SecUploadFileLimit
　
SecUploadFileLimit 10
　
・マルチパートPOST内で処理される最大のファイルアップロード数を定義します。
　
・デフォルトは100ですが、少なくすることを推奨。
　
・この上限を超過しても超過したファイルが抜き取られる事はなく、下記フラグがセットされます。チェックの漏れが起きないように下記フラグのいずれかをチェックしなければなりません。
MULTIPART_FILE_LIMIT_EXCEEDED
MULTIPART_STRICT_ERROR
　
・上限を超過した場合、part名とファイル名は、”FILES_NAMES”、”FILES”変数にセットされ、ファイルサイズは、”FILES_SIZES”変数にセットされます。
　
一方、一時ファイルが作成されないので”FILES_TMPNAMES”変数にはセットされません。
　
⑥AuditLog
　
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogType Serial
SecAuditLogParts ABIFHZ
SecAuditLog /var/log/httpd/modsec_audit.log
　
●SecAuditEngine On/Off/RelevantOnly
　
監査ログエンジンを設定
　
・On
すべてのトランザクションをログ記録
　
・Off
どのトランザクションもログ記録しない。
　
・RelevantOnly
警告、エラー、または妥当なステータスコードを持つトランザクションのみログ記録
　
●SecAuditLogRelevantStatus
　
どのレスポンスステータスコードを監査ログの対象とするか指定
　
●SecAuditLogType Serial/Concurrent
　
監査ログのタイプを指定
　
・Serial
“SecAuditLog”で指定されるファイル内に記録します。
一つの監査ログエントリーをその都度ファイルに書き込むのでサーバーが遅くなります。
　
・Concurrent
トランザクション単位で一つのファイルを使用。複数のトランザクションは、並行して書き込む事が出来ます。
　
●SecAuditLogParts
　
監査ログのフォーマット
　
A: Audit log header
B: Request headers
I: Request body（multipart/form-dataエンコードの場合は、擬似的なapplication/x-www-form-urlencoded body ）
F: Final response headers
H: Audit log trailer
Z: Final boundary, signifies the end of the entry
　
●SecAuditLog
　
監査ログファイルのパス
　
⑦SecRequestBody、SecResponseBody
　
SecRequestBodyLimit 131072
SecRequestBodyInMemoryLimit 131072
SecResponseBodyLimit 524288
　
●SecRequestBodyLimit
　
・リクエストボディをバッファする最大値
　
・超過するとステータスコード413（Request Entity Too Large）で拒否します。
　
●SecRequestBodyInMemoryLimit
　
・リクエストボディをメモリー内に保存する最大値
　
・multipart/form-dataリクエストを処理しているときにこの上限に達するとディスク上の一時ファイルで処理するようになります。
　
●SecResponseBodyLimit
　
・レスポンスボディをバッファする最大値
　
・この上限を超過した場合は、ステータスコード500（Internal Server Error）で拒否します
　
・この設定は、バッファー用に選択されていないMIMEタイプのレスポンスには影響を与えません。