COMODO WAF: HTTP header is restricted by policy

A client get blocked by this rule all the time. What is this rule for and why is blocking the access of this user?

ModSecurity: Access denied with code 403 (phase 2). Matched phrase “/via/” at TX:header_name. [file “/var/cpanel/cwaf/rules/10_HTTP_HTTP.conf”] [line “32”] [id “210740”] [rev “2”] [msg “COMODO WAF: HTTP header is restricted by policy”] [data “/Via/”] [severity “WARNING”] [hostname “www.XXXXXXX.com”] [uri "/wp-content/uploads/2014/04/XXXXXXX.jpg

Hello,

we know about this issue. Just exclude this rule till we check and test this rule.

If you believe that this is false positive or this header is required for proper work of your web server clients then just remove “Via” header name from “userdata_bl_headers” file.

I was getting the same warnings as Doublepush…I’ve now just excluded this rule and will wait until you’ve looked into it.

im still seeing this aswell, seem on business customers who have an internal proxy or somethinbg

Could you remove “Via” header name from “userdata_bl_headers” file and check log file again?

I have now removed /Via/ from the list in userdata_bl_headers as you’ve suggested.

Did it help to avoid this issue?

I’ve been getting this error, too. My hosting clients pointed out that their users who were using AT&T data connections were not able to connect. I found this forum while googling the error message. I deleted the “via” header name from the “userdata_bl_headers” file, as suggested. It worked, but a few days later, the problem came back. Upon further investigation, I discovered the “via” header name entry was once again in the “userdata_bl_headers” file.

Why did this get put back in? Was it due to an apache update? When are you going to have a fix for this? Seems like a pretty big problem, considering how many folks are using mobile data connections these days.

So far so good no reported problems,all seems to be working fine now…

Edit :- Just as a side note all my Via errors being blocked was from AT&T data connections as well…Or at least mobile connections,same as ebrains…I will keep watching to see if these errors return and if the Via header get’s put back into the userdata_bl_headers" file after an update ect…

Will keep checking this thread for any updates…

Thanks

Updater will backup all your “userdata files” and restore them after update so they’ll stay unchanged.

+1 on this, with AT&T, but also some foreign IPs. Went ahead and killed /via/ as instructed.

Funny thing is i started getting email alerts again tonight with the same /Via/ error messages…So i logged onto server and looked back into the userdata_bl_headers file and /Via/ had restored itself back into that file…

So the problem has come back after 5/6 days…

Hi

I think it because rules were updated yesterday.
Unfortunately we can’t preserve your changes If you use rules as cPanel vendor.
So if you want to save changes during update please use rules as cPanel plugin.

Regards, Oleg

We will remove /Via/ from userdata_bl_headers within next update.

I did notice that there was an update and thought that must of been the reason behind the /Via/ restoring itself.

I do use cPanel vendor and not the plugin version and i’m very happy with that and i don’t really feel the need to change. I just removed /Via/ again and all’s working again no more hits…

Thanks again for the reply’s guy’s and keep up the great work.

I am still getting errors with rule 210740 COMODO WAF: HTTP header is restricted by policy. And the errors are mainly occurring with the AT&T wireless network (there may be other networks that don’t work too). Turning off the rule allows access to the sites.

In the latest ruleset, released at 2016.01.26 header “Via” was removed.

https://forums.comodo.com/free-modsecurity-rules-comodo-web-application-firewall/rules-updates-changelog-t101377.45.html

I had the 1.63 update installed with the same AT&T errors with rule 210740. However, I installed the 1.64 update released today and now the rule and AT&T wireless no longer conflict.

Hi,

We are on rules version 1.70 and we still have users having this issue (mostly on AT&T). Any ideas (other than turning off the rule)?

Thanks,

Mark