Re: packet too large and/or Ping Of Death ???

[Robert Graham <robert_david_graham () yahoo com>]

--- Drexx Laggui <drexx () pacific net sg> wrote:
> I need your collective experience/brain power to shed some light on what's
> filling up my FireWall-1 logs and alarming also RealSecure...
>
> I have a FireWall-1 controlling access to internal VLANs across Cabletron
> switches. The RealSecure v3.0.2 constantly alerts with a Ping Of Death
> attack,
> while the FireWall-1 reports that the packets are too large, with an IP
> Protocol
> number of zero.
>
> It maybe coincidental fact, but the internal networks are of IP address
> a.b.y.z,
> yet the source/destination of the attacks reported are of y.z.a.b .
> The weird thing is that I think that the Cabletron maybe mangling the packets
> or something, therefore creating a lot of false positives on the RealSecure.
>
> Any idea what is really happening? Thanks in advance,

Below is the IP header info. 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If we combine your y.z.a.b address and the fact that the "Protocol" field is
zero, then the most likely diagnosis is that the entire header is being shifted
two bytes to the right.

In other words, you have something like the following going on for the
addresses:

  a.b.Y.Z -> a.b.y.z
  x.x.a.b -> Y.Z.a.b

Likewise, the "Fragment offset" field is almost always zero, which would make
sense when it overwrites the protocol field with zero. Likewise, the
"Identification" field is going to overwrite the Flags/fragment offset field
with a random number. Combined with the fact that the total length field is
being overwritten, you'll very likely end up with a "fragment" whose fragment
offset points to beyond the end of a legal frame.

One interesting aspect is why the firewall/IDS is not dropping the packet due
to an illegal checksum. One explanation is that only 1/65536 packets are
triggering the alert. The other is that they don't checksum the IP headers
because it slows down performance.

Do you have a Sniffer handy to take a packet capture? I'm the developer of an
intrusion detection system and I would LOVE to get my hands on the tracefile in
order to run through our IDS. I know that lots of IDSs generate sniffer-style
tracefile from the packets that trigger alerts (I'm not sure about RealSecure).
In any case, the actual packet would clearly indicate what is going on (at
least, 90% chance I could figure it out).

Rob.




=====
Robert Graham
"Anxiously awaiting the millenium so I can start programming
dates with 2-digits again."
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com