Comodo firewall really doesn't let anything pass

What can you do, when a program, despite having disabled auto-updates and cloud features, continues to want to phone home? You block it with your firewall! And in this case, Comodo can be relied upon to block itself (kudos to Comodo for the honesty of being able to block itself).




The bad thing, is that Comodo's log is spammed with dozen of "intrusions" of blocking itself. When the dedication of Comodo goes to extremes.

 

427 "intrusions" in 1 night. Cmdagent desperately trying to phone home, despite the fact that i have even sabotaged comodo's update URL (edited into nothing). Because if you just remove the URL, after a reboot, the URL is automatically inserted again and ticked.

While i was asleep, Comodo was still desperately trying to reach daddy-Melih.
Check the time on the right. Almost every 2 minutes.






That's what you call conflict of interests. The firewall wants to remain faithful to my orders, but also feels nostalgia for Comodo's paternal servers. To please both me and Melih, he tries to call dad, but at at the same time, feels oblidged to block itself. It's almost a family drama going on in my PC every 2 minutes. I almost feel guilty for separating a family...


P.S.: Melih, stop torturing my firewall! It's fully grown and out of the home now! Let it live its own life!

 

You could create a firewall rule with logging disabled for cmdagent.exe, but where would be the fun in that?

 

I am at 522 intrusions right now, when i reach 1000 i will actually do that. Not for anything else, but, even if it's fun having "proof" that the firewall works, it is cluttering the logs.

Thanks for the idea. Why didn't i think about it myself?

 

I had a similar thing happen when using their Comodo Dragon browser, finally had to disable it in the control panel under Administrative tools..

 

Melih is emotionally attached to his products. Anyway, after Nebulus gave me the idea, i made a custom firewall policy, exactly the same as "blocked application", with the difference that i unticked the "log". Interestingly, a custom policy of "block TCP/UDP in/out", wouldn't show cmdagent blocked. But "blocked" does. The difference, is that "blocked" uses "IP" instead of TCP/UDP in the rules. So i made the rule with "IP" (carbon copy of "blocked application"), disabled the log and FINALLY, i can have the log clear from Comodo, while certain that it blocks it (tested it).

 

FWIW:

1) IIRC, and with 5.x at least, some Comodo executables are listed as being "Windows System Applications" and "Windows Updater Applications" in Computer Security Policy->Defense+ Rules. I don't know if those Comodo files ever attempt to use the network, but I think some would have at least "Windows Updater Applications" allowed under Network Security Policy->Application Rules.

2) I once came across some information which suggested that cmdagent.exe is sometimes involved in certificate checking and blocking it could cause related shortcomings. I didn't try to flesh out the details. I'd be interested to know if you or others are familiar with this.

3) Quick lookups of destination addresses in your logs...

91.199.212.132 = secure.comodo.net, not sure what all that is used for
199.66.201.28 = licenseactivation.security.comodo.com

 

Correct, but this has to do with execution rights on the PC. Basically allows Comodo's exes to install freely whatever they want (updates for example). It doesn't affect firewall rules.

I read that too, in a Comodo forum post, after googling, but it seems nobody got a satisfying answer. Most of the time, the replies were "if you don't trust the program, uninstall it", or "why do you care". And nobody had an explanation as to why a firewall, would need to check certificates, despite one having unchecked all cloud options and auto-updates.

Yup. They 're Comodo servers... The first one, could make sense, if i had installed Comodo DNS, but i didn't. And the second doesn't make sense either, since it's free. I actually let it phone home for a while, just to see if once "satisfied", it would stop phoning. But no. Once i blocked it again, it started again the attempts to phone out.

So, since i can't solve the mystery, i block it and all is fine.

 

If you disagree that the File Groups called "Windows System Applications" and "Windows Updater Applications"... for which Network Security Policy (firewall) rules can be specified... are defined under Defense+ settings in Computer Security Policy->Defense+ Rules, I'd appreciate you pointing out where those File Groups are defined.

Sounds like we were in the same boat.

FWIW, I did as well and didn't *notice* any problems.

 

I am not sure if we 're talking about the same thing. In Defence+ Rules, there is the groups you mention, but the rules there won't determine their "fate" as far as the firewall is concerned:



Where Windows components (and Comodo's) will be "judged" for firewall rules, is under NEtwork Security Policy.

There, you will have cmdagent asking (well, not really, by default is set to allowed, but you can change it).
Also Windows services unless distinct, will try to use svchost. Windows Update will need remote 443 for example.

I only have allowed outbound (for svchost):
- UDP remote port 123 (time synchronization)
- IGMP out
- UDP Remote 1900 (router for Upnp)
- UDP Remote 67 (DHCP)
- UDP remote 547 (DHCP Ipv6)
- UDP remote 5355 (LLMNR)
- UDP remote 53 (DNS)
- TCP remote 80 to some Akamai servers my ISP uses.

- Block all else, incoming and outgoing. Never had any problem. When i do Windows Update i allow temporarily outbound 443 and then remove it again.

With these settings never had a problem.

Here are also some programs that help show what services are behind svchost by PID:

http://svchostviewer.codeplex.com/

http://www.neuber.com/free/svchost-analyzer/index.html

Yes, i would have prefered if Comodo simply sat quiet doing his filtering instead of trying to phone daddy, but, the firewall filtering seems to work. Cmdagent is blocked so is manual updating. When i try manual updates, i get:

Checking for updates...
An error occurred while updating.

 

Yes, my understanding is that the Defense+ rules *for* those groups will affect Defense+ rather than the firewall. However, since you can have firewall rules that target the specific groups mentioned, *which* files appear *under* those group names in that Defense+ Rules tab of Computer Security Policy *can* affect firewall behavior. I believe. I was simply attempting to draw attention to this because a) when I first saw this I was somewhat surprised as I didn't expect a Comodo file to be listed in a Windows System Applications or Windows Updater Applications file group, and b) the thread deals with blocking all Comodo network activity.

