Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- <IfModule mod_security.c>
- # Turn the filtering engine On or Off
- SecFilterEngine On
- # Change Server: string
- SecServerSignature "Hacked By X-Cisadane"
- # Make sure that URL encoding is valid
- SecFilterCheckURLEncoding On
- # Unicode encoding check
- SecFilterCheckUnicodeEncoding Off
- # Only allow bytes from this range
- SecFilterForceByteRange 0 255
- # Debug level set to a minimum
- SecFilterDebugLog /var/log/httpd/modsec_debug_log
- SecFilterDebugLevel 0
- # Should mod_security inspect POST payloads
- SecFilterScanPOST On
- # By default log and deny suspicious requests
- # with HTTP status 500
- SecFilterDefaultAction "deny,log,status:500"
- # Require HTTP_USER_AGENT and HTTP_HOST in all requests
- SecFilterSelective "HTTP_USER_AGENT|HTTP_HOST" "^$"
- # Prevent path traversal (..) attacks
- SecFilter "../"
- # Weaker XSS protection but allows common HTML tags
- SecFilter "<[[:space:]]*script"
- # Prevent XSS atacks (HTML/Javascript injection)
- SecFilter "<(.|n)+>"
- # Very crude filters to prevent SQL injection attacks
- SecFilter "delete[[:space:]]+from"
- SecFilter "insert[[:space:]]+into"
- SecFilter "select.+from"
- SecFilter "drop[[:space:]]table"
- # Protecting from XSS attacks through the PHP session cookie
- SecFilterSelective ARG_PHPSESSID "!^[0-9a-z]*$"
- SecFilterSelective COOKIE_PHPSESSID "!^[0-9a-z]*$"
- SecUploadDir /tmp
- SecUploadKeepFiles Off
- SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
- SecFilterSelective HTTP_Content-Type \"!(^application/x-www-form-urlencoded$|^multipart/form-data;)"
- SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
- SecFilterSelective HTTP_Content-Length "!^$"
- SecFilterSelective REQUEST_METHOD "^POST$" chain
- SecFilterSelective HTTP_Content-Length "^$"
- SecFilterSelective HTTP_Transfer-Encoding "!^$"
- SecResponseBodyLimit 524288
- # -- 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 DetectionOnly
- # -- Request body handling ---------------------------------------------------
- # Allow ModSecurity to access request bodies. If you don't, ModSecurity
- # won't be able to see any POST parameters, which opens a large security
- # hole for attackers to exploit.
- #
- SecRequestBodyAccess On
- # Enable XML request body parser.
- # Initiate XML Processor in case of xml content-type
- #
- SecRule REQUEST_HEADERS:Content-Type "text/xml" \
- "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
- # 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
- # Store up to 128 KB of request body data in memory. When the multipart
- # parser reachers this limit, it will start using your hard disk for
- # storage. That is slow, but unavoidable.
- #
- SecRequestBodyInMemoryLimit 131072
- # What do 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'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 "!@eq 0" \
- "id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',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" \
- "id:'200002',phase:2,t:none,log,deny,status:44,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_MISSING_SEMICOLON}, \
- IQ %{MULTIPART_INVALID_QUOTING}, \
- IP %{MULTIPART_INVALID_PART}, \
- IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
- FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
- # Did we see anything that might be a boundary?
- #
- SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
- "id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"
- # 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_/ "!@streq 0" \
- "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
- # -- 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 On
- # 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's somewhat less secure, but does not break any legitimate pages.
- #
- SecResponseBodyLimitAction ProcessPartial
- # -- Filesystem configuration ------------------------------------------------
- # The location where ModSecurity stores temporary files (for example, when
- # it needs to handle a file upload that is larger than the configured limit).
- #
- # This default setting is chosen due to all systems have /tmp available however,
- # this is less than ideal. It is recommended that you specify a location that's private.
- #
- SecTmpDir /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't access.
- #
- SecDataDir /tmp/
- # -- File uploads handling configuration -------------------------------------
- # The location where ModSecurity stores intercepted uploaded files. This
- # location must be private to ModSecurity. You don't want other users on
- # the server to access the files, do you?
- #
- #SecUploadDir /opt/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 RelevantOnly
- # 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/modsecurity/var/log/debug.log
- #SecDebugLogLevel 3
- # -- 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 RelevantOnly
- SecAuditLogRelevantStatus "^(?:5|4(?!04))"
- # Log everything we know about a transaction.
- SecAuditLogParts ABIJDEFHZ
- # 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 /var/log/httpd/audit_log
- # Specify the path for concurrent audit logging.
- #SecAuditLogStorageDir /opt/modsecurity/var/audit/
- # -- Miscellaneous -----------------------------------------------------------
- # Use the most commonly used application/x-www-form-urlencoded parameter
- # separator. There's probably only one application somewhere that uses
- # something else so don'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.
- #
- #SecUnicodeCodePage 20127
- #SecUnicodeMapFile unicode.mapping
- </IfModule>
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement