Incorrect analysis of ICMP packets (v3.0.8.214)

Hi,

I’m running Comodo 3.0.8.214 in Win XP x64 with SP2. I observed an unusual behavior with respect to ICMP packets, and I’m not sure if this is a bug.

I’m using BitTorrent which causes a lot of outgoing UDP packets. Some of them are replied by an incoming ICMP packet of type 3, code 3 (Port unreachable). I have a rule which allows and logs these and blocks all other packets. They are logged as

[tr]
[td]Action[/td][td]Protocol[/td][td]Source IP[/td][td]Source Port[/td][td]Destination IP[/td][td]Destination Port[/td]
[/tr]
[tr]
[td]Allowed[/td][td]ICMP[/td][td]x.x.x.x[/td][td]768[/td][td]192.168.1.x[/td][td]768[/td]
[/tr]

Since ICMP has no ports, I assume that the shown values of source and destination port are equal to bits no. 0-15 and 16-31 of the incoming packet. These bits contain the port numbers for TCP and UDP. In ICMP, they contain type (0-7), code (8-15) and a checksum (16-31). I read somwhere that you have to divide the value by 256 if you run on an Intel platform. This would result in a type value of 3 which is perfectly right for unreachable-messages.

Besides the log entries shown above, there are some other entries like the following:

[tr]
[td]Action[/td][td]Protocol[/td][td]Source IP[/td][td]Source Port[/td][td]Destination IP[/td][td]Destination Port[/td]
[/tr]
[tr]
[td]Blocked[/td][td]ICMP[/td][td]x.x.x.x[/td][td]768[/td][td]192.168.1.x[/td][td]3328[/td]
[/tr]
[tr]
[td]Blocked[/td][td]ICMP[/td][td]x.x.x.x[/td][td]768[/td][td]192.168.1.x[/td][td]256[/td]
[/tr]
[tr]
[td]Blocked[/td][td]ICMP[/td][td]x.x.x.x[/td][td]768[/td][td]192.168.1.x[/td][td]0[/td]
[/tr]

These are all PortUnreachable packets, too, but they are blocked. My assumption is that CFP analyzes bits 16-31 instead of bits 0-15, which would be incorrect.

Wow,
Thanks. I had a hard time trying to figure the meaning of those “ports”.

Your hint was very precious. I have elaborated another explaination.

Every port is a 16 bit value. Every Icmp too.
So the source and destination ports are the inbound ICMP and the reply ICMP (or the other way round).

That division by 256 is a way to get the first 8 bit of a number to have the type.
The code should be port Modulo (remainder operation) 256

So 760 actually mean ICMP Net unreachable (type 3 code 0)
3328 actually mean ICMP Timestamp (type 13 code 0)
256 actually mean ICMP Unassigned (type 1 code 0) //this is a strange value ???

First of all, thanks for your fast answer.

Every port is a 16 bit value. Every Icmp too. So the source and destination ports are the inbound ICMP and the reply ICMP (or the other way round).

I don’t think that the source port value contains one ICMP value and the destination port value contains another one because there’s a golden rule which says that an ICMP packet must never be the cause for a second ICMP packet (except the echo message; taken from ICMP in German Wikipedia). I’m not really sure about this, but it makes sense.

That division by 256 is a way to get the first 8 bit of a number to have the type. The code should be port Modulo (remainder operation) 256

I agree on this thought. Indeed a better explanation than the Intel platform. Maybe it would be a good idea to change this in the CFP log.

I really appreciate your efforts, thanks for your thoughts.

Thank to you too,

I’m not so used to those protocols thanks for poining that out. The english wikiopedia missed that part :frowning: Anyway It should be that way, as you mentioned some ICMP are reply to Inbound UDP packets.

I didn’t test ICMP rules anymore as I was unable to figure out how to read those ports so I have no ICMP logged at the moment. Logging for ICMP is not meant to be this way, I bet Devs are fixing other issues ATM so this is a low priority glitch.

