First, thanks for your products, I truely appreciate them.
Situation: My firewall log is stuffed full of blocked Unsolicited (?) Incoming TCP from 85.91.228.132 (www.Comodo.com) Ports range around 1033 to 1039 and also 72.20.6.62 (NS0.Comodogroup.com/us2.cownload.comodo.com) (similar ports). I have also, on other days been innundated with blocked Inbound TCP hits from 83.170.113.144 (eu2.comodo.com) & 208.122.24.146 (us3.download.comodo.com. All my Comodo products (set-up as Trusted Apps) are set in Application Rules by default “Allow IP out . . .”; this was done automatically when v3 ran it’s set up. Why/what is this UNsolicited (inbound i.e. not outbound reply) traffic? Is it some type of update function? On the activities screen I have seen i-Vault in communication with 85.91.228.132 playing by the rules.
I would prefer to see only real bad-guy blocked traffic in my logs. Should Comodo products (I have Firewall v3 & i-vault+Launcher of course) be set to “Allow IP in any any [1033-1039]”?
(WinXP SP2)
I do not have any such incoming connection requests on my log. I would not accept them. There is a possibility that they could be spoofed headers that actually originate elsewhere, but have altered headers (falsely reporting that they come from Comodo) to conceal their origin.
BTW these are all logged to “System Idle Process” which I noticed in Defense+ “Active Process List” is at the top of the first (of two on my machine) expanding list which includes a plethora of mainly Win XP services/processes plus one Comodo process: C:\Program Files\Comodo\Firewall\cmdagent.exe. Cmdagent.exe is the only Comodo file listed under the “System Idle Process” expansion tree on my machine; the other three Comodo files listed in Defense+ “Active Process list” are under the C:\Windows\explorer.exe expansion/tree. However when the firewall installed and automatically set-up my Comodo programs (the firewall + i-vault) and listed them in Firewall “Network Security Policy” “Application Rules” cmdagent.exe is not listed. So the fact that it is not set-up in “Application Rules” and that it is the only Comodo file listed under System Idle Process which is the listed “application” in the firewall log should I manually set-up cmdagent.exe in “Application Rules”? Is that the problem?
Is v3 lumping any application/process under the “System Idle Process” to SIP in the logs instead of listing the specific app/process? Seems like a step backwards to less info, better a step forward to more info, no? :THNK :THNK :THNK
Also the v2 firewall logs had a little more info for each log entry, I miss that extra detail
Yes, I think you need to set up Cmdagent.exe manually. The problem likely arises because outbound requests are allowed, but without an application rule for Cmdagent, the reply is probably not allowed by the existing rules. The System Idle Process is a convenient way of listing connection attempts that do not have any other target that is defined in the firewall. I am guessing that the reason that Cmdagent appears under it is because it had sent a message that came from an “unlisted” program.
Thanks AnotherOne. I appreciate your time. I don’t think the IPs are spoofed; it just feels/smells more like a setting is not set-up ideally.
So is cmdagent.exe set-up using a “Predifined Policy”: “Trusted Application”, “Outgoing only” or by using some custom rule; if custom then what are the Comodo recommended parameters?
What is the function of cmdagent.exe (Is it an updater, does it query the mothership)? Under program “Properties” it is described as: “Comodo Service Agent” (what’s that?).
Should v3 have picked it up and defined it (i.e. Did everyone have to manually set it up/did I miss a memo)?
Is it part of i-vault, Firewall v3, LaunchPad or all of the above, or which?
Hmmm this is strange why will comodo “phone home” anyhow…
its either updates or some defence+ online db query thing i think but the big question is why it dosent have a rule by default if its needed (:TNG)
EDIT: maybe its related to this known bug “CFP can not find the application behind a connection(for example kaspersky web scanner)”
Probably worth going to the beta forum and downloading the Comodo 3.0.14 test version. Some of the strange logging is reported to have been solved in that version. But Comodo doesn’t inundate me with inbound connections either, so I can’t tell. What are the source ports of the inbound connections?
The source port was always 80. However, just today the source port jumped to 443 and the destination port started out in the 1033-1039 range and jumped to 2306, and 1288, and 1290 and a dozen others.
I block (and not log) all requests from http ports to the System Idle Process (now Windows Operating System in 3.0.14). These items have been discussed in other threads and seem to include delayed housekeeping response messages to your http requests that don’t affect anything if you ignore them. But try 3.0.14 with the default Comodo generated rules, add back your custom rules later as required. Port 80 is the regular http port, port 443 is the secure https port.
Now you’ve got my curiosity piqued sded… Where is the Windows Operating System entry? I have installed 3.0.14 and I don’t see it. Do you mean the System entry, or am I missing something?
anpmech007 - you can use the Outgoing predefined policy for Cmdagent.exe if you don’t want to update to v3.0.14 yet.
Go to the Network Security Policy and select add/select/running processes. You should see a tree, with Windows Operating System at the top, and system and some other stuff underneath it. This is a recent addition to Comodo, and when I put all my rules under “System” (which you see below WOS in the tree) some stuff didn’t seem to go away. So I added WOS with rules imported from system, added my new stuff, and deleted “system” (which used to cover System Idle Process) and haven’t seen any problems yet from doing it this way. At least now the log and the rules are for the same thing. Maybe fixed in the next version?
Found that some things were blocked by system, even though allowed by Windows Operating System. Looks like they require separate rules anyway.
No inheritance in CFP.
Now I strongly suspect Comodo i-Vault. I tried adding cmdagent.exe to “Application Rules” & set up rules for outbound: no change. However using TCPView ivault is listed as Close_wait on 85.91.228.132:80. At this time I don’t know what “Close_Wait” means but i-Vault seems to be in some kind of wait state and the IP is www.comodo.com. Will keep trying to resolve this mystery.
Question: Does anyone else have Comodo i-Vault installed and running; if so are your firewall logs filled with unsolicited inbound TCPs from 85.91.228.132?
Frankly i-Vault works only middling well; even on this forum i have to keep manually entering my name/password. On logons where it works it works fine, it is just that it doesn’t work on about 30%-40% of logons.
Your report looks like iVault is waiting for update info (checking for newer version). It may be blocked by the firewall. You can give iVault permission in CFP by clicking Firewall>Advanced>Network Security Policy. On that page, locate and select the entry for iVault. (if there is none, click Add and click the Select button and then choose Browse and locate the exe for iVault and select it. You will then be on the Edit page mentioned next.) Click Edit and then select the “Use a Predefined Policy” button. Click the drop-down beside it and select “Trusted Application” and then click Apply and Apply. The inbound connection attempts are often for applications that do not have an entry in the Network Security Policy page, or have one that does not permit incoming connections. The Global rules permit outgoing messages, but the incoming messages are blocked unless they have a rule permitting incoming connections.
Maybe fixed in the next version?