Re: [squid-users] Squid 3.1.15 not enforcing browser proxy mode

From: Ron Starr <ronl1213_at_comcast.net>
Date: Fri, 4 Nov 2011 18:36:47 -0700

On 5/11/2011 11:04 a.m., Ron Starr wrote:
> To all,
>
> Maybe someone wiser than me can point out the error in our configuration.
> Have googled for hours and searched the archives.
>
> We have two configs we are testing. In both configs a requirement is that
> the user be forced to use the Squid proxy by enabling proxy mode in the
> browser (ie, FF, chrome,Opera latest versions). In the first config we are
> using NTLM with fallback. This config works properly. If proxy mode in the
> browser is set to point to Squid all works as expected—traffic passes
> normally. When proxy mode is disabled, all works as expected, the user
> receives a Squid denied page.
>
> The problem is the second config. In this config we have a fairly minimal
> config allowing localhost access. The issue is it does not matter how the
> browser is set, traffic passes normally. Our expectation is if the browser
> proxy mode is off the user should receive a squid denied page. Any help is
> appreciated.
>

Firstly that Squid does not and cannot enforce this policy. The box or
network firewall is the front line which rejects direct client->Internet
connections.

Squid is part of a secondary mechanism that can be added to the firewall
with NAT or TRPOXY interception. Intercepting the packets into Squid for
a custom page explaining the policy instead of a blunt "cannot connect"
error.

So, with taht in mind, config update comments inline...

> Good Configuration
>
> auth_param ntlm program
> /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
> auth_param ntlm children 50 startup=10 idle=10
> auth_param ntlm keep_alive on
> auth_param basic program
> /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
> auth_param basic children 50
> auth_param basic realm squidproxy
> auth_param basic credentialsttl 2 hours
> acl AuthorizedUsers proxy_auth REQUIRED
> max_filedesc 20000
> cache_mem 300 MB
> visible_hostname localhost
> http_port 3128

Regular traffic from configured browsers. Good.
<snip>
> #Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
> http_access allow all AuthorizedUsers

The "all" can be removed from the above line. It is not useful like that
at the beginning of a line of ACLs.

> # And finally deny all other access to this proxy
> http_access deny all
> # We recommend you to use at least the following line.
> hierarchy_stoplist cgi-bin ?

Performance tip: The stoplist can go now. It has been shown not to be
useful.

>
> Bad Configuration—browser proxy mode is not enforced.
<snip>
> # Only allow cachemgr access from localhost
> http_access allow manager localhost
> http_access deny manager
> # Deny requests to certain unsafe ports
> http_access deny !Safe_ports
> # Deny CONNECT to other than secure SSL ports
> http_access deny CONNECT !SSL_ports
> http_access deny to_localhost
> http_access allow localhost
> # And finally deny all other access to this proxy
> http_access deny all

The main thing I notice in the above. There is no http_port
configuration in either one for Squid to receive intercept or tproxy
traffic.

I suspect you are doing NAT on the local box (okay, fine and proper) but
squid is not configured to understand that it is NAT traffic arriving.
So it only sees the localhost IP address on all traffic coming in.

Amos

Amos,

Thank you so much for your reply. In both configs we are referencing
http_port 3128 (It was part of what you snipped). We are upgrading from an
early version of Squid 2.5 where this appeared to work (even though the
syntax was more complex). Our understanding was that if http_port 3128 by
itself was referenced that proxy on the browser was a requirement. If we
didn't want it then we would use http_port 3128 transparent (or with 3.1
Intercept).

Yes, we re nat'ing and we're feeding Dansguardian into Squid using Shorewall
to redirect port 80 traffic into DG on 8080. Are we totally off base on what
to expect with Http_access 3128? Also, in the good config when proxy is not
enabled in the browser, we receive a Squid denied message--not a generic
"cannot connect". Our concern is why we do not receive the same Squid
message in the bad config.

Thanks again,

Ron
Received on Sat Nov 05 2011 - 01:37:22 MDT

This archive was generated by hypermail 2.2.0 : Sat Nov 05 2011 - 12:00:03 MDT