DreamHost enables mod_security with the Extra Web Security option under Domain Management in the Web Admin Panel.
Extra Web Security
General Caution: Most of this article dates from 2008 or earlier. Some quoted directives were only valid in mod_security version 1.x; others may not be usable at all in htaccess. Copy and paste at your peril.
April 7th 2014 update: Our current configuration of modsec does not allow for disabling or custom rules via .htaccess. We intend to upgrade in the future to a version that will allow this.
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 220.127.116.11
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
|The instructions provided in this article or section are considered advanced.|
You are expected to be knowledgeable in the UNIX shell.
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.