Here’s what I found on the Windows Pro Site… maybe it’ll help…
A. To display which process ID is using a certain TCP port or UDP port, you can start by using the Netstat command with the n (display in numeric form), o (display the owning process ID–this works on Windows XP only), and a (display all connections and listening ports) switches as follows:
netstat -noa
For example, the command
C:>netstat -noa
might produce output like the following:
After you have this information, you can use the Tasklist command to match a particular process ID to a task name. To search for a specific process ID, use the following format:
C:> tasklist | findstr
A sample command and output might look like
C:> tasklist | findstr 712
lsass.exe 712 Console 0 1,792 K
The sample output indicates that the task lsass.exe is using process ID 712. If you’re using Windows 2000, you can accomplish the same task by using Tlist instead of Tasklist.
But I know this. I’m using ProcessExplorerNT instead. Its same, but with GUI.
OK, this would then mean, that 0.0.0.0 indicates, that an appkication wants to listen to UNrequested data on a port. (e.g. it by now is not knowing wich IP will come speak to it).
So, in easy its = “open a port for TCP inbound traffic”.
For this case, it is Internetnet Explorer, wich “opens port”.
What I dont understand is, why is the monitor network rule not blocking those UNrequested traffic, so that I can see a difference as if I allow inbound in the application rule for IE.
Hm, is that maybe: IE opens a port for listenig, at this moment, the APP rule sees it and prvents any further traffic to that port. After a while IE gets an REQUESTED packed on that port, BUT it is skipped for the APP rule, that “thought” it would be a port for only INBOUND traffic.
Is it possible, that this is the reason for that behavior ??