In message <200201151959.g0FJxFv03307@nms.lcs.mit.edu>, "David G. Andersen" wri
tes:
Ian A Finlay just mooed:
I wonder what's up?
bash-2.04$ traceroute windowsupdate.microsoft.com
traceroute to windowsupdate.microsoft.com (207.68.131.27), 30 hops max, 40
[...]
8 POS6-0.GW4.DCA8.ALTER.NET (152.63.35.197) 14.747 ms 13.515 ms
12.878 ms
9 65.195.34.226 (65.195.34.226) 653.529 ms 709.526 ms 702.782 ms
10 * * *
11 * * *
12 * * *
Um, it's firewalled? Most of microsoft isn't traceroutable or
pingable.
Yup:
b129$ ipsrvtrace -p 80 windowsupdate.microsoft.com
1 oden.research.att.com 135.207.31.1 0.474 0.338 0.304
2 janus.research.att.com 135.207.1.2 1.360 1.951 2.577
3 argus.research.att.com 192.20.225.225 2.973 3.505 4.063
4 12.119.155.157 12.119.155.157 3.543 4.035 4.603
5 gbr5-p52.n54ny.ip.att.net 12.123.192.10 4.897 5.433 6.188
6 tbr2-p013301.n54ny.ip.att.net 12.122.11.25 6.190 7.795 8.417
7 ggr1-p320.n54ny.ip.att.net 12.122.12.22 4.518 5.232 6.299
8 POS5-1.BR1.NYC9.ALTER.NET 204.255.169.93 6.384 7.661 8.211
9 0.so-6-0-0.XL2.NYC9.ALTER.NET 152.63.18.222 5.242 6.388 6.952
10 0.so-0-0-0.XR2.NYC9.ALTER.NET 152.63.9.89 5.377 5.897 6.586
11 0.so-3-0-0.TR2.NYC9.ALTER.NET 152.63.22.94 4.873 5.388 5.949
12 125.at-7-0-0.TL2.DCA8.ALTER.NET 146.188.141.197 11.861 12.356 12.932
13 0.so-4-3-0.XL2.DCA8.ALTER.NET 152.63.144.30 11.740 13.227 13.792
14 POS7-0.GW4.DCA8.ALTER.NET 152.63.35.201 10.737 11.228 11.778
15 65.195.34.226 65.195.34.226 155.934 156.415 156.973
16 iusbsecurc1202-ge-6-0.msft.net 207.68.128.66 13.109 13.598 14.142
17 - - * * *
18 207.68.131.27 207.68.131.27 13.988 14.373 *
b130$ traceroute windowsupdate.microsoft.com
traceroute to windowsupdate.microsoft.com (207.68.131.27), 30 hops max, 40 byte packets
1 oden (135.207.31.1) 0.424 ms 0.270 ms 0.245 ms
2 janus (135.207.1.2) 1.156 ms 2.943 ms 1.346 ms
3 argus (192.20.225.225) 2.345 ms 1.875 ms 1.749 ms
4 12.119.155.157 (12.119.155.157) 3.412 ms 3.288 ms 3.567 ms
5 gbr5-p52.n54ny.ip.att.net (12.123.192.10) 4.277 ms 4.860 ms 4.038 ms
6 tbr2-p013301.n54ny.ip.att.net (12.122.11.25) 5.238 ms 5.344 ms 4.821 ms
7 ggr1-p320.n54ny.ip.att.net (12.122.12.22) 4.360 ms 5.456 ms 4.098 ms
8 POS5-1.BR1.NYC9.ALTER.NET (204.255.169.93) 4.823 ms 4.466 ms 4.360 ms
9 0.so-6-0-0.XL2.NYC9.ALTER.NET (152.63.18.222) 4.753 ms 5.054 ms 6.305 ms
10 0.so-0-0-0.XR2.NYC9.ALTER.NET (152.63.9.89) 5.017 ms 4.816 ms 4.572 ms
11 0.so-3-0-0.TR2.NYC9.ALTER.NET (152.63.22.94) 6.842 ms 9.812 ms 4.747 ms
12 125.at-7-0-0.TL2.DCA8.ALTER.NET (146.188.141.197) 11.163 ms 11.162 ms 11.214 ms
13 0.so-4-3-0.XL2.DCA8.ALTER.NET (152.63.144.30) 11.414 ms 11.665 ms 11.232 ms
14 POS7-0.GW4.DCA8.ALTER.NET (152.63.35.201) 10.842 ms 11.577 ms 10.759 ms
15 65.195.34.226 (65.195.34.226) 170.249 ms 123.845 ms 135.542 ms
16 * * *
17 * * *
18 * * *
19 * *^C
--Steve Bellovin, error
Full text of "Firewalls" book now at http://www.wilyhacker.com
> Um, it's firewalled? Most of microsoft isn't traceroutable or
>pingable.
Yup:
b129$ ipsrvtrace -p 80 windowsupdate.microsoft.com
[...]
15 65.195.34.226 65.195.34.226 155.934 156.415 156.973
16 iusbsecurc1202-ge-6-0.msft.net 207.68.128.66 13.109 13.598 14.142
17 - - * * *
18 207.68.131.27 207.68.131.27 13.988 14.373 *
Microsoft has been moving/changing Windowsupdate.microsoft.com for
the last week or so. The problems have been covered extensively
in other forums.
Although microsoft technicians have messed up access filters on its
routers in the past, I believe this is just them blocking some packets
used by the standard traceroute. If you are having other problems
with windowsupdate, I think they are unrelated to traceroute.
> > Um, it's firewalled? Most of microsoft isn't traceroutable or
> >pingable.
>
> Yup:
>
> b129$ ipsrvtrace -p 80 windowsupdate.microsoft.com
[...]
> 15 65.195.34.226 65.195.34.226 155.934 156.415 156.973
> 16 iusbsecurc1202-ge-6-0.msft.net 207.68.128.66 13.109 13.598
14.142
> 17 - - * * *
> 18 207.68.131.27 207.68.131.27 13.988 14.373 *
Microsoft has been moving/changing Windowsupdate.microsoft.com for
the last week or so. The problems have been covered extensively
in other forums.
Although microsoft technicians have messed up access filters on its
routers in the past, I believe this is just them blocking some packets
used by the standard traceroute. If you are having other problems
with windowsupdate, I think they are unrelated to traceroute.
Ok, well this is good to know. Although it still doesn't explain why my
firewall is reporting DNS UDP/TCP probes from windowupdate.com on a regular
basis.
-Tim
A couple of possibilities
- DNS cache poisoning sending spoofed answers to your DNS server (are
you running a current version of BIND or an alternative?)
- DDOS attack on windowsupdate.com using spoofed source packets (DNS
and HTTP packets can tunnel through most firewall configurations)
Here are examples of the bogus queries I've been seeing. Since this is
a non-windows machine, it has no reason to query windowsupdate.com for
any purpose.
Jan 14 22:08:47 clifden named[14504]: [ID 295310 daemon.notice] denied
query from [207.68.131.17].1029 for "180.53.34.199.in-addr.arpa" PTR/IN
Jan 14 22:08:47 clifden last message repeated 2 times
Jan 14 23:12:12 clifden named[14504]: [ID 295310 daemon.notice] denied
query from [207.68.131.17].1029 for "180.53.34.199.in-addr.arpa" PTR/IN
Jan 14 23:14:05 clifden last message repeated 5 times
Jan 15 00:24:56 clifden named[14504]: [ID 295310 daemon.notice] denied
query from [207.68.131.17].1029 for "180.53.34.199.in-addr.arpa" PTR/IN
Jan 15 00:24:56 clifden last message repeated 2 times
Jan 15 01:32:20 clifden named[14504]: [ID 295310 daemon.notice] denied
query from [207.68.131.17].1029 for "180.53.34.199.in-addr.arpa" PTR/IN
Jan 15 01:36:13 clifden last message repeated 8 times
Jan 15 01:38:19 clifden named[14504]: [ID 295310 daemon.notice] denied
query from [207.68.131.17].1029 for "180.53.34.199.in-addr.arpa" PTR/IN
Jan 15 01:38:19 clifden last message repeated 2 times
In a message written on Tue, Jan 15, 2002 at 03:49:24PM -0600, Tim Devries wrote:
Ok, well this is good to know. Although it still doesn't explain why my
firewall is reporting DNS UDP/TCP probes from windowupdate.com on a regular
basis.
Microsoft has in the past used load balancing technology that sent
DNS queries back to your machine/nameserver in an attempt to provide
you with a better performing (one can only assume lower latency)
server.
I suspect you may get "probed" approximately as often as you (or your
users) contact windows update.