Still is difficult to tell if the second port value is the checksum because we don’t have all the ICMP fields needed for that.
Anyway I may be wrong because all the value you listed have a 0 remainder.

I’m not sure about the destination port value. I said that it could be the checksum, and that’s because the position of the checksum in ICMP is the same as the destination port in UDP and TCP:
ICMP Header Format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             unused                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Internet Header + 64 bits of Original Data Datagram      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TCP Header Format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ...

UDP Header Format:


                  0      7 8     15 16    23 24    31
                 +--------+--------+--------+--------+
                 |     Source      |   Destination   |
                 |      Port       |      Port       |
                 +--------+--------+--------+--------+
                 |                 |                 |
                 |     Length      |    Checksum     |
                 +--------+--------+--------+--------+
                 |
                 |          data octets ...
                 +---------------- ...

On the other hand, the values in my log are always dividable by 256 which would be very unusual for a checksum. I’ve just looked up the the checksum details in the ICMP Specification:


   Checksum

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the ICMP message starting with the ICMP Type.
      For computing the checksum , the checksum field should be zero.
      This checksum may be replaced in the future.

If I get it right, the checksum is calculated from the complete ICMP message, i.e. type, code (, checksum is filled with zeros for calculation), ‘unused’ field, IP header and 64 bits of data of the original datagram. So it should be quite improbable that the checksum value is same for different originating packets. I don’t know how my BitTorrent UDP packets look like (they could all hold the same message), but at least the receiver’s IP is different and thus the checksum should differ. Maybe your developers can help out when they have a look into the source code.

At least the problem should be pointed out and maybe there’s time to fix it for the next beta / final.

A new beta will be out in short time but maybe it’ll not fix this issue.

Devs already know about this. I know that is difficult to fine-tune rules without complete logging info but it makes sense that dev are not fixing minor interface glitches at the moment. when the core set of functionalities works properly I bet they’ll implement all those at once.

Anyway If we manage to sort out this port issue (at least for the first one) we can make this info available from known workarounds topic with a summarized description and a link to this topic.

Devs already know about this. I know that is difficult to fine-tune rules without complete logging info but it makes sense that dev are not fixing minor interface glitches at the moment. when the core set of functionalities works properly I bet they'll implement all those at once.

Please let me just point out once again that I don’t really care about wrong logging info - CFP blocks packets although they are allowed. That’s my point. I agree that this can be considered a minor bug, however.

Silly me I didn’t understand that. Blocking traffic explicitely allowed in rules it is a bug indeed and a MAJOR one. Anyway examining this topic again I found out a definitive answer, please verify this on you side too.

All values have a reminder of zero (they are divisible by 256).

So I checked the data you provided again.

Allowed ICMP x.x.x.x 768 192.168.1.x 768 ICMP Type 3 code 3
Blocked ICMP x.x.x.x 768 192.168.1.x 3328 ICMP Type 3 code 13
Blocked ICMP x.x.x.x 768 192.168.1.x 256 ICMP Type 3 code 1
Blocked ICMP x.x.x.x 768 192.168.1.x 0 ICMP Type 3 code 0

So that’s it, I don’t know why all ports have to be divided by 256.

Your interpretation of the port values makes absolutely sense to me. I’ve looked up the ICMP codes at IANA and they seem all reasonable and certainly possible in a BitTorrent environment.

I’ve looked up my rules once again, and I’ve seen that I allow the predefined values Net / Host / Protocol / Port Unreachable (should be (3,0) (3,1) (3,2) (3,3)) but not (3,13). So CFP’s behavior of blocking 768/3328, i.e. ICMP (3,13), is correct and no bug. I’ve just added a rule for that and will examine the logs later to see if (3,13) comes through now.

