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

[Brant Wells]

Hi All,


> 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.
>
>
 I consider myself new to Suricata and am somewhat unfamilar with its
internals.  I say I have to agree with Eric here, though.

The job of the IPS/IDS engine for any similar product should be to identify
the traffic coming across the wire in whatever method it (or the devs) see
fit.  To do any further analysis, the offending packet or packet streams
should be stored in a fashion that can be forwarded on to some other
analysis package.  Once the IPS engine has decided to block or allow
packets, the IPS has done its job.

I like the question that Robert asks about the way Suricata's threads are
managed...  Is it 1 thread per packet or 5 threads all analyzing one packet
at the same time?

I don't really understand the intricacies involved in either method of
development, but I can see both advantages and disadvantages going in both
directions.  Would anybody that understands more than I do care to give a
simple example of each?  (not code -- an explanation, that is).  Feel free
to reply off-list.

See Yas!
~Brant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20100721/6d354b4a/attachment-0002.html>