Author Topic: Incorrect analysis of ICMP packets (v3.0.8.214)  (Read 12958 times)

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Incorrect analysis of ICMP packets (v3.0.8.214)
« on: September 18, 2007, 07:13:42 AM »
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
ActionProtocolSource IPSource PortDestination IPDestination Port
AllowedICMPx.x.x.x768192.168.1.x768

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:
ActionProtocolSource IPSource PortDestination IPDestination Port
BlockedICMPx.x.x.x768192.168.1.x3328
BlockedICMPx.x.x.x768192.168.1.x256
BlockedICMPx.x.x.x768192.168.1.x0

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.
« Last Edit: September 20, 2007, 09:45:13 AM by djbronko »

Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #1 on: September 18, 2007, 07:58:54 AM »
Wow,
Thanks. I had a hard time trying to figure the meaning of those "ports".

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.

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 ???
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #2 on: September 18, 2007, 02:06:24 PM »
First of all, thanks for your fast answer.

Quote
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.

Quote
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.

Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #3 on: September 18, 2007, 03:42:45 PM »
Thank to you too,

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.
I'm not so used to those protocols thanks for poining that out. The english wikiopedia missed that part :( 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.
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #4 on: September 19, 2007, 03:28:35 AM »
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:
Code: [Select]
    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:
Code: [Select]
    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:
Code: [Select]
                  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:
Code: [Select]
   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.

Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #5 on: September 19, 2007, 03:58:54 AM »
...snip...
BETA we plan for this Thursday( or Next Tuesday if we miss the date).
...snip...
A new beta will be out in short time but maybe it'll not fix this issue.

At least the problem should be pointed out and maybe there's time to fix it for the next beta / final.
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.
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #6 on: September 19, 2007, 04:32:01 AM »
Quote
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.


Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #7 on: September 19, 2007, 05:05:36 AM »
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.


« Last Edit: September 19, 2007, 05:17:16 AM by gibran »
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #8 on: September 19, 2007, 06:13:34 AM »
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

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #9 on: September 19, 2007, 06:30:55 AM »
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

Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #10 on: September 19, 2007, 07:28:12 AM »
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:

  • 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

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 :)
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #11 on: September 19, 2007, 11:07:49 AM »
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.


  • System process - Need only confirmation that you allow all IP traffic out
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.

  • System Idle process - Need only confirmation that you created a rule for it to allow all IP traffic out
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.

  • svchost.exe - maybe it is not needed but it is a core process that handle nearly anything
I allow outgoing DNS, HTTP and NTP requests.

Also tell me if you set an allow ip in/out for your bittorrent client.
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.





Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #12 on: September 20, 2007, 04:03:03 AM »
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 ???
« Last Edit: September 20, 2007, 04:22:58 AM by gibran »
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

Offline djbronko

  • Newbie
  • *
  • Posts: 19
Re: Incorrect analysis of ICMP packets
« Reply #13 on: September 20, 2007, 04:57:54 AM »
Quote
BTW is uTorrent no more  ???

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


Offline gibran

  • Average User
  • Comodo's Hero
  • *****
  • Posts: 5056
  • A bad workman always blames his tools
Re: Incorrect analysis of ICMP packets
« Reply #14 on: September 20, 2007, 09:34:35 AM »
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 :(





[attachment deleted by admin]
« Last Edit: September 20, 2007, 06:41:53 PM by gibran »
"In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move."- Douglas Adams

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek