comodo update blocked by sonicwall for suspected trojan

ok, so I get an alert that there are updates available, and I click to proceed and after a few seconds, nothing. Later in the day I check the FW and the version has not changed. The next day I get the same alert there are updates, try it again, nothing again. My Sonicwall firewall log tells me it’s blocking due to a trojan:
01/17/2011 12:53:41.544 Alert Security Services Gateway Anti-Virus Alert: Banbra.XXE (Trojan) blocked 205.234.175.175, 80, X1, vip1.G-anycast1.cachefly.net

Could there be an issue with the mirror distributing the update? Is there another location from which I can get the update? I am running product version 5.0.163652.1142 with the signature database version 7420.
I assume the update is to version 5.3?

Thanks for your help!

Firstly, scan your computer with MBAM and/or SUPERAntiSpyware, as your computer seems to be infected. After that, go to More → Check for Updates in CIS and see if you can download new version that way.

Thanks, but my computer is scanned daily with updated databases for both MWB and Comodo. It’s always clean. This is our company firewall that is blocking the download, not my system. I get the same issue when I try to use check for updates. In my Comodo setup the update is set to come from download.comodo.com, so I am not sure why the Comodo updater is pulling down from the anycast1.cachefly.net site. If I manually go to download.comodo.com and download, it comes down through our firewall just fine. There is an issue with the anycast1.cachefly.net location.

I will run the update manually now that I have it downloaded, but I wonder if anyone is interested in
checking anycast1.cachefly.net to see what’s up?

If I recall correctly, this is a Tucows domain. Do you have problems downloading files in general from Tucows?

I also see regular connections to IPs associated with that host during windows startup. Comodo shows explorer.exe as being the source, and explorer.exe has no business at all initiating outbound connections.

If Comodo Update is indeed the culprit, the process that needs to be shown is cfupdat.exe. cmdagent.exe also initiates connections to outside IPs on ports 4447, 4448 and 80, which it shouldn’t. Not on 80 because I have neither AV nor Defense+ activated and not on 4447/8 because my sandbox is set to “disabled”.

On the positive side, at least the firewall is able to block its own connections - it would be infinitely worse if those were silently permitted for being “internal” connections. So, my trust in Comodo remains unbroken, but more transparency would be desirable.

CacheFly is a Content Delivery network use by Comodo for mirroring, so I’d guess Sonicwall is reporting a false positive. CacheFly - Wikipedia.

I also see regular connections to IPs associated with that host during windows startup. Comodo shows explorer.exe as being the source, and explorer.exe has no business at all initiating outbound connections.

That depends on services you choose to use, some, such as federated search will require Windows Explorer to have Internet access. However, for most home users, blocking access to the Internet for Windows Explorer is fine.

If Comodo Update is indeed the culprit, the process that needs to be shown is cfupdat.exe. cmdagent.exe also initiates connections to outside IPs on ports 4447, 4448 and 80, which it shouldn't. Not on 80 because I have neither AV nor Defense+ activated and not on 4447/8 because my sandbox is set to "disabled".

If you remove the checks from the two boxes found under D+ Settings/Execution Control, for cloud services, this won’t happen.

Thanks, that did indeed stop those connection attempts. However, I think having to go into D+ settings is counterproductive when D+ Security Level is set to “disabled” initially. The general “disabled” setting should automatically disable all other settings.