mod_security

From DreamHost

DreamHost enables mod_security with the Extra Web Security option under Domain Management in the Web Admin Panel.

Contents 1 Extra Web Security 2 Alternative to Disabling Extra Web Security 2.1 Staying Secure, without the Errors 2.2 Prevent mod_security logs from showing up in error log 3 Advanced Configurations for the Brave 4 See Also 5 External Links

Extra Web Security

The Extra Web Security option (you see it when adding a new domain or editing the web settings for an existing domain) enables the use of a very special security module for your website. Many common attacks that can compromise your website will be blocked by this option. We cannot guarantee that all attacks will be blocked but we will do our best to ensure the most common known attacks will be prevented.

Alternative to Disabling Extra Web Security

It is really a bad idea to turn off the Extra Web Security option from the panel because mod_security protects your site from many kinds of attacks and is highly effective. But occasionally it can be a little too secure and cause an error in your web application. These errors occur because of the default mod_security rules pre-loaded by mod_security from within the servers configuration, and can not be modified easily.

Thankfully DreamHost has allowed its customers to control some of these options from within site. So make sure all of your domains have it enabled. .htaccess files

Staying Secure, without the Errors

SetEnvIfNoCase Remote_Addr ^208\.113\.183\.100$ MODSEC_ENABLE=Off

If you are receiving an error message while doing an administrative task like posting on a blog, uploading an image, etc., then you can instruct mod_security to allow that specific task.. Beyond that you can turn mod_security completely off for your IP address. And any other number of options. Google for more. Adding this to your .htaccess file will turn mod_security off for the IP address 208.113.183.100

SetEnvIfNoCase Request_URI ^/wp-admin/async-upload\.php$ MODSEC_ENABLE=Off

If the problem is only occurring for a particular file, like /async-upload.php which [caused problems for WP 2.5 users you can also disable mod_security from within .htaccess for a specific file..

<IfModule mod_security.c>
 SecFilterSelective REQUEST_URI "^/wp-admin/async-upload\.php.*$" "allow,pass"
</IfModule>

Instead of disabling mod_security for everyone who requests async-upload, you should instead use this method which allows the request to pass without being denied, so you still have the security of additional mod_security checks and you keep logging turned on.

Prevent mod_security logs from showing up in error log

<IfModule mod_security.c>
SecFilterDebugLevel 0
SecFilterDefaultAction "deny,nolog,noauditlog,status:503"
</IfModule>

Advanced Configurations for the Brave

Basically mod_security is very similar to mod_rewrite in many delightful ways, except that mod_security is actually considered more difficult than mod_rewrite, if you can believe such a thing! For example, here is a basic mod_security configuration I've used on DH.. notice I replaced the 503 with a 403 Forbidden message.

### ASKAPACHE MOD_SECURITY ###
<IfModule mod_security.c>
SecFilterEngine On

# The default rule to apply to inherited rules
# Reject requests with status 403
SecFilterDefaultAction "deny,log,status:403"

# Goes up to 9 but at 2 its overwhelming trust me
SecFilterDebugLevel 0

# Make sure that URL encoding is valid
SecFilterCheckURLEncoding On

# Unicode encoding check
SecFilterCheckUnicodeEncoding Off

# Should mod_security inspect POST payloads
SecFilterScanPOST On

# Accept almost all byte values
SecFilterForceByteRange 1 255

# Designate a directory for temporary files
# storage. It is a good idea to change the
# value below to a private directory, just as
# an additional measure against race conditions
SecUploadDir /tmp
SecUploadKeepFiles Off

# Only record the interesting stuff
SecAuditEngine RelevantOnly

# Uncomment below to record responses with unusual statuses
#SecAuditLogRelevantStatus ^5
#SecAuditLog logs/modsec_audit.log

# You normally won't need debug logging
SecFilterDebugLevel 0
#SecFilterDebugLog logs/modsec_debug.log

# Only accept request encodings we know how to handle
# we exclude GET requests from this because some (automated)
# clients supply "text/html" as Content-Type
SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;)"

# Do not accept GET or HEAD requests with bodies
SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Length "!^$"

# Require Content-Length to be provided with
# every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

# Don't accept transfer encodings we know we don't handle
SecFilterSelective HTTP_Transfer-Encoding "!^$"
</IfModule>

My current config is much longer now, but then again I've almost completely eliminated spam, I've written all about it.

See Also

• .htaccess files
• Security

External Links

• Mod_Security Official Site