Do not disable mod_security if you care about your site
Especially with popular applications, I strongly caution against disabling mod_security.
The more popular an application is, the more people want to find exploits for it.
Wordpress is in the top 3 for blog software. Disabling mod_security for it is just asking for disaster, as exploits WILL be found for it. It's not necessarily the fault of the developers, I am sure they try very hard to write safe code. But, when you have thousands of people looking over every inch of your code, looking for ways to attack and exploit it, eventually those thousands will find a problem that you missed as a developer. It happens.
Realize that even now, versions of Wordpress < 2.3.1 are remotely exploitable. This is just an example. It's not safe to turn off mod security.
If you have a rule that is causing trouble, disable that rule.
Disable multiple rules if you need to. The suggestion to disable all of modsec is an "easy" solution for everyone. The problem goes away, your wordpress works, and you can do your stuff. But it also exposes you to a much higher threat level, as you're putting an application online with no protection against even basic attacks. It is of course up to you as the user. But I think most users do not realize how often servers and sites are scanned for the latest exploits (it happens all the time, at every host).
Mod security, if kept up to date and properly configured, can save you in some circumstances. It's not perfect, but turning it off is almost never the answer. Work through the problem instead of avoiding it.
If modsec is blocking you based on a rule, look at which rule is causing the problem. For example, the log shows this in your example:
Pattern match "((alter|create|drop)[[:space:]]+(column|database|procedure|table)|delete[[:space:]]+from|update.+set.+=)" at POST_PAYLOAD [id "300015"][rev "1"] [msg "Generic SQL injection protection"] [severity "CRITICAL"]
Pattern match "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\\\(.*from)" at POST_PAYLOAD [id "300016"][rev "2"] [msg "Generic SQL injection protection"] [severity "CRITICAL"] [hostname "domainname.com"] [uri "/private.php?do=insertpm&pmid=36173"]
You see the ID in the error message? Well written mod_security rules include an id. You can disable filters based on that, so as an example, putting this in your .htaccess file will disable those two problematic rules:
<IfModule mod_security.c>
<Files /blah/something.php>
SecFilterRemove 300015
SecFilterRemove 300016
</Files>
</IfModule>
That will disable ONLY those two rules for ONLY the file /blah/something.php, but leave full protection on for all other pages locations. Of course it's best to rewrite the rule to avoid false positives. But if nothing else, this is a much safer alternative than disabling the entire engine. As an alternative to the <Files> and </Files> wrapper, you may also possibly use <Location /blah/php> </Location> or even <LocationMatch> </LocationMatch> or <File /blah.php> </File>. You may even apply it to the entire folder/site by not wrapping it in limitations, like:
<IfModule mod_security.c>
SecFilterRemove 300015
SecFilterRemove 300016
</IfModule>
Either way, this is much more preferable and safer.
The reason anyone (Wordpress developers, whoever) recommend disabling modsec completely is because it is far less hassle for them. You don't come back and say "hmm it still doesn't work" because of another rule, and they dont have to explain how to use SecFilterRemove, or anything else. But it is not safe.
-- then a better solution will be to disable only the mod_security rule that is causing the problem. It is always better to disable one rule than to disable them all. At least you still have the bulk of your "shield" working if you only disable the one problem rule, vs no "shield" at all if you disable them all.
