[Snort-users] "Saving State" in Snort

Phil Wood cpw at ...441...
Tue Apr 1 13:50:12 EST 2003


Read the whole thing, at least the /LAST PART about broken snort_decoder.

On Tue, Apr 01, 2003 at 10:55:41AM -0500, Chris Green wrote:
> Phil Wood <cpw at ...441...> writes:
> 
> >   cat pcapfile.gz | snort -r - ... -b -L - > snort.cap.gz
> >
> > ? Never mind.
> 
> It's one of those things that I keep forgetting about and very rarely
> is the case for WHY enumerated clearly enough that it fits between my

I'll assume my enumeration failed.  Basically, I like keeping "stats" in
the stderr department, keeping stdout free for piping data.  Obviously,
snort uses even other "descriptors" to write data (syslog, short alerts,
long alerts, barnyard type data).  

This is not high on my list, I just mention it from time to time.  That
script I sent is what I run on the snort cvs source before I use it.
I run snort with stderr sent to <basename>.stats, where <basename> is
carfully crafted to sort well with some added uniqueness based on the
sensor:

In the example below:

   <basename> = /ids/pw/log/default/aa20030401.0000

Filter aa is enabled, using PID 7723 ? R 264:45 /ids/pw/bin/snort
Datafile:     16443691391 Apr  1 13:42 /ids/pw/log/default/aa20030401.0000
               ^ looks like things got a little out of hand to day.
                 this thing is running with standard stuff from:
                 Version 2.0.0beta (Build 57)  I'll upgrade later.

Datafile:       353043 Apr  1 13:36 /ids/pw/log/default/aa20030401.0000.alert
S: 13:42:02, 385778099 packets processed at 7831.56 pps in 49331 seconds, with 566386 drops.

I log all the rules generated alerts (in pcap format), but pass the preprocessor
ones on to a report generator at midnight.  Special rules "redalerts" go to
syslog and I get a page.  (needless to say, I don't have many special rules %^)

The stats are picked up from /d2/pw/log/default/aa20030401.0000.stats, which
has all the nifty snort boilerplate along with some periodic (10 second) 
packet stats that get generated from my libpcap that look like "S:10...*"

          processed packets  ring   ignored           snort    poll waits
  starttim          |  drops total  | /proc/net/dev   bytes    | ring  max
                    |      | |      | | pkts bytes    |        | index consec
S:1049230882.531381 125934 0 125934 0 126342 72324578 72301298 0 31245 136 
S:1049230892.531459 128907 0 128905 0 129360 72189350 72161851 0 29080 198
S:1049230902.531555 125520 0 125520 0 126059 68172907 68140311 0 23528 124
...

Makes for some nice 24 hour gnuplots.


LAST PART

Stay tuned, I've got a problem with Version 2.0.0rc1 (Build 65)
and reassembled fragments.  I'll send you the data if you need it.
You may be aware of it.  In short on the wire there was this (seen by tcpdump):

11:04:52.292451 (tos 0x0, ttl 27, id 22455, length: 1500) 128.165.3.143.2049 > 128.165.114.97.3738408876: reply ok 1472 (frag 22455:1480 at ...183...+)
11:04:52.292455 (tos 0x0, ttl 27, id 22455, length: 1500) 128.165.3.143 > 128.165.114.97: udp (frag 22455:1480 at ...6820...+)
11:04:52.292457 (tos 0x0, ttl 27, id 22455, length: 1164) 128.165.3.143 > 128.165.114.97: udp (frag 22455:1144 at ...8745...)


Snort reassembled those three into one packet:

11:04:52.292457 truncated-ip - 14 bytes missing! (tos 0x0, ttl 27, length: 4138) 128.165.3.143.2049 > 128.165.114.97.3738408876: reply ok 4110

and then sends an alert about it.

04/01-11:04:52.292457  [**] [116:97:1] (snort_decoder): Short UDP packet, length field > payload length [**] {UDP} 128.165.3.143:0 -> 128.165.114.97:0

I'd say it has lost it's mind.  And this is not an AFDP (April Fools Day Prank).

Later,


> ears.
> 
> -L - never made sense to me :)
> 
> Let's try this for part of 2.0.1 :)
> -- 
> Chris Green <cmg at ...1935...>
> A watched process never cores.

-- 
Phil Wood, cpw at ...440...





More information about the Snort-users mailing list