From 957e79c7dd6e93328f9e63c166b343d8034b5d2e Mon Sep 17 00:00:00 2001 From: Remi Collet Date: Wed, 13 Jun 2012 18:43:31 +0200 Subject: reorg repo --- mod_security.conf | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 92 insertions(+) create mode 100644 mod_security.conf (limited to 'mod_security.conf') diff --git a/mod_security.conf b/mod_security.conf new file mode 100644 index 0000000..7468a05 --- /dev/null +++ b/mod_security.conf @@ -0,0 +1,92 @@ + +LoadModule security2_module modules/mod_security2.so +LoadModule unique_id_module modules/mod_unique_id.so + + + # This is the ModSecurity Core Rules Set. + + # Basic configuration goes in here + Include modsecurity.d/*.conf + Include modsecurity.d/activated_rules/*.conf + + # Additional items taken from new minimal modsecurity conf + # Basic configuration options + SecRuleEngine On + SecRequestBodyAccess On + SecResponseBodyAccess Off + + # Handling of file uploads + # TODO Choose a folder private to Apache. + # SecUploadDir /opt/apache-frontend/tmp/ + SecUploadKeepFiles Off + SecUploadFileLimit 10 + + # Debug log + SecDebugLog /var/log/httpd/modsec_debug.log + SecDebugLogLevel 0 + + # Audit log + SecAuditEngine RelevantOnly + SecAuditLogRelevantStatus ^5 + SecAuditLogType Serial + SecAuditLogParts ABIFHZ + SecAuditLog /var/log/httpd/modsec_audit.log + + # Alternative mlogc configuration + #SecAuditLogType Concurrent + #SecAuditLogParts ABIDEFGHZ + #SecAuditLogStorageDir /var/log/mlogc/data + #SecAuditLog "|/usr/bin/mlogc /etc/mlogc.conf" + + # Set Data Directory + SecDataDir /var/log/httpd/ + + # Maximum request body size we will + # accept for buffering + SecRequestBodyLimit 131072 + + # Store up to 128 KB in memory + SecRequestBodyInMemoryLimit 131072 + + # Buffer response bodies of up to + # 512 KB in length + SecResponseBodyLimit 524288 + + # Verify that we'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_PROCESSOR_ERROR "!@eq 0" \ + "phase:2,t:none,log,deny,msg:'Failed to parse request body.',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 "!@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}, \ + IH %{MULTIPART_INVALID_HEADER_FOLDING}, \ + IH %{MULTIPART_FILE_LIMIT_EXCEEDED}'" + + # Did we see anything that might be a boundary? + SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \ + "phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" + + # 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_/ "!@streq 0" \ + "phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" + -- cgit