[Snort-users] Snort dumps core on Solaris 8
cpw at ...440...
Thu Jun 7 14:27:55 EDT 2001
On Thu, Jun 07, 2001 at 12:56:54PM -0500, Neil Dickey wrote:
> Phil Wood <cpw at ...440...> wrote to the IPFilter list:
> >I've also seen problems with defrag, but have not gotten any confirmation.
> >It is my experience that certain fragment sequences in conjunction with
> >some unknown force cause the creation of mutant packets, that is:
> > IP: proto=icmp (20 byte header)
> > DATA from somewhere in snort memory (not another incoming packet)
> >Makes for some real weird ICMP type / code packets if you are looking for
> >that sort of thing.
> I've been seeing alerts like these:
> [**] PING-ICMP Destination Unreachable [**]
> 06/03-00:56:43.763294 22.214.171.124 -> xxx.yyy.zzz
> ICMP TTL:241 TOS:0x0 ID:14290 IpLen:20 DgmLen:56
> Type:3 Code:13 DESTINATION UNREACHABLE: PACKET FILTERED
> ** ORIGINAL DATAGRAM DUMP:
> xxx.yyy.zzz:25 -> 126.96.36.199:38058
> TCP TTL:246 TOS:0x0 ID:24527 IpLen:20 DgmLen:40
> 12U*PRS* Seq: 0xD1F97B19 Ack: 0x0 Win: 0x0 TcpLen: 0 UrgPtr: 0x0
> ** END OF DUMP
> What particularly interests me is the really unusual collection of flags
> reported for the original datagram, viz., 12U*PRS* . Is this the sort of
> thing you are referring to?
nope. It's interesting because at first blush, xxx.yyy.zzz sent the
weird ass packet with 12u*PRS* in it to 188.8.131.52 and an intermediate
(router) says "hey that's crap my filters don't like it, and I'm going
to send it back, encapsulated in an icmp destination unreachable packet.
You deal with it!"
In my case, I set up 2 packet capture systems running.
One was tcpdump collecting every icmp packet coming or going to
our nets here. The other is snort, which is running most of the x.rules
with the exception of icmp.
I installed my icmp rules which essentially pass all known icmp type/codes.
Then, I have a rule that says alert on any icmp. Consequently, I get what
I call illegal icmp packets. When I compare one of these with
the real thing captured by the tcpdump, there is a glaring difference.
IP: xxxxx IP: xxxxx (both the same)
ICMP: 00ab ICMP: df98 (beginning of some data from snort's memory)
DATA: some zeros DATA: the rest of (up to the original ip length)
When I remove 'defrag' preprocessor. The problem seems to go away.
> Best regards,
> Neil Dickey, Ph.D.
> Research Associate/Sysop
> Geology Department
> Northern Illinois University
> DeKalb, Illinois
Phil Wood, cpw at ...440...
More information about the Snort-users