Include PID (Process ID) in pop-up alerts and in the event log [M1945]

Comodo Internet Security - CIS Verified Wish Reports - CIS
1

Hi,

I often get firewall alerts which read a svchost process tries to do something. There are several svchost processes running on my WinXP system. How do I know which of them triggered the alert? Why not include the process id (PID) in the alert?

Thanks,
Al

2

Dear Comodo.

Is there a way to find the PID of processes / executables trying to access the internet. I see only the application name, remote port, protocol, & ip on the notification (firewall alert). I see that the PID is listed in the active connections, so this seems doable.

Then, the PID can be matched to a list of processes from, for example, process explorer, to see which instance of a program is actually trying to access the internet. This would be useful for example in the case of svchost.exe which is used for a bunch of different apps/services, (without allowing it to access the internet first, then seeing on the active connections list which PID it actually had.)

3

Why don’t you go ahead and add a poll?

Anyways, I think this would be good, although it isn’t really the biggest requirement of process management.
As said it shouldn’t be so big deal to show it in notifications too.

4

I agree completely. So many apps hide behind host processes it makes it extremely difficult to track down what is doing the communicating.
A lot of malware out these days like to attach as a sub process to several legitimate files that already should have access through a local firewall.
I think the days of running a randomly named bit of code is long gone. The current methods use legitimate pathways to bypass communication blocks.

So I vote yes, absolutely need to ID PID in the alerts and log, and even the sub process.
I haven’t read the manual for several years but I am almost certain that even sub processes attached to a legitimate process such as svchost.exe have to issue a unique token to get a request processed.

svchost.exe can act as a proxy for all of the following and more, making it an easy way to get around local firewalls. DcomLaunch, PlugPlay, Power, RpcEptMapper, RpcSS, CryptSvc, Dnscache, AudioSrv, Dhcp, eventlog, wscsvs, AudioEndPointBuilder, hidserv, Netman, SysMain, UxSms, Wlansvc, WPDBusEnum, wudfsv, Appinfo, EAPHost, gpsvc, ProfSvc, Scheduler, SENS, ShellHWDetection, Themes, Winmgmt, EventSystem, nsi, BFR, MpsSvc, and FontCache.

That is not all, that is on a VERY basic install. All of these services can be impersonated and used to bypass a firewall that limits by host processes rather than what is using the host process. A lot of these services can host entire server systems behind them, and with CIS 5.9.xxx current logging facilities it is darn near impossible to track down which service is misbehaving.

5

1. What actually happened or you saw:
When a firewall pop-up appears, there is no PID (Proccess ID) given, associated with every process in Windows.
When browsing firewall records, the PID is not given either, only full paths to applications.

2. What you wanted to happen or see:
To determine which svchost.exe Windows processes trying to access the network (there are many, every one of them is called svchost.exe but they differ from each other with the Process ID).

3. Why you think it is desirable:
There are several processes called svchost.exe in Windows systems, as it is a container for running Windows services.
To determine exactly which Windows service wanted to access the network, you have to know the PID to distinguish between many (svchost.exe)s. Then, knowing the PID number, you are able to locate a proper name of Windows service that tried to access the network.

4. Any other information:
Might be added when needed.

6

Good idea in my opinion. :-TU

7

I second this idea, but it would be even more helpful to pick apart separate components (cf. thread:

8

The process or number it is very difficult to get those that are actually used by the system. One way around this problem could be denied by default, except the essential system services and other applications. In this case, the most correct would be to determine what services they use through the “service manager” (svchost). Even restricted, there would still be a need to identify requests by other processes, block certain type of request and the encryption through insurance (system) or signed process, x: .… / (commands via cmd) …

9

Hi,
Yes please, comodo dev team, include the PID in firewall alerts related to svchost.
The best would be to retrieve the service name and display it too.

10

Merged topics of an already format verified wish request.