So what’s the essence?

  • CFP handles packets of (type,code) (3,3) correctly,
    so the strange values (* 256) seem to be a log visualization problem only

  • Packets logged as 768 / 0 = ICMP (3,0) = NetUnreachable:
    Blocked although they should be allowed, probably a bug

  • Packets logged as 768 / 256 = ICMP (3,1) = HostUnreachable:
    Blocked although they should be allowed, probably a bug

  • Packets logged as 768 / 512 = ICMP (3,2) = ProtocolUnreachable:
    Never seen such a packet on my machine

  • Packets logged as 768 / 768 = ICMP (3,3) = PortUnreachable:
    Allowed based on existing rule - correct behavior

  • Packets logged as 768 / 3328 = ICMP (3,13) = CommunicationAdministrativelyProhibited:
    Blocked because no explicit rule existed - correct behavior

Addition: I just observed that packets of type/code (3,13) are still blocked although I now (after a reboot) have a rule which allows them.

So what’s the essence?

  • CFP handles packets of (type,code) (3,3) correctly,
    so the strange values (* 256) seem to be a log visualization problem only

  • Packets logged as 768 / 0 = ICMP (3,0) = NetUnreachable:
    Blocked although they should be allowed, probably a bug

  • Packets logged as 768 / 256 = ICMP (3,1) = HostUnreachable:
    Blocked although they should be allowed, probably a bug

  • Packets logged as 768 / 512 = ICMP (3,2) = ProtocolUnreachable:
    Never seen such a packet on my machine

  • Packets logged as 768 / 768 = ICMP (3,3) = PortUnreachable:
    Allowed based on existing rule - correct behavior

  • Packets logged as 768 / 3328 = ICMP (3,13) = CommunicationAdministrativelyProhibited:
    Blocked although they should be allowed, probably a bug

This should be definitively a bug, anyway I’ll test this too in order to confirm this behaviour. Now there is enough info to tweak my ruleset.

In order to test your configuration as well I need your Application rules for:

[ol]- System process - Need only confirmation that you allow all IP traffic out

  • System Idle process - Need only confirmation that you created a rule for it to allow all IP traffic out
  • svchost.exe - maybe it is not needed but it is a core process that handle nearly anything[/ol]

Also tell me if you set an allow ip in/out for your bittorrent client.

If we are on the right track this will provide enough info to devs.
Thanks :slight_smile:

The system processes usually don’t handle the network traffic. This is done by the application processes themselves. Thus, I don’t allow my system processes more than necessary.

I do not allow all IP traffic out.
I only allow Netbios traffic in/out within my LAN (i.e. UDP ports 137, 138, TCP ports 139, 445) because ‘System’ manages the Windows network.

I do not allow all IP traffic out.
I allow outgoing

  • DNS: because applications delegate name queries to the System Idle Process
  • ICMP: because the System Idle Process handles all ICMP
  • TCP: to deny external connection requests on ports that once were in use by an application but are closed now. No ‘normal’ TCP connection is started by the System Idle process.

I allow outgoing DNS, HTTP and NTP requests.

BitTorrent client:
Allow DNS, TCP and UDP Out
Allow TCP and UDP In on port 12345

Let me append that CFP security level is set to ‘Custom’, i.e. if a system process would try to send outgoing packets, I’d be notified about this. But this was not the case for weeks. I’m using my system as usual, and I have all connectivity.

Thanks I did some preliminary testing (wow to gather such data I needed a day :o) I used a more permissive ruleset and logged using global rules.
I had the same behaviour you reported.

I need to reboot and test again. Then I’ll remove Sytem idle rules completely to see if there are any changes.

BTW is uTorrent no more ???

BTW is uTorrent no more ???

I never used it, but on their website I found a release 1.7.5 from 2007-09-11.

I tested again. I can confirm the behaviour you described and the Time exceeded ICMP not allowed described in the previous beta.
Plus I cannot log Echo request or reply ICMPs.

This behaviour is not changed by allow and log all icmp in System idle process nor by deleting System idle process rules.

My global rules are

BTW I downloaded utorrent but utorrent forum mentioned that it was acquired by bittottent :frowning:

[attachment deleted by admin]

Yep. It was a bug in displaying the logs. the latest beta should not behave like this. It is just about showing the logs. The firewall filtr is not related to this issue.

Egemen