ModSecurity3未进入requestbody检查阶段

# -- Rule engine initialization ----------------------------------------------                                                    



# Enable ModSecurity, attaching it to every transaction. Use detection

# only to start with, because that minimises the chances of post-installation

# disruption.

#

SecRuleEngine On





# -- Request body handling ---------------------------------------------------



# Allow ModSecurity to access request bodies. If you don&＃039;t, ModSecurity

# won&＃039;t be able to see any POST parameters, which opens a large security

# hole for attackers to exploit.

#

SecRequestBodyAccess On





SecDefaultAction "phase:1,pass,log,tag:&＃039;Local Lab Service&＃039;"

SecDefaultAction "phase:2,pass,log,tag:&＃039;Local Lab Service&＃039;"



# Enable XML request body parser.

# Initiate XML Processor in case of xml content-type

#

SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\&＃043;|/)|text/)xml" \

     "id:&＃039;200000&＃039;,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor&＃061;XML"



# Enable JSON request body parser.

# Initiate JSON Processor in case of JSON content-type; change accordingly

# if your application does not use &＃039;application/json&＃039;

#

SecRule REQUEST_HEADERS:Content-Type "application/json" \

     "id:&＃039;200001&＃039;,phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor&＃061;JSON"



# Maximum request body size we will accept for buffering. If you support

# file uploads then the value given on the first line has to be as large

# as the largest file you are willing to accept. The second value refers

# to the size of data, with files excluded. You want to keep that value as

# low as practical.

#

SecRequestBodyLimit 13107200

SecRequestBodyNoFilesLimit 131072



# What to do if the request body size is above our configured limit.

# Keep in mind that this setting will automatically be set to ProcessPartial

# when SecRuleEngine is set to DetectionOnly mode in order to minimize

# disruptions when initially deploying ModSecurity.

#

SecRequestBodyLimitAction Reject



# Verify that we&＃039;ve correctly processed the request body.

# As a rule of thumb, when failing to process a request body

# you should reject the request (when deployed in blocking mode)

# or log a high-severity alert (when deployed in detection-only mode).

#

SecRule REQBODY_ERROR "!&＃064;eq 0" \

"id:&＃039;200002&＃039;, phase:2,t:none,log,deny,status:400,msg:&＃039;Failed to parse request body.&＃039;,logdata:&＃039;%{reqbody_error_msg}&＃039;,severity:2"



# By default be strict with what we accept in the multipart/form-data

# request body. If the rule below proves to be too strict for your

# environment consider changing it to detection-only. You are encouraged

# _not_ to remove it altogether.

#

SecRule MULTIPART_STRICT_ERROR "!&＃064;eq 0" \

"id:&＃039;200003&＃039;,phase:2,t:none,log,deny,status:400, \

msg:&＃039;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}&＃039;"



# See #1747 and #1924 for further information on the possible values for

# MULTIPART_UNMATCHED_BOUNDARY.

#

SecRule MULTIPART_UNMATCHED_BOUNDARY "&＃064;eq 1" \

    "id:&＃039;200004&＃039;,phase:2,t:none,log,deny,msg:&＃039;Multipart parser detected a possible unmatched boundary.&＃039;"





# PCRE Tuning

# We want to avoid a potential RegEx DoS condition

#

SecPcreMatchLimit 1000

SecPcreMatchLimitRecursion 1000



# Some internal errors will set flags in TX and we will need to look for these.

# All of these are prefixed with "MSC_".  The following flags currently exist:

#

# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.

#

SecRule TX:/^MSC_/ "!&＃064;streq 0" \

        "id:&＃039;200005&＃039;,phase:2,t:none,deny,msg:&＃039;ModSecurity internal error flagged: %{MATCHED_VAR_NAME}&＃039;"





# -- Response body handling --------------------------------------------------



# Allow ModSecurity to access response bodies.

# You should have this directive enabled in order to identify errors

# and data leakage issues.

#

# Do keep in mind that enabling this directive does increases both

# memory consumption and response latency.

#

SecResponseBodyAccess Off



# Which response MIME types do you want to inspect? You should adjust the

# configuration below to catch documents but avoid static files

# (e.g., images and archives).

#

SecResponseBodyMimeType text/plain text/html text/xml



# Buffer response bodies of up to 512 KB in length.

SecResponseBodyLimit 524288



# What happens when we encounter a response body larger than the configured

# limit? By default, we process what we have and let the rest through.

# That&＃039;s somewhat less secure, but does not break any legitimate pages.

#

SecResponseBodyLimitAction ProcessPartial



SecTmpDir /opt/waf/modsecurity/var/tmp



# The location where ModSecurity will keep its persistent data.  This default setting

# is chosen due to all systems have /tmp available however, it

# too should be updated to a place that other users can&＃039;t access.

#

SecDataDir /opt/waf/modsecurity/var/data





# -- File uploads handling configuration -------------------------------------



# The location where ModSecurity stores intercepted uploaded files. This

# location must be private to ModSecurity. You don&＃039;t want other users on

# the server to access the files, do you?

#

SecUploadDir /opt/waf/modsecurity/var/upload/



# By default, only keep the files that were determined to be unusual

# in some way (by an external inspection script). For this to work you

# will also need at least one file inspection rule.

#

SecUploadKeepFiles Off



# Uploaded files are by default created with permissions that do not allow

# any other user to access them. You may need to relax that if you want to

# interface ModSecurity to an external program (e.g., an anti-virus).

#

SecUploadFileMode 0600





# -- Debug log configuration -------------------------------------------------



