Home > Uncategorized > The mysterious case of the 501 error

The mysterious case of the 501 error

May 13th, 2009
Goto comments Leave a comment

I recently installed mod_security on our Apache server, and everything seemed to be working fine. Suddenly, while working on the previous post, I was presented with this error:

Method Not Implemented
POST to /wp/wp-admin/post.php not supported.

I checked the log files, and found these hits:

[Wed May 13 10:52:48 2009] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 501 (phase 2). Pattern match “(?:\\b(?:\\.(?:ht(?:access|passwd|group)|www_?acl)|global\\.asa|httpd\\.conf|boot\\.ini)\\b|\\/etc\\/)” at ARGS:content. [file "/etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf"] [line "114"] [id "950005"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [hostname "blog.spind.net"] [uri "/wp/wp-admin/post.php"] [unique_id "xxxxxxxxxxxxx"]

In short, it’s mod_security telling me that the text /etc/ triggered rule 950005, which should be protecting our server against malicious attempts to access local files – like the ones in the /etc directory. The access file only showed a POST to /wp/wp-admin/post.php so I had no idea where the /etc/ string was coming from. Maybe some weird hidden Javascript? Maybe something else?

This post narrowed acknowledged it to be related to mod_security and suggested to disable it permanently or just turn it temporarily off while posting. I aim to do better.

The previous post has a wonderful nugget of enlightenment about prioritizing services on Linux, and suggested a couple of changes to the Linux configuration files – most of which are located in.. the /etc/ folder. In short, I triggered mod_security rule 950005 by posting data containing /etc/.

If you ever plan to cover issues related to deployment and administration of operating system in the Unix family, this rule absolutely has got to go. Obviously it’s written with the best of intentions, but as it is doesn’t work and should be disabled.

Avoid messing with /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf and just disable the specific rules in /etc/httpd/conf.d/mod_security.conf by adding this:

# Disable a couple of rules in modsecurity.d/modsecurity_crs_40_generic_attacks.conf
# that prevents submitting text containing filenames in the Unix family.
SecRuleRemoveById 950005
SecRuleRemoveById 950006

Uncategorized , , , ,

  1. pabiltostar
    July 16th, 2009 at 15:15 | #1
    Reply | Quote

    I appreciate your approach to understanding and fixing at the source. As you know mod_security will filter on other tokens and phrases as well, such as embedding sql queries in your post. My work-around, rather than crippling the security at each discovery, is maybe more simple-minded but just as effective; alter the spelling of the offending tokens. E.g., write /e t c or s elect instead. I discovered the issue on my first blog post ever, which was on sql. Took me hours to figure out (since I can’t access web logs) before it clicked that it could look like sql injection. But I didn’t actually know the root cause. Thanks for your post (and the one on techpulp you’re responding to).

  1. No trackbacks yet.
Mail