On 24/07/2012 4:53 p.m., Ming-Ching Tiew wrote:
----- Original Message -----
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxx
One big change in 3.2.0.14 related to TPROXY traffic handling. A bug in host_strict_verify was fixed, making the validation > bypass properly when the (default) non-strict was configured.
- check that this host_strict_verify directive is ABSENT from your config file, or at very least set to OFF.
There is not such directive in my config file.
- check your cache.log for host forgery security alerts, or forwarding loop warnings when these requests are being made.
- check your cache.log file for invalid request parsing messages. This may require "debug_options ALL,1" to be configured.
The cache.log has these :-
2012/07/24 12:38:34.628| SECURITY ALERT: Host header forgery detected on local=219.93.13.235:80 remote=192.168.1.3 FD 13 flags=17 (local IP does not match any domain IP)
2012/07/24 12:38:34.628| SECURITY ALERT: By user agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; (R1 1.6); .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 2.0.50727)
2012/07/24 12:38:34.628| SECURITY ALERT: on URL: http://us.mg6.mail.yahoo.com/neo/launch?.rand=5fsn8p9a1efna
What is the significance ? Is it that my test client machine is infected by virus adware or what ?
The HTTP Host: header contains a domain name which does not match the IP
address the TCP connection is being made to.
http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery covers the
problem in some detail. For your case in particular I suspect the DNS
situations need to be checked.
219.93.13.235 found by the client is not one of the IPs belonging to
us.mg6.mail.yahoo.com which DNS is supplying to Squid. On the "big name"
websites this is usually caused by Geo-DNS resolution problems rather
than client infection. But there is no way for Squid to be sure. The
only option is for Squid to open a TCP connection directly to that IP
and hope for the best, or if direct connections are blocked the unable
to connect comes up.
NOTE: if you are using cache_peer you can currently only send them
requests where the Host header validates as okay, or were received as
regular forward-proxy / reverse-proxy traffic. (I'm working on that one
as I type, but the fix is a few days/weeks away).
If you are *not* using cache_peer then you have TCP connectivity
problems that need fixing.
You can run 3.1 series for now, or that older beta (ideally not, but if
you *really* have to its okay for now). There are tweaks and
improvements around this right up to the squid-3.2.0.18-20120724-r11624
<http://master.squid-cache.org/Versions/v3/3.2/RELEASENOTES.html>
snapshot with more coming. With probably some of the network environment
situations mentioned in the wiki needing to be fixed as well.
Amos
