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

John Sage jsage at ...2022...
Sat Mar 23 17:01:02 EST 2002


Dang!

Well, I'll go _back_ to sleep, again!.

Maybe someone who's paying attention will take a look at your first post..

..gotta admit, icmp 31:5 was pretty creative :-/ -- I mean, it _does_ exist!


zzzzzz...

- John


On Sat, Mar 23, 2002 at 04:13:56PM -0800, Bill McCarty wrote:
> 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 at ...2022...> 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









More information about the Snort-users mailing list