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

Offline egemen

  • Comodo Staff
  • Comodo's Hero
  • *****
  • Posts: 3380
Re: Incorrect analysis of ICMP packets (v3.0.8.214)
« Reply #15 on: September 28, 2007, 02:58:20 PM »
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.

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

 

Free Endpoint Protection
Seo4Smf 2.0 © SmfMod.Com Smf Destek