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

[Drexx Laggui <drexx () pacific net sg>]

Nov. 5, 1999

Hello Robert Graham,

Thanks for your offer of help on this one. We'll be running the FW-1 in
debug mode (and the output will be something like TCPdump) to capture
these anomalous packets. After I've de-sensitized (or de-classified or
massaged or whatever-word-that-is) IP addresses from this capture file, 
I'll share it with you on a private e-mail. Then we'll summarize on this list.

1] I tried to use RealSecure in this customer environment, but there is no
     way I know on how to view raw IP packets in the network. The Replay
     feature was quite inadequate for us, unless we were viewing text-based
     transmissions.
     We wanted tcpdump, or snoop like functionality.

(And since I'm veering towards the topic of IDS and firewall integration...)
2] You can't rebuild transmitted files (via NBT, FTP, e-mail, ICQ, etc.)
      for your forensic analysis with RealSecure, nor any IDS I know. Maybe
      not yet, at least.
3] Without a way to do a "live update" for the attack signature database,
      nor do some sort of heuristic scanning for network traffic behaviour,
      you'll either generate lots of false positives (it's like crying wolf so often)
      and/or you miss out the most sophisticated and lethal attacks.
And probably the most important in our Asia-Pacific region,
4] When you start monitoring traffic at high speeds 155 Mbps or more, it
      either starts missing out many attack details, or the database logs gets
      some records corrupted. No single CPU is good enough yet, and multiple
      CPUs are useless.
      (Yep, due to shortage of skills, budget, time and manpower, we put
      RealSecure on a GigaEthernet network with goal of helping find where a
      network problem or cracker is.)
      Workaround: Place enough RealSecure engines on network segment,
      but it's still no guarantee ALL traffic will be monitored.

thanks again,
Drexx Laggui.

At 08:37 PM 11/4/99 -0800, Robert Graham wrote:
> --- 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