For many years now I have used Comodo Firewall (and firewall only) and it has become one of my most trusted applications. I only install Comodo Firewall on my system, i.e. during the installation I disable Defense+.
Recent events brought up questions which, hopefully can be answered here.
Number One:
I switched my antivirus to Webroot SecureAnywhere WSA 2012. Unfortunately it didn’t work as expected, the most annoying thing being frequent application crashes.
I soon found out that disabling the antivirus protection returned the system to normal behavior. So naturally I assumed it must be Webroot’s software.
I wrote to their support and in the two weeks ensuing countless messages were exchanged. When at last support suggested that it might be a problem with Comodo software, I was set to prove them wrong.
On a fresh install I tested the software without problems until, you guessed, I installed Comodo firewall.
I found a solution to the problem: I enabled defense+ and it soon triggered an alert for WSA. I allowed the behaviour and created a rule for it. From then on the system ran smoothly again. After that I simply disabled Defense+ again.
Why does Defense+ interfere with running applications when it’s disabled?
Number Two:
After that I kept a more closer watch over Cfw behaviour and removed all the rules for Comodo applications in my firewall.
And to my surprise when installing new software cmdagentexe frequently asked for internet access, obviously for checking the certificate status of the installation files.
Im running Windows 7 and I’m confident that my OS can check when there is need.
Who told Comodo firewall to check certificates?
Number Three:
Today cmdagent.exe asked for permission to connect to my ISP via TCP on Port 80.
Isn’t that fishy?
I disable Defense+, because I definitely only want the firewall functionality. Is anyone able to shed some light on this? :-La
It depends how your ‘Disabling’ Defense+. Going to the tray icon and selecting Defense+ Security level > Disabled is sort of a quick test to see if actions taken by Defense+ blocked something, but due to the nature of the beast Defense+ has get to low down to the system to intercept and monitor inter process/memory/files/handles, etc, which means hooking in at boot time, hence the Defense+ driver ‘Guard32.sys’ still loaded in memory and still has its hooks in place so that Defense monitoring can be toggled without having to reboot the whole system.
To fully disabled the Defense+ module (ie: stop loading the driver) go to Defense+ > Defense+ Settings > Check ‘Deactivate+ permanently (Requires a system restart)’
as I said, during the installation process I deselect all proactive functions. This results in D+ being disabled permanently. After installation I uncheck all other options. Cloud scanning disabled, sandbox disabled… to no avail. It seems it is not possible to turn it off…
I am not sure what is going on here. What version of WSA are you using? AV or Complete?
What was happening with your system other than crashes when having both products installed?
What did you allow in D+ to make the problem go away?
Number Two:
After that I kept a more closer watch over Cfw behaviour and removed all the rules for Comodo applications in my firewall.
And to my surprise when installing new software cmdagentexe frequently asked for internet access, obviously for checking the certificate status of the installation files.
Im running Windows 7 and I’m confident that my OS can check when there is need.
Who told Comodo firewall to check certificates?
How did you check that cmdagent.exe was checking for certificates?
Number Three:
Today cmdagent.exe asked for permission to connect to my ISP via TCP on Port 80.
Isn’t that fishy?
What do you mean with CIS is connecting to your ISP? What IP address was it trying to connect to?
I’m using Webroot Secure Anywhere 2012 Antivirus.
The application crashes were limited to some apps. As soon as I enabled D+ and started one of the applications I got a D+ warning concerning suspicious behaviour of WSA. I clicked allow and made a rule of it. After that all problems disappeared.
As to your questions about cmdagent.exe: After that incident I didn’t totally trust Comodo software, so I removed all Trusted rules for cmdagent.exe from the Firewall. That is why from then on I got alerts about cmdagent connections.
The certificate checking occurs when running installers.
Usually the addresses are from verisign or comodo connected with crl and ocsp. At one time the connection request was to the address of my ISP.
I’m sure that this is not specific to my system. I never noticed all these connections the years before, because by default Comodo executables are allowed all outbound connections. It was only after I removed the “Comodo Updater applications” rule from the firewall that I first noticed that there’s far more than updating going on. (By the way, automatic updates are also disabled)
I always believed that when I set D+ to disabled it should be disabled.
Behavior blocking and certificate checking are definitely not firewall features.
So in a way I’m saying that this is possibly a bug in Cfw.
“Bug: Defense+ is not really disabled even if all relevant settings are set”
The connection to my ISP I don’t understand at all. Could be a DNS request but still strange on port 80 TCP.
If any one has an explanation for that…
under Execution Control disable under Automatically scan unrecognized files in the cloud
I just installe WSA AV 2012 with D+ enabled but saw nothing out of the ordinary. It is a trusted file and did not get flagged as a potential virus. I have the AV heuristics at Medium.
EricJH, thank you for taking an interest in this topic.
I use the firewall installer, so the antivirus is not installed.
Yes, the cloud scanning features are disabled.
The installation of WSA ran without problems for me also.
I was able to reproduce the behaviour in a virtual machine.
If you install WSA with D+ enabled you will not encounter problems, as Comodo will do a cloud check and whitelist WSA. So the issue is only reproducible if you install WSA with D+ disabled (go figure). That way it will not be whitelisted (wasn’t for me certainly).
I’m running Windows 7 64 Bit, the issue only occurs with running 32 Bit executables.
The executable in question must not be whitelisted in WSA. For example Firefox will run without problems, as it is a well known application and already trusted in the Webroot cloud. I experienced the problem with lesser known programs. XYplorer file manager, Event Log Explorer and even Dependency Walker 32 Bit version.
I believe that executables, that are not yet whitelisted in the webroot cloud, will be monitored specifically by WSA. At that point the issue is being triggered.
Can you try disabling the loading of guard64.dll on start up using Autoruns by Sysinternals? I want to see if loading of that dll plays a role with your problem.
OK, finally got the time to create a new VM and did some experimenting.
Things get curiouser and curiouser…
First I installed WSA. Then I installed Cfw and customized the installation so that D+ was disabled from the beginning.
The “crashing applications” behaviour returned.
Disabling guard64.dll in Autoruns didn’t change anything. (I checked with Sysinternals listdlls tool to verify guard64.dll was not loaded)
Now comes the interesting bit.
When I opened Autoruns on my regular system, there were no AppInit entries. Neither guard64.dll nor guard32.dll are in any autorun location on my system. Again I checked with listdlls and neither are loaded on my system.
I don’t want to bore you with the details, but this is what I found out:
When installed with D+ disabled both guard32.dll and guard64.dll are in autoruns.
If you enable D+, restart and then disable D+ again and restart both entries disappear magically.
All I can say is that Firewall appears to be working properly on my system without guard32-64.dll. I guess they’re not needed for firewall functionality.