Hello, there was already discussion on this topic, but it went offtopic and is of older date, so i am creating new regarding my issue.
Like hourly i receive CIS firewall alert if i want to allow outgoing Windows Operating System connection. The IP and port differs, and i tried to lookup IPs at https://myip.ms to discover details. Though do not make me to understand which app makes this connection. On Comodo alert windows, “Show activities” shows “Cannot find process by this PID”. Any way to discover .exe causing the connection? What about KillSwitch? Killswitch does not allow sorting by port number nor filtering results and my computer makes hundreds of connections, so can not find it. (room to improve KillSwitch)
How i discovered .exe causing Comodo alert “Windows Operating System”
But i used System Explorer app and it has “Connections” tab which allows filtering, i type port number and it shows app which is attempting connection. This time it was qbittorrent.exe (i also seen ApexDC-x64.exe) which matched the IP and port the CIS was reporting as “WIndows Operating System”, so i think Comodo should fix the FIrewall to properly recognize application (the System Explorer app running with Admin. privileges recognized the .exe).
To see history of “Windows Operating System” connection attempts, i double clicked CIS tray icon, then clicked “Network intrusions” and found these Windows OS conn. attempts. Many comes from local port: 53358 (maybe my Soulseek app, when googling this port number)
Recently in CIS/Tasks/Firewall Tasks/Stealth ports/ i enabled option to alert incoming connections in aim to make WebTorrent app working. (it seems CIS or Windows firewall blocks its incoming or outgoing connections somehow even the app was marked as “Allowed” when the app first connected internet)
Anyone else bothered by general “Windows Operating System” alerts, please add your feedback into this bug report.
Thanks for the feedback, i read on that page:
“What else it would block exactly I’m unsure so that’s why the suggestion to create separate rules for each process. Then you know exactly what’s outgoing.”
What bothers me that i and others have to be bothered
A) asking at forums and then finding possible .exe’s in System32 folder and creating separate rules for these in hope Comodo will start to recognize the connections
B) permanently blocking/allowing Win. Op. Sys. maybe important connections putting uncertainty in their mind
While Comodo programmers maybe can make the firewall to properly detect the .exe (System explorer app. i mentioned is able to pair these "Win. Op. Sys. connections to particular .exe - i mentioned it in my first post).
Yes, i also think a Firewall Should ALWAYS provide information on what is actually trying to make an outgoing connection. WOS doesn’t actually help.
It is a LIMITATION of Comodo Firewall (no matter what they try to call it or downplay it). If a dll or exe can “cover” itself as WOS, then we have a problem, don’t we ?
I also see that problem when Installing some software. When the installation starts EXPLORER.exe tries to connect to the Internet. Apparently it is NOT Explorer but the Installation script that Phones Home.
The problem is that another driver may be metaphorically speaking be blocking view for CIS. Drivers run in the kernel together with CIS drivers. They have the same rights as CIS and are allowed to do anything with sometimes unexpected consequences.
The only way to find out what driver is causing is to unistall programs that use drivers to see which one stops blocking the view. I know of no other way to determine as an end user without advanced knowledge of Windows internals. Once the driver is identified a bug report could be filed. I can’t make it any more beautiful. :-\
The installer either calls Explorer.exe or it starts a program with the exact same name but from a different location on the disk. Installers when they are trusted, either by whitelist or user permessions, are by allowed to do anything without alerting and asking the user.
On a side note. I have seen a malware once starting a process called explorer.exe with matching icon which wasn’t the original explorer.exe and was running from a different folder. I was following its behaviour by going step by step with HIPS alerts.
I agree wholeheartedly with the OP on this one. It’s something I have always longed for from Comodo.
On Explorer.exe, this usually happens when an installer (or other unruled executable) is launched from an open folder window (or Start Menu or from a pinned hotlink on taskbar). Fires the Explorer rule automatically every time, and if a net request is made, Explorer.exe and only Explorer.exe is on the alert.
From a programming perspective, couldn’t Comodo simply keep an open dialog of applications/executables and then note when they are responsible for Windows executable alerts (add the info to any of the alerts)?..Honestly to me this appears to be a hole that could be patched.