post-page

ModSecurity, WordPress Admin and “Method Not Implemented”

8
responses

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.

heading
heading
8
Responses

 

Comments

  1. Alenônimo (1 comments.) says:

    Are you using WP Cache? My host have ModSecurity and I can’t use that plugin or my site crash pretty bad.

  2. Mark Ghosh (386 comments.) says:

    No, I was not using WP-Cache.

  3. Ted Clayton (31 comments.) says:

    For people using typical remote-hosting arrangements, will this general approach be impractical, for lack of information, and access? (Mr. Cheney recently affirmed that if my hosting-provider does actually exist, it can be legally denied under Geneva Convention.) ;-)

    If that is so, is there an alternative approach in view, using only client-side facilities?

  4. Mark Ghosh (386 comments.) says:

    In that case, something like this should/might work. Dont forget to change the name of the file that is causing the error to come up.

  5. Ted Clayton (31 comments.) says:

    Ah – these are the refs you started with/hoped would solve your issue; which describe the ‘simple’ case and provide the least-invasive, most-general solution-approach: .htaccess edits, which most hosts allow. Good to know – thanks!

  6. Bennett (4 comments.) says:

    I talked about this issue in WordPress vs. mod_security on my blog a while ago. I don’t think my host allows any way of overriding the mod_security rules (being security rules and all) so I ended up just having to use a workaround. Thanks for the pointer to the various links — I might try the “SecFilterInheritance Off” fix if I get the time.

  7. Raj says:

    My host recently enabled mod_security2 on the server and which resulted into broken wordpress blog. After doing some search on mod_security vs wordpress, I found following article

    http://blog.webhostingdiscussi.....issues.htm

    I provided this to my host and they implemented it and now it works fine without any issue.

    Raj



Trackbacks/Pingbacks

  1. […] ModSecurity, WordPress Admin and “Method Not Implemented” […]

Obviously Powered by WordPress. © 2003-2013

page counter
css.php