Mod security

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.'''

'''A Cloud-based WAF (similar to ModSecurity) might be better suited depending on your needs. CloudFlare and Sucuri are services you can look at.'''

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..

 SecFilterSelective REQUEST_URI "^/wp-admin/async-upload\.php.*$" "allow,pass"  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
 SecFilterDebugLevel 0 SecFilterDefaultAction "deny,nolog,noauditlog,status:503" 

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.

 SecFilterEngine On
 * 1) ASKAPACHE MOD_SECURITY ###

SecFilterDefaultAction "deny,log,status:403"
 * 1) The default rule to apply to inherited rules
 * 2) Reject requests with status 403

SecFilterDebugLevel 0
 * 1) Goes up to 9 but at 2 its overwhelming trust me

SecFilterCheckURLEncoding On
 * 1) Make sure that URL encoding is valid

SecFilterCheckUnicodeEncoding Off
 * 1) Unicode encoding check

SecFilterScanPOST On
 * 1) Should mod_security inspect POST payloads

SecFilterForceByteRange 1 255
 * 1) Accept almost all byte values

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

SecAuditEngine RelevantOnly
 * 1) Only record the interesting stuff


 * 1) Uncomment below to record responses with unusual statuses
 * 2) SecAuditLogRelevantStatus ^5
 * 3) SecAuditLog logs/modsec_audit.log

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

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

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

SecFilterSelective REQUEST_METHOD "^POST$" chain SecFilterSelective HTTP_Content-Length "^$"
 * 1) Require Content-Length to be provided with
 * 2) every POST request

SecFilterSelective HTTP_Transfer-Encoding "!^$" 
 * 1) Don't accept transfer encodings we know we don't handle

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