[Snort-devel] THREAD_LOCAL

Russ Combs (rucombs) rucombs at ...3461...
Mon Jan 26 10:19:56 EST 2015


________________________________________
From: Sancho Panza [sancho at ...3553...]
Sent: Sunday, January 25, 2015 10:21 AM
To: Russ Combs (rucombs)
Cc: snort-devel at lists.sourceforge.net
Subject: RE: [Snort-devel] THREAD_LOCAL

On Fr, 2015-01-23 at 16:04 +0000, Russ Combs (rucombs) wrote:

> * No, IpsOptions are instantiated as rules are parsed and should only
> hold configuration.  What kind of state information are you trying to
> update?  Is it per thread or per session?  If you really want global,
> you will need to synchronize access (which impacts performance).

I am writing an IPs option that will adds some kind of "probability
score" to a generated alert. The idea is as follows:

By default, an event triggered by a rule that lacks my option gets a
score of 5 (neutral).

My option will then allow you to specify things like:

Packet Node: Either of "Source" or "Destination"
Correlation Attribute: "Operating System", "Architecture", etc...
Attribute Value (depending on the attribute): "linux", "windows", "x86",
"SPARC", etc...
Success: 0-10 (value to add to default score on match)
Failure: 0-10 (value to subtract from score on failue to match)

When the option evaluates, it will look the source or destination node
up in some sort of dictionary to find out whether the packet matches and
increment or decrement the default score accordingly.

I already saw that the LUA kind of option makes use of an array to keep
the LUA state of each thread in a separate value. But even that does not
help me. The problem is that it should be possible to use this option
more than once in a rule, and when the second option for a rule and
packet evaluates, it should of course modify the result of the first
evaluation (NOT the default value!)

I already saw that it's also NOT an option to store that value in the
packet itself, because for each rule that's checked against the packet,
this value must be reset to the default value.

I think whats necessary is some kind of argument that can be passed to
the eval function like so (pseudo code):

for each packet p:
     score = DEFAULT
     for each rule r:
         for each option o in r:
             o.evaluate(p, &score);

When an event is generated for a given combination of (packet and rule),
the corresponding score shall be written into the event structure...

Can you confirm this is only possible by changing the signature of the
eval function?

* Changing the eval() signature doesn't help define a solution any better, it just pushes the problem out of your area and on to the framework.  It sounds like you want each instance of your rule option to leverage thread local data, and that means you will need to manage an array of thread local data within the rule option itself.  At runtime you must index the array using the current thread id.  This is the approach taken elsewhere.  A template based IpsOption subclass could perhaps be a generic parent of your rule option to help manage the tread local data, but this is not required by any existing rule options so I'd start with the simplest implementation to get your concept working.

Thanks

Sancho

>
> Many thanks
>
> Sancho
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in
> Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely
> compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!



More information about the Snort-devel mailing list