[Oisf-users] Understanding Suricata's "xbit" implementation.

Champ Clark III cclark at quadrantsec.com
Tue Feb 28 16:06:09 UTC 2017

Thank you for the response....

On 02/26/2017 05:38 AM, Victor Julien wrote:
> We currently support: ip_src, ip_dst and ip_pair:
> ip_src and ip_dst are wrappers around our 'hostbits', which stores per
> host (host == ipaddress here). ip_src means we store the bit for the src
> ip of the matching packet. We don't have a 'both' yet.
> ip_pair means we store it in a different place, the ip pair table. This
> is meant to store bits per 2 talkers.

My question is,  when using xbit "set" are you required to supply an 
ip_src or ip_dst?
>> We don't use this syntax, but instead you'd have multiple instances of
>> the keyword in a rule. Your syntax suggestion would make sense to
>> implement though.

That works :)  I actually want my syntax to match Suricata's.

> In our git master I've added a 'vars' log. Currently it only does 'flow'
> vars and 'pkt' vars, not host and ippair yet. But it's basically an EVE
> log for these things. It can be configured to go into redis like all EVE
> outputs.

I can see xbits being pretty interactive within Suricata.   The main 
goals I have are:

1. Provide Suricata with a way to "save" its state between process 
stops/restarts/system reboots.
2. Allow Suricata to globally share xbits with other Suricata ( *cough* 
and Sagan :) processes.

In Sagan,  we do some of this with mmap files.   This allows some IPC 
between Sagan processes and the ability to save it's state between 
reboots/process restarts.   I'm looking at adding the option to do the 
same but via Redis.

Because of the constant interaction between xbits/Redis,  I'm not sure 
if EVE will be enough.

I think it's just going to take some experimentation :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3813 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170228/badc737d/attachment-0002.bin>

More information about the Oisf-users mailing list