# The default debug log configuration is to duplicate the error, warning

# and notice messages from the error log.

#

SecDebugLog /opt/waf/modsecurity/var/log/debug.log

SecDebugLogLevel 9



# -- Audit log configuration -------------------------------------------------



# Log the transactions that are marked by a rule, as well as those that

# trigger a server error (determined by a 5xx or 4xx, excluding 404,  

# level response status codes).

#

SecAuditEngine On

SecAuditLogRelevantStatus "^(?:5|4(?!04))"



# Log everything we know about a transaction.

SecAuditLogParts ABCDEFIJHZ



# Use a single file for logging. This is much easier to look at, but

# assumes that you will use the audit log only ocassionally.

#

SecAuditLogType Serial

SecAuditLog /opt/waf/modsecurity/var/audit/audit.log



# Specify the path for concurrent audit logging.

SecAuditLogStorageDir /opt/waf/modsecurity/var/audit/





# -- Miscellaneous -----------------------------------------------------------



# Use the most commonly used application/x-www-form-urlencoded parameter

# separator. There&＃039;s probably only one application somewhere that uses

# something else so don&＃039;t expect to change this value.

#

SecArgumentSeparator &



# Settle on version 0 (zero) COOKIEs, as that is what most applications

# use. Using an incorrect COOKIE version may open your installation to

# evasion attacks (against the rules that examine named COOKIEs).

#

SecCOOKIEFormat 0



# Specify your Unicode Code Point.

# This mapping is used by the t:urlDecodeUni transformation function

# to properly map encoded data to your language. Properly setting

# these directives helps to reduce false positives and negatives.

#

SecUnicodeMapFile unicode.mapping 20127



# Improve the quality of ModSecurity by sharing information about your

# current ModSecurity version and dependencies versions.

# The following information will be shared: ModSecurity version,

# Web Server version, APR version, PCRE version, Lua version, Libxml2

# version, Anonymous unique id for host.

SecStatusEngine On

curl -d "name&＃061;tom&password&＃061;123" http://localhost

POST / HTTP/1.1

User-Agent: curl/7.29.0

Host: localhost:8080

Accept: */*

Content-Length: 21

Content-Type: application/x-www-form-urlencoded



name&＃061;tom&password&＃061;123

[1617093957] [] [4] Initializing transaction

[1617093957] [] [4] Transaction context created.

[1617093957] [] [4] Starting phase CONNECTION. (SecRules 0)

[1617093957] [] [9] This phase consists of 0 rule(s).

[1617093957] [] [4] Starting phase URI. (SecRules 0 &＃043; 1/2)

[1617093957] [/] [4] Starting phase REQUEST_HEADERS.  (SecRules 1)

[1617093957] [/] [9] This phase consists of 2 rule(s).

[1617093957] [/] [4] (Rule: 200000) Executing operator "Rx" with param "(?:application(?:/soap\&＃043;|/)|text/)xml" against REQUEST_HEADERS:Content-Type.

[1617093957] [/] [9]  T (0) t:lowercase: "application/x-www-form-urlencoded"

[1617093957] [/] [9] Target value: "application/x-www-form-urlencoded" (Variable: REQUEST_HEADERS:Content-Type)

[1617093957] [/] [4] Rule returned 0.

[1617093957] [/] [9] Matched vars cleaned.

[1617093957] [/] [4] (Rule: 200001) Executing operator "Rx" with param "application/json" against REQUEST_HEADERS:Content-Type.

[1617093957] [/] [9]  T (0) t:lowercase: "application/x-www-form-urlencoded"

[1617093957] [/] [9] Target value: "application/x-www-form-urlencoded" (Variable: REQUEST_HEADERS:Content-Type)

[1617093957] [/] [4] Rule returned 0.

[1617093957] [/] [9] Matched vars cleaned.

[1617093957] [/] [4] Starting phase RESPONSE_HEADERS. (SecRules 3)

[1617093957] [/] [9] This phase consists of 0 rule(s).

[1617093957] [/] [9] Appending response body: 27 bytes. Limit set to: 524288.000000

[1617093957] [/] [4] Starting phase RESPONSE_BODY. (SecRules 4)

[1617093957] [/] [4] Response body is disabled, returning... 1

[1617093957] [/] [4] Starting phase LOGGING. (SecRules 5)

[1617093957] [/] [9] This phase consists of 0 rule(s).

[1617093957] [/] [8] Checking if this request is suitable to be saved as an audit log.

[1617093957] [/] [8] Checking if this request is relevant to be part of the audit logs.

[1617093957] [/] [5] Saving this request as part of the audit logs.

[1617093957] [/] [8] Request was relevant to be saved. Parts: 6014

---WLT7wZWS---A--

[30/Mar/2021:16:45:57 &＃043;0800] 1617093957 127.0.0.1 53020 127.0.0.1 80

---WLT7wZWS---B--

POST / HTTP/1.1

User-Agent: curl/7.29.0

Host: localhost

Accept: */*

Content-Length: 21

Content-Type: application/x-www-form-urlencoded



---WLT7wZWS---D--



---WLT7wZWS---E--

Thank you for requesting /\x0a



---WLT7wZWS---F--

HTTP/1.1 200

Server: nginx/1.19.7

Date: Tue, 30 Mar 2021 08:45:57 GMT

Content-Length: 27

Content-Type: text/plain

Connection: keep-alive



---WLT7wZWS---H--



---WLT7wZWS---I--



---WLT7wZWS---J--



---WLT7wZWS---Z--