[Snort-users] MISC Large ICMP Packet alert on small ICMP packet

John Sage jsage at ...2022...
Sat Mar 23 12:54:02 EST 2002


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




More information about the Snort-users mailing list