What are the IP ranges to allow to ensure Automatic Updates is working?

Frequently Asked Questions (FAQ) for Comodo firewa
#1

Hi,

As svchost.exe is a pretty opaque process, and as such a possible vector for malware, I do really want to fine grained its related rules. THerefore I don’t want to allow svchost.exe full outgoing TCP access granted. I already tuned it for most of my needs.

However, one for which my rules are not complete is for Automatic Updates (not Windows Update accessed using IE, but AU in charge of downloading the patches in background, and possibly installing them depending on your choice).
Here is waht I currently have:

  • allow range [207.46.0.0-207.46.255.255] TCP out on port 80,
  • allow range [64.4.0.0-64.4.63.255] TCP out on port 80,
    There are for sure other ranges to add, could Comodo guys give us the exhaustive list?

BTW, I found a list here: firewallleaktester.com - This website is for sale! - firewallleaktester Resources and Information., which is related to the news described at firewallleaktester.com - This website is for sale! - firewallleaktester Resources and Information., under the title “June 10 2006 : Windows BITS service bypasses default firewall rules”. However, what annoys me is that it is recommended to allow full range for akamai addresses… I’m a bot reluctant to grant access to a full non MS access for an MS specific program aiming at looking only for MS stuff…

Thanks in advance

#2

You could set Alerts to “High”, then every time svchost trys to access windows update you will get the IP added to your rules. That way you can build up a list of IPs and edit the rules to make ranges out of these new IP’s. Thats how I set rules up.

They vary a lot so you might not get a definitive list. Some people say they have one, but I have never been able to. They may depend on where you are as well so someone elses list may not apply to you.

#3

I think you’re right SteveC. I think it also matters what OS you’re running as to where WU goes… and as for the IP numbers… I don’t think you safely depend on them. Mainly since WU uses names, rather than IP numbers & these can obviously be changed by MS.

#4

I wonder if CPFs rule option “Host Name” would work instead of specifying the IPs.?

#5

For WU, I think that would be the better option. But, I’d bet MS also change the names without notice as well.

#6

Well that would be nice, but unfortunately I’m afraid this is not working, indeed as soon as I specify either “update.microsoft.com” or “*.download.microsoft.com”, it seems to be taken into account by CPF, but in the list it is surprisingly displayed as “[Name : update.microsoft.com] - 192.168-255-255 - 192.168.255-255”.
I wonder why this address is added, the worse is that it is a private, ie. non-routable, broadcast address…

Note: I did not have time to install the latest release as yet, so these findings are from the 2.3.3.33 beta.

HOwever, I agree that would be the best solution, AFAIK it is applicable on other FW (like Jetico). From what I found, the list of names should be:
*.download.microsoft.com
*.windowsupdate.com
*.windowsupdate.microsoft.com
windowsupdate.com
windowsupdate.microsoft.com
update.microsoft.com

Comodo guys, what do you think?
Is such a list applicable for rules in Comodo? Including those with a wildcard?
Why 192.168.255.255 is displayed along the name once entered?
Is this the best solution for fine-grained rules to allow AU?

Thanks in advance

#7

Yes. But, *'s should be V4 & V5 for W2k… No, idea what they should be for XP.

One additional consideration. Not all WU connections are HTTP, some are HTTPS. On W2k, it uses HTTPS on V4.windowsupdate.microsoft.com & V5.windowsupdate.microsoft.com as well as HTTP.

But, I’m not a Comodo guy. So, maybe it doesn’t count. ;D

#8

Ooo… one more thing. CPF did (that last time I checked) retain the names used in rules. CPF was just resolving them at run-time for display and, I assume, for using. Which is (or was) sensible.

#9

if you type in “update.microsoft.com” in IExplorer, mine goes to:

“Microsoft Update”

just a guess, maybe thats why you get 192.168.255.255 as its forwarded to another host.

#10

@Kail: well… you could be right, anyway I think that if MS recommends to use a wildcard this is for a good reason, either this is not limited to v4/v5, or it could change in a undetermined future…

@SteveC: sorry but your explanation is not valid from a networking point of view, this address is a private one, non-routable on the Net, and, as underlined, moreover a broadcast address. So it couldn’t, by no means, map to any valid host.

Thanks guys for your suggestions, anyway I’d also like to read the position of Comodo about my above post… any “Comoder” monitoring this forum? :wink: