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
