WAF Policy

This menu lists the custom policies in effect by mod_security.

It allows you to create new one on the fly, and you can fine tune them.

Main settings

Fiendly name: The name of the policy.

Enable body inspection: Toggle the body parsing (CPU intensive).
This option will enable or disable the SecRequestBodyAccess ModSecurity directive.
This directive is required if you use a RuleSet like OWASP-RS or Vulture-RS in your application.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRequestBodyAccess for more informations about this option.

Enable content injection: Toggle the content injection (CPU intensive)
This option will enable or disable the SecContentInjection and SecStreamOutBodyInspection ModSecurity directives.
This option is required if you use a RuleSet like OWASP-RS or Vulture-RS in your application.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRequestBodyAccess and https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecStreamOutBodyInspection for more information about this option.

Disable backend compression: Disable compression.
This option will enable or disable the SecDisableBackendCompression ModSecurity directive.
That one is required if you have "body inspection" and/or "content injection" enabled, as well as to use OWASP-RS or Vulture-RS.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecDisableBackendCompression for more information about this option.

Validate UTF8 Encoding: Toggle the parsing and validation of the UTF8 encoding compliance.
Enable that option will set the ModSecurity variable "tx.crs_validate_utf8_encoding=1".
You have to use the OWASP-RS in your application to enable this option.

XML Inspection: Validate the XML structure correctness.
Enable that option will set the ModSecurity variable "tx.requestBodyProcessor=XML".
You have to use the OWASP-RS in your application to enable this option.

Block invalid body: Returns 400 (Invalid request) status code is body is detected as invalid.
This option enable the following ModSecurity directive:
SecRule REQBODY_ERROR "@eq 1" \ "id:'95',phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
The REQBODY_ERROR variable is set in the OWASP Core Rules Set, so you have to use the OWASP-RS in your application to verify the body correctness.

Connections engine: Toggle the rule, or set it up as detection only to log only.
This option will modify the SecConnEngine ModSecurity directive.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecConnEngine for more information about this option.

Audit Engine: Log level, enable/disable or only log if revelant.
This option will modify the SecAuditEngine ModSecurity directive.
This directive is used to configure the audit engine, which logs complete transactions.
Three options are available :

Relevant status code: This option is used if the last option is configured with the value "RelevantOnly".
It will set the SecAuditLogRelevantStatus directive.
The default regex "^(?:5|4(?!04))" means that all 4xx and 5xx status code will be logged, except for 404s.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecAuditLogRelevantStatus for more informations about this option.

Logging Mode: Select the log file, audit_log, error_log or both
This option will modify the SecDefaultAction ModSecurity directive.
Three options are available :
Both, this will set the directive with the value : SecDefaultAction "phase:2,pass,log"
Audit logs, this will set the directive with the value : SecDefaultAction "phase:2,pass,nolog,auditlog"
Apache error logs, this will set the directive with the value : SecDefaultAction "phase:2,pass,log,noauditlog"
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecDefaultAction for more informations about this option.

Enable Mod Defender: Toggle the activation of Mod Defender.
This option will enable or disable the Defender ModDefender directive.
This directive is required if you want to use :

Enable Generic SQL Detection: Toggle the activation of LibinjectionSQL.
This option will enable or disable the LibinjectionSQL ModDefender directive.
That directive will activate the use of the libinjection library.
The last option must be enabled to use that one.
See https://www.vultureproject.org/doc/waf/waf.html for more informations about libinjection.

Enable Generic XSS Detection: Toggle the activation of LibinjectionXSS.
This option will enable or disable the LibinjectionXSS ModDefender directive.
That directive will activate the use of the libinjection library.
The "Enable Mod Defender" option must be enabled to use that one.
See https://www.vultureproject.org/doc/waf/waf.html for more informations about libinjection.

Scoring

Each HTTP request begins with an anomaly score of 0 and is incremented each time a rule match.
If a threshold (inbound or outbound) is reaches, corresponding actions are triggered.
Security Level: Increase or decrease the anomal score threshold depending on the security level.
Block desktop users User-Agent: Enable this toggle will set the variable "ua_browser_anomaly_score" to 999, which means that if the user-agent is detected as "Desktop user", the anomaly score will be increased by 999, and reach the threshold an block the request.
Block crawlers User-Agent: Enable this toggle will set the variable "ua_crawler_anomaly_score" to 999, which means that if the user-agent is detected as "Desktop user", the anomaly score will be increased by 999, and reach the threshold and block the request.
If this toggle is not enabled, the anomaly score will be incremented by 2 in case of detecting the User-Agent as a crawler.
Block suspicious User-Agent: Enable this toggle will set the following variable to 999:
ua_unknown_anomaly_score, ua_anonymous_anomaly_score, ua_bot_anomaly_score, ua_console_anomaly_score, ua_emailclient_anomaly_score, ua_emailharvester_anomaly_score, ua_script_anomaly_score
which means that if the user-agent is detected as "Unknown" or "Anonymous" or "Bot" or "Console" or "emailclient" or "emailharvester" or "script", the anomaly score will be increased by 999, and reach the threshold and block the request.
If this toggle is not enabled, the scores will be set to 2 by default.

