On 2/12/2011 10:51 p.m., David Touzeau wrote:
Le vendredi 02 décembre 2011 à 15:05 +1300, Amos Jeffries a écrit :
Hooray progress :)
On 2/12/2011 5:49 a.m., David Touzeau wrote:
Here it is the log in debug mode :
----------
2011/12/01 17:49:14.106 kid1| HTTP Client local=4.26.235.254:80
remote=192.168.1.228:1074 FD 30 flags=33
2011/12/01 17:49:14.106 kid1| HTTP Client REQUEST:
---------
GET /v9/windowsupdate/a/selfupdate/WSUS3/x86/Other/wsus3setup.cab?1112011649 HTTP/1.1
Accept: */*
User-Agent: Windows-Update-Agent
Host: download.windowsupdate.com
Connection: Keep-Alive
K. first problem:
# host download.windowsupdate.com
...
download.windowsupdate.com.c.footprint.net has address 204.160.124.126
download.windowsupdate.com.c.footprint.net has address 8.27.83.126
download.windowsupdate.com.c.footprint.net has address 8.254.3.254
Client is connecting to server 4.26.235.254 port 80. Which is clearly
not "download.windowsupdate.com" according to the official DNS entries I
can see. It is likely you have another set of IPs entirely, so please
confirm that by running "host download.windowsupdate.com" on the Squid box.
Note that transparent Squid requires the same DNS "view" as the clients
to keep the traffic flowing to the right places. Since it should be in
the same network as the clients for transparent to work anyway this is
not usually a problem. But can appear if you or the client is doing
anything fancy with DNS server configurations.
NP: if 4.26.235.254 happens to be a local WSUS server you need to
configure your local DNS to pass that info on to Squid for the relevant
WSUS hosted domains. You will also benefit from Squid helping to enforce
that MS update traffic stays on-LAN.
Amos
OK
Thanks, this is the story..
I'm using a dedicated server has the DNS server (PowerDNS) that cache
for a long time DNS records.
So you are using a DNS srever which caches records after their expiry
time and facing that anycast problem Jenny mentioned?
All Squid-3.2 is doing here is making it a whole lot more obvious. It is
still happening in the background out of sight in older Squid. Users
suffering from broken pages and websites mysteriously disappearing
(whenever the anycast CDN servers go offline and the DNS system is
updated, but not for your DNS server).
After set the server to query ISP DNS, the issue is resolved.
I think that this behavior should be met along this new version.
Is there a way to disable this security checks feature ?
It is optional (and off by default) on regular forward-proxy traffic.
For the intercepted traffic "This problem allows any browser script to
bypass local security and retrieve arbitrary content from any source."
in the advisory is the best we could describe its importance without
giving away bad ideas. Please forgive me for being a bit vague on the
details, but most transparent proxies out there are still vulnerable and
will be for a while yet.
Sometimes, in companies Proxy IT did not have rights to play with DNS
servers
Understood. But you can still discuss the needs with the DNS admins.
Amos