Unfortunately, it seems I added confusion rather than useful clarification. Hopefully the above is sufficient to clear that up. If not, I don't think it is worth either of us spending more time on.

 

Ah, i think i may now understand what you mean. I think you refer to default Comodo settings. Unfortunately i don't remember them anymore, since i 've made a configuration much time ago and since then i just import it, so all the rules are auto-set as i had customized them, but, i do remember that by default Comodo is "generous" with Windows Update, Comodo itself and svchost. I think i had changed all these in the firewall rules and i may have changed something to "ask" in D+ rules, but i don't remember details. It's probably what you mean too. I just didn't think of that.

 

I block both cfp.exe and cmdagent.exe from connecting out. I also have my cloud settings disabled, and the TVL deleted.

I don't know what those things are trying to do, but I don't need it. The FW works fine without allowing it.

 

Well, back when I was using Comodo's Firewall, I too change the rules and settings to stop it from contacting Comodo's server. I wonder who else on this forum does...

 

I have never blocked any of comodo,s connections.It needs to connect for you to receive your updates and cloud cover.I mean really if you dont trust the connections then why have their product installed.

 

This is true, as long as you have enabled "check for updates", "perform cloud based behaviour analysis" and "automatically scanned files in the cloud". However, with these disabled, why does it need? I mean, what's the point to disable them if they still want to do the job they do when they are enabled?

Trusting is good. Not trusting is better. (In Iobit we trust). I only trust the program to follow the settings i chose. If the program doesn't comply, then i have to make sure it does, one way or another, before i ditch it.

 

Maybe when at design stage they have never thought that anybody would want to disable all of those hence the attempts to connect out in vain (when ideally prog should know not to try anything as there is no need).

 

Yes, it's possible. It's obvious that some switch doesn't switch off... I even did let it phone home for a while, just in case it wanted to "activate" the license, but it continued afterwards. It also tried to do so, while the computer was idle all night. So it's rather obvious that it wants to check something at all costs... Maybe it's certificates as some said in Comodo forum. Anyway, the important thing is that it can be blocked. The bad would be if it was bypassing the firewall in order to phone home.

 

Come on, don't give them ideas...

 

Now that you mention it, when i will reboot, i will launch TCPView, just to check things from a "3rd" party perspective. As a Kaspersky labs expert said, "being paranoid in PC security is good, because it increases chances that you will spot something unusual going on".

 

Maybe for the Trusted Software Vendors list?

 

Who knows... It was even left overnight and every 3 minutes for no reason wanted to get new vendor's list? Could be, but it's overkill.

 

I installed the latest version of CIS and also tried just Firewall/D+ on multiple machines in different locations.

If I left the "default" config be for a couple hours, using wireshark and other tools to monitor traffic. Comodo goes out to those IPs to verify the license (whether free/pro/trial). Once a successful communication is made and a response is received the attempts to those IPs stop.

However, if I installed the latest version of CIS or Firewall/D+ and setup everything, including blocking for Comodo stuff you see those IPs continuously as it tries in vein to verify the license. Once I unblocked the various Comodo processes, it ended up verifying the license and the attempts stopped.

Also, if I installed the latest version of the above apps and tried to import a previous configuration, the IP attempts continued even after removing comodo processes from being blocked. For whatever reason, a response is never received from the licensing server. So I'm not sure if this attempt has something to do with using an older config.


But that's what we found using multiple test labs.

 

Interesting. I wasn't using the latest Comodo, but 5.10 and i did unblock it for a while, but it continued to try afterwards. So it could be the same as your last observation.

Then of course you have the theory in Comodo forum that it tries to check certificates... At any case, i block.

 

One approach would be to setup a prompt & log rule and run it that way for an extended period. Acquiring longer-term notes on when it happens, including both fixed intervals and possibly other times when something special was going on such as the installation or updating of some other software. Theoretically, the results *might* be OS specific and/or specific to some other application in use.

We need to be careful about making assumptions based on the remote hostname. It is natural to expect that a license check is going on when the remote hostname is licenseactivation.security.comodo.com, but that doesn't guarantee that it is or that the information used and passed for license checks is appropriate or that there isn't something else going on during such exchanges. For example, the client software using that window to pass telemetry data to the remote server. You really have to see the data being passed in order to assess it. I don't know if you can MITM those connections though.

Given that a new version has recently been released, now would be a good time to investigate it and try to answer any open questions. I may give it a whirl in Feb if my schedule cooperates.