Critical anomaly score: The score added to the anomaly score when a critical rule match.
Error anomaly score: The score added to the anomaly score when an error rule match.
Warning anomaly score: The score added to the anomaly score when a warning rule match<.br/> Notice anomaly score: The score added to the anomaly score when a notice rule match.
Block if global score exceeds: The score threshold that when reached will block the request.

HTTP Policy

Maximum number of arguments in request: The maximum number of parameters in the request.
This value will be set by the following ModSecurity directives :
SecAction "id:'6', phase:2, t:none, setvar:tx.max_num_args={{policy.max_num_args}}, nolog, pass"
This 2 variables will be used by the OWASP Rules Set, more precisely by the file modsecurity_crs_23_request_limits.conf.
You need to enable the OWASP-RS in your application to block the request if that value is reached.

Maximum argument name length: The maximum name length for each request parameters.
This value will be set by the following ModSecurity directive:
SecAction "id:'7', phase:2, t:none, setvar:tx.arg_name_length={{policy.arg_name_length}}, nolog, pass"
This 2 variables will be used by the OWASP Rules Set, more precisely by the file modsecurity_crs_23_request_limits.conf.
You need to enable the OWASP-RS in your application to block the request if that value is reached.

Maximum arguments value length: The maximum value length for each request parameters.
This value will be set by the following ModSecurity directive:
SecAction "id:'8', phase:2, t:none, setvar:tx.arg_length={{policy.arg_length}}, nolog, pass" This variable will be used by the OWASP Rules Set, more precisely by the file modsecurity_crs_23_request_limits.conf.
You need to enable the OWASP-RS in your application to block the request if that value is reached.

Maximum arguments value total length: The request arguments total length.
This value will be set by the following ModSecurity directive:
SecAction "id:'9', phase:2, t:none, setvar:tx.total_arg_length={{policy.total_arg_length}}, nolog, pass" This variable will be used by the OWASP Rules Set, more precisely by the file modsecurity_crs_23_request_limits.conf.
You need to enable the OWASP-RS in your application to block the request if that value is reached.

Request body limit: The request body length limit.
This value will be set by the following ModSecurity directive:
SecRequestBodyNoFilesLimit {{policy.request_body_limit}} And by the following ModDefender directive:
RequestBodyLimit {{ policy.request_body_limit }} If this variable is reached, ModDefender will send a 403 HTTP code response, and if ModDefender is disable, ModSecurity will send a 413 (Request entity too large) HTTP code response.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRequestBodyNoFilesLimit for more informations about the ModSecurity directive,
and see https://www.vultureproject.org/doc/waf/waf.html for more informations about ModDefender directive.

Maximum file size, in bytes: The maximum files size allowed to upload.
This value will be set by the following ModSecurity directive:
SecRequestBodyLimit {{policy.max_file_size}} If this variable is reached by the "Content-Length" header value, ModSecurity will send a 413 (Request entity too large) HTTP code response.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecRequestBodyLimit for more informations about the ModSecurity directive.

Maximum combined file size, in bytes: The maximum file size allowed to upload.
This value will be set by the following ModSecurity directive:
SecAction "id:'11', phase:2, t:none, setvar:tx.combined_file_sizes={{policy.combined_file_sizes}}, nolog, pass"
And will be, in the OWASP Core Rules Set, compared to the ModSecurity variable "FILES_COMBINED_SIZE". If that value is reached, the anomaly score will be incremented by the "critical_anomaly_score" value.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#FILES_COMBINED_SIZE for more information about that ModSecurity macro.

Allowed HTTP versions: Allowed HTTP protocol versions.
This value will be set by the following ModSecurity directive:
setvar:tx.allowed_http_versions={{policy.allowed_http_versions}}
If a non allowed method is detected, the anomaly score will be incremented by the "warning anomaly score" value by the OWASP-RS, more precisely in the file REQUEST-920-PROTOCOL-ENFORCEMENT.conf
and incremented by the "critical anomaly score" value by the Vulture-RS.

Allowed request content type: Allowed Content-Type headers.
This value will be set by the following ModSecurity directive: setvar:tx.allowed_request_content_type={{policy.allowed_request_content_type}} If a non allowed Content-Type header is detected, the anomaly score will be incremented by the "warning anomaly score" value by the OWASP-RS, more precisely in the file REQUEST-920-PROTOCOL-ENFORCEMENT.conf
and incremented by the "critical anomaly score" by the Vulture-RS.

