When I installed Comodo 3.9, I had my PC IP assigned dynamically via DHCP from my router. I subsequently changed my PC IP to a static address. I created a trusted network in Comodo for the static IP.
What I observed afterward is that certain update applications were being logged as their did when they were first allowed. However, other updater application were not being logged. So I deleted one of the unlogged updater apps and let Comodo catch it. I then allowed this app as an outbound app. I then checked my log and low and behold, the update app was logged when attempting to connect.
So my question is when changing trusted networks, are existing app rules not updated internally to reflect the new network? It kind of appears that way from what I am observing.
Well, my original post manipulations still did not catch outbound application updates as I thought it did.
The application in question is AntiMalwarebyte’s updater. What it presently appears to be doing for updates is connecting using svchost.exe on port 53 UDP to my ISP DNS server. The Symantec Endpoint 11 AV definition updater is doing the same thing. As such, there is no way to create a rule to block this activity since it appears to be normal svchost outbound UDP port 53 activity. If there is outbound TCP activity to the appliication vendor’s web site; it is not being logged.
Hi DonZ, if you’d rather not have svchost performing DNS queries, which is the norm, you can disable the DNS Client service. If you do this, however, you will have to create individual DNS rules for each application that requires Internet access.
What I am concerned about is the appilication I allowed for AntiMalwareBytes updates is mbam.exe. When I run an update, it appears the update application is connecting via IE7. This I confirmed by watching what was running using TCPView. All I see in the Comodo log is the svchost.exe entry. No entry for IE or mbam.exe.
Same thing occurs when the Symantec Endpoint AV updater executes. I see no log entry for LiveUpdate just a svchost.exe log entry.
Yes, I see the same active connections as you show but the IP I am connecting to for mbam is different than yours. The IP is 220.127.116.11.
My original question was however, why doesn’t mbam.exe appear in Comodo firewall log as allowed? Like I originally posted, some update applications I have allowed appear in the firewall log when they execute. Others do not. Why?
I did change the originally allowed mbam rule to outgoing only and I turned on logging in the predefined outgoing rule.
Yes, when I deleted the mbam rule and let Comodo catch it again and I alllowed it, that is the log entry I saw. However, it never appeared again on subsequent updates. From what I saw using TCPView, the connection to the mbam server was done using IE. Equally disturbing was that IE connect was not logged. The only evidence I saw in the log was a svchost entry for DNS.
My Symantec Endpoint AV updates are doing the exact same thing - only a svchost entry in the log file.
Now updates for SuperAntiSpyware and A2Squared are being fully logged.
Doesn’t give me a lot of confidence in Comodo’s logging capability.
Two connects are made for AntiMalwareBytes. One for svchost.exe port 53 to my router which I assume is DNS and one using IE to port 80. The Symantec Endpoint AV definition update does the same thing. All that is logged is the svchost connects.
All the rest of my updaters; Adobe, SuperAntiSpyware, A2Squared etc. are logged showing their respective update programs.
I will be out of town for a while so I will respond only infrequently.
Hi, Apologies if I’m being a bit dim, but I just want to make sure I understand. Are you saying that when you run the updater, you don’t see mbam.exe in TCPView, you see instead IE connecting and performing the update.
Just downloaded the latest version, 1.4, of AntiMalwareBytes via their updater. Low and behold, mbam.exe now shows in Comodo firewall log as allowed. I am beginning to believe that perhaps I have entered the twilight zone as far as Comodo logging capability is concerned … 88)