CPU: 32 bit
OS: XP SP3
Apps: CIS (FW & D+), DrWeb’s Spider Guard 5
Administrator account
The newly released DrWeb’s updater is recognized by FW as ‘Windows Operating System’, however a simple TCPView test shows the process requesting the connection (screenshot attached). This is a very new behaviour for this setup, processes are routinely recognized by the FW. Am not using the PC for ICS, although the respective service does run. Setup is dual Ethernet cards, one of which is connected to the Internet.
So that’s TCPView’s bug then? I’m pretty certain it’s firewall’s direct duty to detect the process requesting connection, no matter how hard it tries to hide. In fact, the harder it tries to hide, the more important it it for the firewall to detect it.
I have the same/similar problem with mIRC. Some of the DCC connections are blocked as ‘Windows Operating System’.
I have the port range 36018-36027 setup in mIRC for DCC connections, and setup as allowed in CIS. The attached screenshot shows the logged events, some allowed and some blocked. Both cases with some IP’s which makes it seem even more arbitrary.
I just recently updated to Windows XP 64-bit, but I think it was happening on 32-bit XP too. I’ve been having DCC problems for a while, but only just noticed the block events in CIS logs.
Windows XP 64-bit SP2.
CIS 3.5.65951.477
I only have the Firewall portion of CIS active, and no other security related processes.
This problem is annoying so I decided to try reinstalling Comodo and starting front a blank slate, re-entering my application rules.
I’ve uninstalled and reinstalled it, disabled the anti-virus and defense+ once restarted, then entered my the rules for mIRC and tried it again.
The problem persists.
My application rules for mIRC are attached as a screenshot.