[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