Restricted extensions: The file extension allowed for requested files.
This value will be set by the following ModSecurity directive: setvar:tx.restricted_extensions={{policy.restricted_extensions}} If a non allowed requested file extension is detected, the anomaly score will be incremented by the "critical anomaly score" value by the OWASP-RS, more precisely in the file REQUEST-920-PROTOCOL-ENFORCEMENT.conf
and incremented by the "critical anomaly score" by the Vulture-RS.

Restricted headers: Restricted (allowed) headers name.
This value will be set by the following ModSecurity directive: setvar:tx.restricted_headers={{policy.restricted_headers}} If a non allowed header name is detected, the anomaly score will be incremented by the "critical anomaly score" value by the OWASP-RS, more precisely in the file REQUEST-920-PROTOCOL-ENFORCEMENT.conf
and incremented by the "critical anomaly score" by the Vulture-RS.

DOS & BF Protection

You can here define an anti DOS policy by specifying the protected urls (or all), the burst time period, the threshold and the block timeout.
The first rule is a default protection for all the URLs.
If a client request the specified URL more than "DOS Counter threshold" times within a period of "DOS Burst Time Slice" seconds, he will be blocked for a period of "DOS Block Timeout" seconds.

Since version 1.63 you can enable/disable the global rule.

Those rules will be defined by the following ModSecurity directives, one per DOS Rule: SecAction "id:'', phase:2, t:none, setvar:'tx.brute_force_protected_urls={{dos_rule.url}}', setvar:'tx.brute_force_burst_time_slice={{dos_rule.burst_time_slice}}', setvar:'tx.brute_force_counter_threshold={{dos_rule.counter_threshold}}', setvar:'tx.brute_force_block_timeout={{dos_rule.block_timeout}}', auditlog, pass" These directives will be then checked by the following custom ModSecurity directives: SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "chain,phase:3,id:'236',deny,status:403,msg:'Brute Force Attack Identified from %{tx.real_ip} (%{tx.brute_force_block_counter} hits since last alert)',setvar:ip.dos_block_counter=+1" SecRule &IP:BRUTE_FORCE_BLOCK_FLAG "@eq 0" "setvar:ip.dos_block_flag=1,expirevar:ip.dos_block_flag=60,setvar:tx.brute_force_block_counter=%{ip.dos_block_counter},setvar:ip.dos_block_counter=0"

Block and track # of requests but don't log

SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:3,id:'237',deny,status:403,auditlog,setvar:ip.dos_block_counter=+1"
SecRule &TX:BRUTE_FORCE_PROTECTED_URLS "@eq 0" "phase:5,id:'238',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"
SecRule REQUEST_FILENAME "!@within %{tx.brute_force_protected_urls}" "phase:5,id:'239',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"
SecRule IP:BRUTE_FORCE_BLOCK "@eq 1" "phase:5,id:'240',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CHECKS"
SecAction "phase:5,id:'241',t:none,auditlog,pass,setvar:ip.dos_counter=+1"
SecRule IP:BRUTE_FORCE_COUNTER "@gt %{tx.brute_force_counter_threshold}" "phase:5,id:'242',t:none,auditlog,pass,t:none,setvar:ip.dos_burst_counter=+1,expirevar:ip.dos_burst_counter=%{tx.brute_force_burst_time_slice},setvar:!ip.dos_counter"
SecAction "phase:5,id:'13',auditlog,msg:'%{ip.dos_counter}'"
SecRule IP:BRUTE_FORCE_BURST_COUNTER "@ge 2" "phase:5,id:'243',t:none,log,pass,msg:'Potential Brute Force Attack from %{tx.real_ip} - # of Request Bursts: %{ip.dos_burst_counter}',setvar:ip.dos_block=1,expirevar:ip.dos_block=%{tx.brute_force_block_timeout}"
SecMarker END_BRUTE_FORCE_PROTECTION_CHECKS

Feel free to contact us if you have any improvement relative to these rules.

Advanced

Arguments separator in forms: Specify which character to use as argument separator.
This value will be set by the following ModSecurity directive:
SecArgumentSeparator
This option is used for application/x-www-form- urlencoded content.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecArgumentSeparator for any information about this directive.

Collections Timeout: Specify the collection timeout, default is 3600 seconds.
For each client identified by client-ip/user-agent, a collection is created and maintained in Redis. In case of a client does not contact the server for a timeout, the collection is deleted.
You can change that value to delete the collections after another timeout.
That value is set by the following ModSecurity directive : SecCollectionTimeout.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecCollectionTimeout for more informations about this option.

Cookie Format: The cookie format, either version 0 (netscape) or version 1 (value can be token or quoted string).
That value will be set by the following ModSecurity directive: SecCookieFormat.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecCookieFormat for more informations about this option.

Cookie Separator: The defined cookie seperator.
Specifies which character to use as the separator for cookie v0 content.
That value will be set by the following ModSecurity directive : SecCookieV0Separator.
See https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecCookieV0Separator for more informations about this option.

Custom directives

Here you can add raw mod_security directives.
This block will be directly past in the section of the application which use that Policy.