# ModSecurity Rules Project # (http://www.modsecurity.org/projects/rules/) # # $Id: modsecurity-hardening.conf,v 1.1.1.1 2006/01/03 13:52:16 ivanr Exp $ # # Copyright (C) 2005,2006 Thinking Stone (http://www.thinkingstone.com). # All rights reserved. # # Redistribution and use, with or without modification, are permitted # provided that the following conditions are met: # # * Redistributions must retain the above copyright notice, this list # of conditions and the following disclaimer in the source code # and in the documentation and/or other materials provided with the # distribution. # # * Neither the name of "Thinking Stone", "ModSecurity", nor the names # of its contributors may be used to endorse or promote products # derived from this software without specific prior written permission. # # THESE RULES ARE PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS # IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, # THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, # EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, # PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR # PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF # LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THESE # RULES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # This is a generic rule set for ModSecurity 1.9.x. It will work # as is, when included from the main Apache configuration file, # but to achieve maximum performance and protection, it needs to # be tweaked according to your specific circumstances. # # Next to each rule there is a description of what it does. Each # location where customisation is needed is marked with "TODO". It # is recommended that you: # # 1) Keep a copy of the original file. This will allow you to use # the "diff" command to quickly see the changes. It will also # make upgrades to future rule sets easier. # # 2) Document your changes thoroughly. # # You are advised to start with ModSecurity in detection mode only. # Switch to protection when you are comfortable with your rule set. # For maximum protection monitor your logs on daily basis (or # better). # # TODO You may want to provide an error friendly message to your # users when you start rejecting requests. You can do this using # the Apache ErrorDocument directive. You should also add # mod_unique_id to your configuration and display the unique # request ID on the error page. This would allow your users to # report the request ID back to you so that you can investigate # the false positive (if that's what it is). A nice error page # usually reduces the impact of false positives on the users. # # The drawback of this user-friendly approach is that it is # easier for the attackers to figure out there is an web # application firewall protecting the application. # # ErrorDocument 403 /path/to/error_document.php # # For more information see http://httpd.apache.org/docs-2.0/custom-error.html ## -- Configuration ---------------------------------------------------------- # Whether to allow ModSecurity to run ("On") or not ("Off"). # # TODO Consider whether to use "DynamicOnly" for "SecFilterEngine". # This setting may serve as an performance improvement but you # MUST verify the Apache handler is used correctly. If you don't # do this attacks may go through undetected. # # Simply change "On" to "DynamicOnly", restart Apache, and execute # one request (with an attack payload) for a static resource, and # another (also with an attack payload) for a dynamic resource. The # first request one should not produce an error/warning message. The # second one should. # SecFilterEngine On # Whether to allow ModSecurity to buffer and monitor request bodies. # # This setting should always be "On". You may want to turn # it to "Off" in some areas (e.g. file uploads) but be warned that # effectively disables ModSecurity for attacks carries out through # in request bodies. Take special care to secure scripts that receive # request bodies directly. # SecFilterScanPost Off # Whether to allow ModSecurity to buffer and monitor response (bodies). # # This is useful to monitor for information leaks, or for signs # of intrusion. However, it does require all responses to be buffered # in memory. For most sites this should not be a problem, but special # care must be taken to avoid buffering file downloads (through # MIME type selection, as shown below). # # TODO If you decide to enable output filtering make sure to # review the list of scanned MIME types. # # SecFilterScanOutput Off # SecFilterOutputMimeTypes "(null) text/html text/plain" # Whether to check if the URL encoding in the request is valid. # # If a request with an invalid URL encoding is discovered it will # we *rejected* even if the default action (see below) says otherwise. # There is no reason to use invalid URL encodings in a request but # sometimes applications do it by mistake (e.g. in cases when URIs are # constructed dynamically using JavaScript). # SecFilterCheckURLEncoding On # Temporary file storage path. # # TODO Change the temporary folder setting to a path where only # the web server has access. # SecUploadDir /tmp # Whether or not to keep the stored files. # # In most cases you don't want to keep the uploaded files (especially # when there is a lot of them). It may be useful to change the setting # to "RelevantOnly", in which case the files uploaded in suspicious # requests will be stored. # SecUploadKeepFiles Off # Inspect uploaded files. # # TODO If there is a danger of attack through uploaded files then it # is possible to configure an external script to inspect each file # before it is seen by the application. An example script is # included with ModSecurity (/util/modsec-clamscan.pl). # # SecUploadApproveScript /path/to/script.pl ## -- Validation ------------------------------------------------------------- # Whether to check if proper UTF-8 encoding is used in requests. # # TODO Change to "On" if the application uses Unicode. This setting # must be configured on the per-application level. # # NOTE UTF-8 encoding uses bytes in the higher range. # SecFilterCheckUnicodeEncoding Off # Whether to restrict which bytes can be used in a request. # # TODO The default setting is not very restrictive. It only disallows # the null byte (only known use of this value is for attacks). # Applications that are English-only could try to use "10 126" # or "32 126" (if there are not