[unisog] Snort woes

Russell Fulton r.fulton at auckland.ac.nz
Mon Jan 24 20:36:29 GMT 2005


Thanks to Morrow (for recognising that I was fast a sleep :), Valdis,
Chris and Michael.  I'll post one reply and try and cover all the points
raised.

On Mon, 2005-01-24 at 11:32 -0600, Chris Green wrote:

> Russell, 
> 
> The steps for debugging this would be to run tcpdump on the connection at
> the same time as snort (or a binary logging snort without the stream
> reassembler).  

yes, I've don this in the past - in fact there is a major revision of
all the SSL reules for PCT and HELLO attacks due out shortly because I
took the time to capture a bunch of full sessions for the Sourcefire
folks to use to debug the FPs.

The reason I have not attempted this here yet is that these problems
tend to occur more or less at random on port 80 flows.  With my present
monitoring resources I am reluctant to collect all port 80 traffic
entering and leaving our network!  However all is not lost, my colleague
and room mate Nevil Brownlee who is a network traffic measurement
specialist has just purchased an new very grunty box specifically for
doing large scale traffic data capture.  The security team have offered
to help him set it up  and we will, of course, need to test it ;)

> My guess is that you are running into a stale packet data.

Yup,  that's what I suspect. 
> 
> Try adding zero_flushed_packets to your stream4 reassembly line.  If the
> problem goes away/is minimized, the problem is with stream4 somewhere.

Thanks, I'll try that!  At least we might get a handle on where the
problem really is
> 
> Right before you get this bad alert, you should find a real instance of this
> alert.

there does not appear to be any.  I'm getting suspicious about the box
again.  I have just had another look at the tagged packets I am getting
off the other sensor and all the ones I have looked at are linked with
valid alerts.  I still don't understand why I'm getting tagged packets
but at least the alerts are valid. 

I think next step is to move the sensor to a new box and see if the
problem goes away.  I don't really see how this can be related to the
box but then I long ago gave up the idea that computers are
deterministic beasts :)

On Mon, 2005-01-24 at 13:23 -0500, Michael Holstein wrote: 
> 
> If you're using the "database" output plugin, all those 'tagged' packets 
> all show up under the same Sig_ID and there isn't an effective way (that 
> I'm aware of) to get a DB frontend to reassemble them for you. This is, 
> in my opinion, more than a 'little' annoying.
> 
Amen to that.  I am currently using Placid as a front end and have been
doing some work on the code.  One of the things I have been thinking
about is modifying the database schema (a new table linking the tagged
packets with the original alert would seem sensible) and adding the
necessary code to placid to allow you see them as a group.

I would also have to hack barnyard to load the stuff into the new table.

Cheers, Russell




More information about the unisog mailing list