Inbound ICMP - Which Windows process?

Which Windows process should be the recipient of inbound ICMP packets in Application Rules?

See image, this is from my logs and have been generated when using my torrent client. In Global rules I allow ICMP Destination Unreachable In, as suggested in the uTorrent guide, but obviously these packets need a place to go, should I add rules to uTorrent, as the WOS is actually non existent? Or maybe System?

Thanks

[attachment deleted by admin]

When something gets logged as being received by Windows Operating System then there is no receiving program for the request. WOS is sorta the garbage collector.

The alert means “Destination network unreachable”. The reason why you get the alerts is that you probably shut down a program and there were message coming from the server. Are you using a peer to peer program? You get quite a bundle of incoming traffic after closing down those programs.

You might be able to speed up downloads by a few KB/s in uTorrent if you allowed ICMP/Destination Unreachable. If you want just the inbound, then it would apply to Windows Operating System. Note there are at least three common types of Destination Unreachables with P2P programs: Host, Net, and Port. I personally enabled all three (inbound and outbound) after I monitored the logs long ago to narrow down what generated such events and researched on google on whether it’s safe or not.

[attachment deleted by admin]

Thanks for the replies

@EricJH

When something gets logged as being received by Windows Operating System then there is no receiving program for the request. WOS is sorta the garbage collector.

This is part of the confusion. The inbound ICMP packets are in response to requests made by uTorrent, which is running, so in fact, there is a “receiving program” available.

As far as I can tell, WOS is simply a Comodo identifier for System Idle Processes.

The reason why you get the alerts is that you probably shut down a program

These packets are received whilst the program is running, not after is closed down.

Are you using a peer to peer program?

As mentioned in my OP, uTorrent.

@Soyabeaner | Mr. Bean

If you want just the inbound, then it would apply to Windows Operating System.

Not sure I understand this?

I only receive log entries for inbound requests and its always WOS thats the target, even though uTorrent is running and I have no rules for WOS.

Note there are at least three common types of Destination Unreachables

I only allow ICMP Type 3 Code 1 and 2 IN through Global Rules as Ive never has a log entry for Type 0

So the advice is to create an Application Rule for WOS and allow ICMP Type 3 Code 1 and 2 against this object, even though it’s a semi fictitious object?

Thanks

Can you show me a screenshot of the uTorrent rule you made?

Sure, no problem :slight_smile:

Attached:

[attachment deleted by admin]

Please add in the uTorrent rule an allow rule for ICMP traffic for both Code (3) Type (1) and Code (3) Type (3). That should do the trick I think.

Let us know if it worked for you.

In that case just allow the ones you have in the log.

It’s not fictitious at all; just the way CIS was designed. Kind of hard to explain, but I guess Egemen thought it was better to be consistent and have WOS classified as an “application” with ICMP vs the other protocols like TCP/UDP. I think I’ve only seen a few ICMP log entries associated with utorrent.exe itself (which would make more sense and allows tracking to which program produced that blocked traffice) vs WOS, but I don’t know why.

Thank you for the replies :slight_smile:

@EricJH

Please add in the uTorrent rule an allow rule for ICMP traffic for both Code (3) Type (1) and Code (3) Type (3). That should do the trick I think.

Let us know if it worked for you.

Unfortunately adding rules for ICMP to uTorrent made no difference, log entries are still generated against WOS when uTorrent is active.

I believe these packets will need an OS process as a receiver, just a question of which.

@Soyabeaner | Mr. Bean

It's not fictitious at all; just the way CIS was designed.

Actually, it is. originally WOS was called SIP (System Idle Process) and that is not a real process:

Finally, the process named Idle that you see spending nearly 100 percent of its time in kernel mode isn’t really a process—it’s a fake process used to account for idle CPU cycles. As you can observe from the mode in which the threads in the Idle process run, when Windows has nothing to do, it does it in kernel mode.

Source: Windows Internals 5th Addition.

I know it used to be called that and what the meaning is (it’s application-less but does exist to represent something), but like I posted I’m bad at explaining ;D.

If those same log entries are still there that means you need to fine tune your rules. As per wiki:
ICMP Code 3 | Type 1 = Destination host unreachable
ICMP Code 3 | Type 3 = Destination port unreachable

Go back to your rules screen and see if those are correctly listed. Also, are you sure they are only inbound?

I know it used to be called that and what the meaning is (it's application-less but does exist to represent something), but like I posted I'm bad at explaining Grin.

we’ll agree to differ on that :slight_smile:

ICMP Code 3 | Type 1 = Destination host unreachable ICMP Code 3 | Type 3 = Destination port unreachable

Go back to your rules screen and see if those are correctly listed. Also, are you sure they are only inbound?

The only way I am able to prevent log entries is by creating an Application Rule for WOS and adding the rules for inbound ICMP, as described, to that object. The rules do not work if applied to uTorrent, svchost or the System object.

In some ways this makes sense; the alternative would be to create individual ICMP rules for any application that required them. My only issue is that WOS is a generic ‘catch all’, fake process, which doesn’t exist in other firewalls. Personally, I’d prefer something a little more concrete.

Still, this will have to do. Thank for you input.