Re: [squid-users] SECURITY ALERT: Host: header forgery detected with today's BZR checkout

On 15/08/11 23:52, Ralf Hildebrandt wrote:
> With today's BZR checkout (3.2-HEAD) I'm getting a lot of "SECURITY
> ALERT: Host: header forgery detected" with everyday requests:
>
> 2011/08/15 13:50:59.016| SECURITY ALERT: Host: header forgery detected from local=141.42.1.205:8080 remote=10.43.65.227:3266 FD 1312 flags=1 (amsprd0104.outlook.com:443 does not match amsprd0104.outlook.com)

We now forcibly detect CVE-2009-0801 vulnerability abuse. A few cases
have been found missing from the detection. Please apply these two
patches in this order:

 
http://www.squid-cache.org/Versions/v3/3.HEAD/changesets/squid-3-11647.patch

 
http://www.squid-cache.org/Versions/v3/3.HEAD/changesets/squid-3-11649.patch

> 2011/08/15 13:50:59.016| client_side.cc(1579) keepaliveNextRequest: abandoning local=141.42.1.205:8080 remote=10.43.65.227:3266 FD 1312 flags=1

keep-alive on CONNECT requests after an error response (the one above)
is possible, but still has this one remaining bug. In your case it is
triggered by the above error, so will disappear again after those
patches go in.

NP: There is a patch trying to fix this. I'm looking for someone with
NTLM (most common and also most complex real-world test case) willing to
test on real traffic and confirm that it works (or not).

If anyone reading this needs NTLM + CONNECT (HTTPS over Squid) please
check out the last few comments on
http://bugs.squid-cache.org/show_bug.cgi?id=3213

> 2011/08/15 13:51:00.746| SECURITY ALERT: Host: header forgery detected from local=141.42.1.205:8080 remote=192.168.247.63:3900 FD 39 flags=1 (profpeak.avira-update.com does not match 89.105.213.24)
> 2011/08/15 13:51:00.752| SECURITY ALERT: Host: header forgery detected from local=141.42.1.205:8080 remote=192.168.247.63:3901 FD 1407 flags=1 (profpeak.avira-update.com does not match 89.105.213.24)

Detection seems to be working properly in this case.

   "profpeak.avira-update.com does not match 89.105.213.24"

NP: I've had a few other private mentions about Avira. It seems you need
to check how/why that request is being made and fix something.
  * If that is part of an internal redirect or HTTP loop to/from
internal update servers I suggest cache_peer doing a reverse-proxy and
avoiding the Host: trickery.
  * If that is part of Avira being used as a chained proxy or via
url_redirector interface I suggest updating it to use the ICAP interface
with Squid.

If any problems remain or you have questions about the matches see the
(new in 3.2) debug_options 11,2 for full HTTP protocol trace.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.10