[Discussion] rfc: different processing stages for rules

[Victor Julien]

I've been thinking some about a problem in the ideas as we currently see
them. Many of the ideas require quite expensive checks, such as Martin
Holste's timemachine ideas or Kevin Ross' ideas about querying external
data sources like nepenthes and firewall logs. Add to that the ideas of
having more higher level scripting languages for alert (post)processing,
and we're going to run into serious latency and performance issues,
especially when we're running inline.

One possible solution would be to have two processing stages. Stage 1 is
(relatively) simple: it detects content, stuff that can be detected in
the current packet, or in multiple packets with the help of flowbits and
the like. Basically, pretty much what Snort/Snort_inline does now. If in
this stage an event is detected, we can still drop on it (most of the
time, fragmented packets and spliced sessions can still be a challenge).

In the second stage, all the expensive checks would come in to play.
Detection here would be after-the-fact by definition, so dropping isn't
possible no more. In a IPS setup we could fall back to dropping the rest
of the packets for that flow/stream, active responses, snortsam style
blocking. This detection could be offloaded to another thread or process
to interrupt the normal packet flow as little as possible.

I look forward to ideas & comments on this.

Regards,
Victor

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------