ModSecurity, WordPress Admin and “Method Not Implemented”

I battled this one for a little bit and I hope the information here helps someone.

First and foremost, there are various version of this problem and they might have different causes stemming from the same source. I list them here in no particular order. I found all the topics starting with a search for the dreaded “Method Not Implemented” 501 error code from the admin panel of WordPress.

POST to /test/wp-admin/index-extra.php not supported: This error is also noticed on post.php and theme-editor.php. Now there are various WordPress Forum posts providing somewhat workable solutions to the problem. I tried some of the solutions but either they did not work for me (I had not looked that closely at the error before trying them) or they were too broad and I did not care for the results. There is some finger pointing in both the forums and the various other pages I found but I believe that the answer lies somewhere in the middle.

In my case, posting caused a “PHP Injection Attack. Matched signature” error that I found in my Apache error logs and the error generated on the browser said “Method Not Implemented 501 error code” with the name of the offending file. This error was caused by ModSecurity which is an Apache module that helps secure web applications on the fly. Now the errant bit of text was in ARGS:content that was bring posted to the server and it matched the regex in one of the ModSecurity rules. It could have been generated by WordPress itself or it could have come from one of the various plugins I have on my blog. I am not sure and I have not taken the time to investigate it further. (please provide more information if you have any). This was a false positive from my perspective and I needed to find an elegant and safe solution that would work.

On reading further about false positives, here is the solution that worked the best. Since I wanted to disable the rule that was catching the post, and not disable the whole mod security for either a file inside the admin folder or the whole admin folder, I found a way to do just that through the Apache configuration files for the virtual host. I found the rule number that was being triggered in the Apache error logs and though I will not disclose the rule number here for security reasons, it was relatively easy to spot. Then I added the following code to my httpd.include (or httpd-vhosts.conf depending on your hosts’ version of software) at the end of the file.

<LocationMatch "/wp-admin/post.php">
SecRuleRemoveById XXXXXX
</LocationMatch>

where XXXXXX was the rule number. Now an ever better solution would be to readd a new rule with the offending regex trimmed out or a !ARGS:content to the Secrule section to only apply to post.php inside the admin folder.

Some caveats: This case ONLY applies to a blog I was working on and the content that was being posted. Your case might be different. If you want to use this method to fix the problem and have no access to your server, just direct your administrator to this post. The secret is to find the offending rule in your error logs and use the rule number to isolate it from the file that it breaks by using LocationMatch and SecRuleRemoveById in your Apache vhosts config file.

Any insights or suggestions will be highly appreciated by me and I am sure by other readers.