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
