I’m trying to enhance security by restricting the connectivity of Services (svchost.exe) and having difficulty in allowing windows update service. IPs of microsoft windows update keep changing, and settings update site as allowed Host Name didn’t help.
What should I put in Host Name? I can’t found example in help file.
I think youre absolutely right in trying to stop svchost from free access, it is a giant security hole since any dll can run via svchost. However, my conclusion is that this cant be done.
but I dont think they are complete. One example of an IP used on my PC resolved to this: cds81.sto9.msecn.net
which is not in any of the lists. And here also a lmitation with Comodo applies: You have to type cds81.sto9.msecn.net as host name, e g msecn.net or *.msecn.net wont work. So you can imagine how many variants of this address alone theer might be.
And Akamai arent seen as akamai.com, apparently they cooperate with others, in my case an IP resolved to a local telecom company, whose abuse address was abuse@akamai.com.
So the number of host names youd have to add is even more than the IP ranges you can think of.
The conclusion is that you will have to allow svchost out to any IP for TCP and UDP. Which really sucks big time. Theres a thread on this forum asking Comodo to make it possible to distinguish between which services that use svchost. That would be great.
The way things are now, its even doubtful if theres any point in having a firewall at all. If I wanted to write spyware I would just use svchost.
If you want a firewall but are not content with the security hole, then you can do one of two things:
A. Experiment with IP ranges (takes time, and will have to be updated now and again)
B. Disable Win updates (and do manual updates a couple of times per year or when you hear about some new malware onh the loose)
I realize the thread is old, but 2000 people have read it so it seems to attract attention
You will have to use address blocks, as domain names simply won’t work. It’s not terribly haed to lock svchost down, just a little time consuming, but once it’s done…
In the image below, the top blocks are Microsoft and the B-AK are mostly AKAMAI. If you create a rule that allows svchost out to ports 80 and 443 with a destination of a network zone, which points to these blocks, you can enable and disable the rule, by allowing or blocking when the need arises.
Blocking based on IP is in general not professional. Every now and again you’d have to add to your set of IP ranges. Some technically skilled home users might accept living with it.
Nice of you to post the IP ranges though, for those who want to try it.
Its going to be an issue where on the globe a CIS user resides concerning the IP addresses that SVChost will access.
It is for that reason that I showed my personal rules; they are all dependent upon IP addresses aggregated / sorted w/in zones.
Whatever system you use has to make sense to you. It makes no sense to implement a system that makes no sense, yes? Far better to implement a system that uses 5 unecessary steps - but make sense - than two steps system that is incomprehensible.
Hi! thanks for good info how to configure comodo firewall rules for Windows Update. Today i found that for some reason, my machine has been starting to want to contact port 8530 for Windows Update too. If this port is not open, Windows Update is not able to check new updates (error “Windows Updates fail error 80072efd” will be displayed).
If you have issue using only ports 80 and 443, i think it can be worth of checking if port 8530 needs to be open as well. Perhaps MS has been starting to utilizie this port too…?
Did not doublecheck this information very well yet though, but yes, for my setup this port addition was needed (Win 7 64-bit, Comodo 5.9, Avast).
EDIT / Correction: Now as i enabled logging and checked these logs traffic more closely, i found it was afterall other element, old friend Avast, again that was causing “harms” with it’s Web Shield. Avast wants to have port 12080 being open for svchost.exe, only then Windows Update succeeds. So port 8530 was not to blame on after all
