[Snort-users] Stream4

Matt Jonkman matt at ...4024...
Mon Jan 28 20:39:08 EST 2002

I appreciate getting the info straight from the horse's mouth. Or keyboard
as it were....

The portscan preprocessor does a great job as far as I can see with the
regular portscan, and even a medium slow scan. It of course won't grab the
slowest and multiple source scans, but what it is intended for it does well.

The big issue there is the output to the database. We're building a pretty
large scale installation on an oracle db and really want to keep the number
of unique signatures to a manageable number. Each portscan entry from the
portscan preprocessor creates a new unique event.

I think our best bet for time's sake will be to see what we can do with
altering the output of that preprocessor to conform to the norm. If any of
the original developers of the portscan preprocessor are listening in any
advice would be greatly appreciated. On the same note, has anyone already
met and solved this issue?



----- Original Message -----
From: "Martin Roesch" <roesch at ...1935...>
To: "Matt Jonkman" <matt at ...4024...>; <snort-users at lists.sourceforge.net>
Sent: Monday, January 28, 2002 8:50 PM
Subject: Re: [Snort-users] Stream4

> On 1/28/02 5:43 PM, "Matt Jonkman" <matt at ...4024...> wrote:
> > Where can I find more detailed documentation on stream4?
> >
> > Specifically, I'm wondering if the setect_scans functionality replaces
> > abilities of the portscan preprocessor.
> Not yet.  Right now it detects stealth scans and nmap fingerprint
> but we don't have the code in to statefully pick up SYN scans.
> IMHO, I think we should move to post-process detection of SYN/UDP scans by
> utilizing the keep_stats function that stream4 supports, there's no
> need for real-time detection of SYN scans in the general case (but that's
> just me talking...)
> > We'd prefer to use the stream4 plugin as it formats database entries
> > correctly with source and dest IP making things much easier to research.
> >
> > I can make stream4 alert on a very overt xmas scan, but nothing for a
syn or
> > tcp scan. Are there parameters to set to make it more sensitive?
> Nope.  We've toyed with the idea of doing things like looking for short
> sessions (SYN-SYNACK-RST, full connect with RST) and detecting just them,
> we've also toyed with the idea of doing straight rate detection for SYN
> packets.  Both methods have their ups and downs from a performance and
> memory management perspective, which is why I've held off on implementing
> them.
> If you want to take a stab at implementing it, I'll take a look at what
> come up with.
>      -Marty
> --
> Martin Roesch - Founder/CEO Sourcefire Inc. - (410) 552-6999
> Sourcefire: Professional Snort Sensor and Management Console appliances
> roesch at ...1935... - http://www.sourcefire.com
> Snort: Open Source Network IDS - http://www.snort.org
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users

More information about the Snort-users mailing list