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

On 5/11/2011 2:36 p.m., Ron Starr wrote:
> 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).

Correct. The only change there since 2.5 is that the two are not
mutually exclusive anymore. 2.5 that was the case. But now you can (and
should) have separate http_port's for each of the different arriving
traffic types.

>
> 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.

Aha! DansGuardian. In that setup the intercept is not going to Squid so
your port was right. It is only accepting forward-proxy traffic from DG.
Which is using localhost to pass it in, thus your second config failure.

To get the actual client IP details out of DG you need to configure the
forwarded_for feature in both software. DG needs to be set to pass the
X-Forwarded-For header and Squid config contains this:

   follow_x_forwarded_for allow localhost
   follow_x_forwarded_for deny all
   acl_uses_indirect_client on
   log_uses_indirect_client on

Which decoded the entry added by DG (ignoring forgeries from the
clients), and uses it in ACLs and logs as the client IP (ignoring DG's
use of localhost IP).

Amos
Received on Sat Nov 05 2011 - 03:13:54 MDT