Reverse Proxy Detected

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Reverse Proxy Detected

creditu
We have been using several squid servers in accelerator mode for a number of years mainly for load balancing to send public requests to backend servers.  The requests to the squids typically come via a well known commercial  caching service.   The squids don't do any caching, they just forward requests to the backend.

Recently the vulnerability scanner that we use changed a plugin from Info level to Moderate for reverse proxy detection.  We need to mitigate this so the vulnerability scanner doesn't flag for the reverse proxy detection.

On a non-production server I added the following.  This seems to mitigate the vulnerability in the eyes of the scanner.  (I may be able to get away with not including the X-Cache-Lookup  line and still fix the issue.)  

via off
reply_header_access X-Cache deny all
reply_header_access X-Cache-Lookup deny all

This removes the headers for both the outgoing traffic to the Internet and the backend traffic to the webservers.  I have not seen any operational impact of doing this, but wanted get some feedback on if there is a better way to fix this issue and if I am missing any possible implications.

Also, does the following have the same effect as "via off"?
reply_header_access Via deny all

 
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Reverse Proxy Detected

Amos Jeffries
Administrator
On 1/08/19 9:41 am, creditu wrote:

> We have been using several squid servers in accelerator mode for a
> number of years mainly for load balancing to send public requests to
> backend servers.  The requests to the squids typically come via a
> well known commercial  caching service.   The squids don't do any
> caching, they just forward requests to the backend.
>
> Recently the vulnerability scanner that we use changed a plugin from
> Info level to Moderate for reverse proxy detection. We need to
> mitigate this so the vulnerability scanner doesn't flag for the
> reverse proxy detection.
>

So the first question is why they did that change. It may be that the
particular Squid version you have is known to have issues they are
warning about.


> On a non-production server I added the following.  This seems to
> mitigate the vulnerability in the eyes of the scanner.  (I may be
> able to get away with not including the X-Cache-Lookup  line and
> still fix the issue.)
>
> via off reply_header_access X-Cache deny all reply_header_access
> X-Cache-Lookup deny all
>
> This removes the headers for both the outgoing traffic to the
> Internet and the backend traffic to the webservers.  I have not seen
> any operational impact of doing this, but wanted get some feedback
> on if there is a better way to fix this issue and if I am missing
> any possible implications.
>

The above are fine.

The "via off" does technically violate a "proxy MUST add" requirement
from RFCs 2616 and 7230. But the HTTPbis WG has been looking into
reducing that to a SHOULD for the next HTTP spec update and the results
looked good. Proxies are already allowed by those RFCs to aggregate
several Via entries together - which is essentially the same as not
adding a new one.


FWIW; All X-* headers are deprecated officially by HTTP and those
X-Cache* ones were only intended to be debug info by their creators back
in 1990's. Though some admin or software apparently place unwarranted
dependency on them for other uses.



> Also, does the following have the same effect as "via off"?
> reply_header_access Via deny all
>

No. "via off" will stop Squid adding itself to the Via header. Any
existing header should remain so that other systems outside yours can
still use the feature. This works in both request and reply traffic.

The access denial approach erases other agents Via headers. Rendering
any use of that feature broken for that other software.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users