Re: MISC Large ICMP Packet alert on small ICMP packet

[Bill McCarty <bmccarty () apu edu>]

Hi John,

Oops! My IP address obfuscation has led to confusion.

The xxx.xxx.xxx.5 is an IP address ending in 5 and the xxx.xxx.xxx.31 is an 
IP address ending in 31. The 5 and 31 are neither port numbers nor ICMP 
types or codes. As it happens, the ICMP type is simply Echo Request, as 
indicated by the tcpshow output.

Sorry for the lack of clarity.

Cheers,

--On Saturday, March 23, 2002 12:51 PM -0800 John Sage 
<jsage () finchhaven com> wrote:

> Bill:
>
> Here's a wild thought:
>
> On Fri, Mar 22, 2002 at 08:57:08PM -0800, Bill McCarty wrote:
> > I'm seeing MISC Large ICMP Packet alerts and don't see why. I used nmap
> > to  scan one of my hosts, using options -f -sS -p 53. The resulting
> > alert,  related to nmap's ping rather than the SYN scan, was:
> >
> > > 03/22-20:21:30.429717  [**] [1:499:1] MISC Large ICMP Packet [**]
> > > [Class ification: Potentially Bad Traffic] [Priority: 2] {ICMP}
> > > xxx.xxx.xxx.31 -> xxx.xxx.xxx.5
>
> Typically icmp representation is not talking about ports, even though
> the presentation by snort "xxx.xxx.xxx.31" and "xxx.xxx.xxx.5" tends
> to confuse newcomers.
>
> Rather, icmp refers to type:code combinations.
>
> There _is_ an icmp type 31, code 5; see:
>
> ftp://ftp.isi.edu/in-notes/rfc1475.txt
>
> Specifically:
>
> <snip>
>
> "6.2  Conversion failed ICMP message
>    The introduction of network layer conversion requires a new message
>    type, to report conversion errors.  Note that an invalid datagram
>    should result in the sending of some other ICMP message (e.g.,
>    parameter problem) or the silent discarding of the datagram.  This
>    message is only sent when a valid datagram cannot be converted.
>
>    The type for Conversion Failed is 31.
>
>    The codes are:
>         0       Unknown/unspecified error
>         1       Don't Convert option present
>         2       Unknown mandatory option present
>         3       Known unsupported option present
>         4       Unsupported transport protocol
>         5       Overall length exceeded
>
> <snip>
>
> So, (Hey! I said this was a wild thought.. :-/ ) perhaps this is an
> icmp representation of a packet that failed conversion, due to
> "overall length exceeded"
>
> Something like an icmp "destination unreachable" which would contain
> the beginnings of the offending packet; but in this case, this is
> reporting an overlength packet that triggered the snort rule, but
> _this_ icmp packet itself is of normal, shorter length...
>
>
> I dunno..
>
> ..I said it was a wild thought.
>
> I'll just go back to sleep, now.
>
>
> - John
> --
> The weirdest thing about Window$ is that it's so opaque
>
>
>
> > The relevant Snort rule is:
> >
> > > alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"MISC Large ICMP
> > > Packet"; dsize: >800; reference:arachnids,246; classtype:bad-unknown;
> > > sid:499; rev:1;)
> >
> > This rule seems to look for a datagram size exceeding 800 bytes. But, a
> > tcpshow dump of the relevant packet shows a datagram size of only 28
> > bytes.
> >
> > > Packet 371
> > >         Timestamp:                      20:21:30.429717
> > > IP Header
> > >         Version:                        4
> > >         Header Length:                  20 bytes
> > >         Service Type:                   0x00
> > >         Datagram Length:                28 bytes
> > >         Identification:                 0x1775
> > >         Flags:                          MF=off, DF=off
> > >         Fragment Offset:                0
> > >         TTL:                            45
> > >         Encapsulated Protocol:          ICMP
> > >         Header Checksum:                0x2571
> > >         Source IP Address:              xxx.xxx.xxx.31
> > >         Destination IP Address:         xxx.xxx.xxx.5
> > > ICMP Header
> > >         Type:                           echo-request
> > >         Checksum:                       0x1F16
> > > ICMP Data
> > >         ....
> >
> > I'm clearly missing something. Can someone point me in the right
> > direction?
> >
> > Thanks, as always!
> >
> > ---------------------------------------------------
> > Bill McCarty



---------------------------------------------------
Bill McCarty, Ph.D.
Associate Professor of Web & Information Technology
School of Business and Management
Azusa Pacific University

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users