[Oisf-users] For those who haven't read this

Wed Jul 21 22:29:00 UTC 2010

Hi,

Le mercredi 21 juillet 2010 à 18:13 -0400, Robert Vineyard a écrit :
> Interesting, I did not realize that was something that Suricata could do.
> 
> Although, it does seem like that would preclude it from running in IPS mode 
> since real-time analysis is essential for that kind of setup. However, for 
> IDS mode, being able to fork off a separate thread/process to handle 
> querying against an IP reputation database would be handy. I'm presently 
> looking at ways to post-process the output of <insert favorite IDS here> for 
> correlation against those types of data sources, but being able to do it 
> natively inside the engine would be a big plus.

You can do it via Prelude correlator for instance. For instance, it has
a dshield correlation rules : if source of the alert is present in
dshield offender base, it will increase the severity of the alert (or
generate a correlated alert).

And I think that doing asynchronous treatment (or simple long duration
treatment) is not the work of the IDS but rather the work of an external
correlator:
      * In IDS mode, packet is gone and we can wait for external
        treatment, no need to overload the IDS
      * In IPS mode, we have to wait for the external treatment and it
        will introduce a undecent delay. Thus external checking is not
        acceptable.

> Just my 2c :-)

My 0.02 € :P

> 
> --
> [ Robert Vineyard | RHCE, Security+ ]    [ robert.vineyard at oit.gatech.edu  ]
> [ Information Security Engineer III ]    [ 404.385.6900 | FAX 404.894.4690 ]
> [Finding a needle in a haystack isn't hard when every straw is computerized]
> 
> On 7/21/2010 5:27 PM, Brian Rectanus wrote:
> > On Wed, Jul 21, 2010 at 1:00 PM, Matt Jonkman<jonkman at jonkmans.com>  wrote:
> >> On 7/21/10 2:58 PM, Robert Vineyard wrote:
> >>> http://vrt-sourcefire.blogspot.com/2010/06/single-threaded-data-processing.html
> >>>
> >>> Here's another link (a writeup by Marty Roesch of Sourcefire) referenced
> >>> from the article you mentioned.
> >>>
> >>> In light of this discussion, does OISF / Suricata have a response to
> >>> Sourcefire's critique of a multi-threaded engine model that uses several
> >>> threads to process the same data simultaneously? It seems to me that the
> >>> most efficient way to do things would be to have a front-end load-balancer
> >>> that could distribute the traffic to multiple back-end threads or processes
> >>> that would each operate on independent data streams. This is the strategy
> >>> employed by Endace and others to accomplish high-throughput IDS inspection.
> >>
> >> I'll leave this for Victor and Will to answer in detail, but that's
> >> about where we're going.
> >>
> >> Now nobody is saying that 4 cores gives you a 4-fold performance
> >> increase. It's something less than that. But it's our only way forward.
> >> The processors aren't going to get faster.
> >
> > Besides performance, one thing you cannot do with snort is send the
> > data off to be analyzed externally without blocking until you get a
> > response.  This is important in L7 if you want to send the data off to
> > a WAF module, or maybe send the data to a virus checker, etc.
> >
> > So multi-threaded is not all about performance, but also about being
> > able to do things that snort just cannot do.
> >
> > And comparing<  1yr old code to code as old as snort is a bit unreasonable.
> >
> >>
> >>> On a related note, are there any plans to implement native acceleration
> >>> support for other vendors besides Endace (in particular Napatech / nPulse)?
> >>>
> >>
> >> Yes! As Randy mentioned they're building it now. We'll have news about
> >> this very shortly as far as membership and support!
> >>
> >> Matt
> >>
> >>> Thanks!
> >>>
> >>> --
> >>> [ Robert Vineyard | RHCE, Security+ ]    [ robert.vineyard at oit.gatech.edu  ]
> >>> [ Information Security Engineer III ]    [ 404.385.6900 | FAX 404.894.9548 ]
> >>> [Finding a needle in a haystack isn't hard when every straw is computerized]
> >>>
> >>>
> >>> On 07/21/2010 07:05 AM, Kevin Ross wrote:
> >>>> http://vrt-sourcefire.blogspot.com/2010/07/innovation-you-keep-using-that-word.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Vrt+(Sourcefire+VRT+-+Vulnerability+Research%2C+Snort+Rules+and+Explosions)
> >>>> <http://vrt-sourcefire.blogspot.com/2010/07/innovation-you-keep-using-that-word.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Vrt+(Sourcefire+VRT+-+Vulnerability+Research%2C+Snort+Rules+and+Explosions)>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Oisf-users mailing list
> >>>> Oisf-users at openinfosecfoundation.org
> >>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>> _______________________________________________
> >>> Oisf-users mailing list
> >>> Oisf-users at openinfosecfoundation.org
> >>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>
> >> --
> >>
> >> ----------------------------------------------------
> >> Matthew Jonkman
> >> Emerging Threats
> >> Open Information Security Foundation (OISF)
> >> Phone 765-429-0398
> >> Fax 312-264-0205
> >> http://www.emergingthreats.net
> >> http://www.openinfosecfoundation.org
> >> ----------------------------------------------------
> >>
> >> PGP: http://www.jonkmans.com/mattjonkman.asc
> >> _______________________________________________
> >> Oisf-users mailing list
> >> Oisf-users at openinfosecfoundation.org
> >> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >>
> _______________________________________________
> Oisf-users mailing list
> Oisf-users at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users

-- 
Eric LEBLOND, CTO
-----------------------------------
Tél. +33 (0)1 40 24 65 00 - Mob. +33 (0)6 70 30 90 32
eleblond at edenwall.com     - http://www.edenwall.com