If you configure the firewall using “Firewall → Stealth ports wizard” and would like to be visible for example in 192.168.0.1/255.255.255.0, the rules are created successfully (i.e. two rules for system and two global rules).
I have another rule in “Network security policy” for svchost.exe, which allows additionally Remote desktop for all users (this rule is after the system rule in the list of Network security policy), consisting of: 1st rule for incoming TCP connections, 2nd rule for outgoing TCP or UDP connections, 3rd block and log all others.
Guess what: If you try to connect from a computer in zone 192.168.0.1/255.255.255.0 the rule for system doesn’t fire, but the svchost.exe rule fires. This results in blocking the access. Maybe svchost.exe isn’t considered a Windows system application anymore? On Comodo Personal Firewall this was never a problem.
Rather simple: I had to add the same (two) rules, which were already in System, also to svchost.exe, but before the other three rules mentioned above.
If needed I can also attach a CIS config report, but it shouldn’t be needed imho.
I don’t believe svchost inherits the CFP/CIS rules of its parent process (System). If System was used in conjunction with svchost to perform the network action, then yes both rule sets would be tested… otherwise no, System would have no direct impact on svchost. So, you do need to add your LAN (it’s easier to use the Network Zone name btw). I think svchost’s default rule is anything to everything, so the Block & Log changed things.
PS The restrictions you’ve placed on SVCHOST is good security, but without some additional rules you might have broken Automatic Updates & some other things.
Thanks for the fast answer. As I said… I never had any similar problems with Comodo Personal Firewall v3.0.25. I then exported the rules, uninstalled CPF, rebooted, installed CIS (with Antivirus), rebooted, imported my rules and deleted all other configurations.
That’s why I thought it would be a bug… and no, there went nothing wrong with the importation of the rules. (As I stated I also tried to delete the old rules for svchost.exe and Windows system applications and to set them up using CIS. This also hadn’t worked, so I used the Stealth ports wizard with the same result.)
Bug or not? It’s not really for me to say, I cannot replicate this issue. So, I’ll leave that call to you.
Did you notice that Vett’s svchost rule is actually the “Outgoing Only” Predefined rule? On this basis, I think it’s probably fair to say that Vett’s requirements of svchost is somewhat different to that of yours.
OK. So, issue is that something (we’ve not determined this yet) changed between the CFP 3 & CIS 3.5, which resulted in an unexpected blocking of svchost with CIS 3.5, where under the same conditions & rules was not blocked in CFP 3. Is that correct?
Yes, I also used the “Outgoing only” rule, but had to change it a bit: As I said I added the support for allowing also Remote desktop (and now the two rules for allowing 192.168.0.1/255.255.255.0). That are the rules I applied - i.e. I allow more than actually the outgoing only policy does.
