406 error, how to solve?!

[AvatarDutch]

Hello,

I got a hosting with Cpanel 11 in it.
But now I got an problem with my forum.
Somethings that i want to do give me a 406 error.
I searched around the web and find mod_security is the issue.
Now I readed to disable it to putting Secfilterengine off in the .htacces file.
And that doesn't work for me.

Later i readed things about an apache condig file or something where also
that line should stand, en now maybe on ON.
But where do i found that one, or how do I solve this problem.

Greetings from AvatarDutch
(from the netherlands)

[Amit Deshmukh]

The solution was very simple. The following lines were added to the .htaccess file to disable mod_security:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>


This should fix the issue.

Let us know if the error persist

Regards,
Amit
Back in Action

[Bailey]

It is really not a good idea to disable mod_security entirely for a forum. mod_security is what protects you from some of the oldest and simplest exploits. If a 406 error is popping up, there's a very good reason for it. Is your forum fully updated and patched? Are you sure your forum is secure (hasn't been exploited and is sticking XSS crap in peoples' URLs)??

If you are simply running old, poorly-coded forum software -- which is entirely possible with some of the scripts out there -- 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.

To find the rule which is causing the problem,

1. Access the URL that is generating the 406 error, in your web browser. Note exactly what the URL is.

2. SSH in to the server as root and type:

cd /usr/local/apache/logs
tail -100 audit_log

3. Find your URL from step #1 in the printout from the tail -f ... the rule which is being triggered will be printed out under the URL.

4. If mod_security has been installed via WHM, login to root WHM and remove that rule from the mod_security ruleset.

4a. If mod_security has been installed via command line, remove the problem rule from /usr/local/apache/conf/modsecurity.conf and restart Apache.

5. Test your work: access the same URL in your web browser and make sure that it works without a 406 error.


And consider upgrading to better-written forum software.


Bailey

[Infopro]

Actually vbulletin and Gallery (amongst others) suggests this, when editing templates in admin you might run into 406 errors.

http://www.vbulletin.com/forum/showthread.php?t=167121
http://gallery.menalto.com/node/47410
http://wordpress.org/support/topic/117993

This works/solves it though.

<IfModule mod_security.c>
SecFilterScanPOST Off
SecFilterInheritance Off
</IfModule>

Below are rules and errors you might run into on vbulletin without the above in your htaccess.
(running apache 1.3.x and mod_sec)



Vbulletin

ERROR:
-
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"]
--
SECFILTER causing it:
-
#SecFilterSelective ARGS "((alter|create|drop)[[:space:]]+(column|database|procedure|table)|delete[[:space:]]+from|update.+set.+=)" "id:300015,rev:1,severity:2,msg:'Generic SQL injection protection'"
--------------

ERROR:
-
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"]
--

SECFILTER causing it:
-
SecFilterSelective REQUEST_URI "!(/node/[0-9]+/edit|/forum/posting\.php|/admins/wnedit\.php|/alt_doc\.php\?returnUrl=.*edit|/admin/categories\.php\?cPath=.*|modules\.php\?name=Forums&file=posting&mode=.*)" "chain,id:300016,rev:2,severity:2,msg:'Generic SQL injection protection'"
SecFilterSelective ARGS "(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\(.*from)""
-------------


Might be something useful for you there.

(I certainly would not suggest removing rules for an entire server that only affect some accounts)

[AvatarDutch]

SSH, is that a program?
Then i searched good, but what is a good program for it?

On the web i readed more about that command, but they doesn't say how to do it.
Thanks for all the reply's.

The line in .htacces didn't worked.
Only i need to know now is a good program where you can login and run that command.

[cPanelDavidG]

SSH, is that a program?
Then i searched good, but what is a good program for it?

On the web i readed more about that command, but they doesn't say how to do it.
Thanks for all the reply's.

The line in .htacces didn't worked.
Only i need to know now is a good program where you can login and run that command.

If you don't know what SSH is, chances are you don't have root access to the server and thus do not have sufficient permissions to execute that command.

You may wish to contact your web hosting provider regarding this issue.

[Amit Deshmukh]

============================

[jshanley]

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.

[AvatarDutch]

The solution was very simple. The following lines were added to the .htaccess file to disable mod_security:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>


This should fix the issue.

Let us know if the error persist

Regards,
Amit
Back in Action

I already done that.
But don't work, deleted it fast when I notice it doesn't work.
Already deleted my cookies and that stuff.