[Bro] Bitwise Operations

M K mkhan04 at gmail.com
Tue May 27 04:53:12 PDT 2014

ChopShop is too slow to handle detection of c2 traffic in real-time on a
large pipe. Frankly, it was never meant for it, even though a lot of folks
would like to run it like that. For detection of c2 in real-time on a large
pipe you need some capability that has the ability to scale (and just be
faster overall). If the performance hit added by the translation of bro
script is too huge, then it would be slow, but given Bro Cluster's ability
to scale I would hope that it could be somehow managed.

The alternative would be to add another bro framework (or augment the
signature framework) to allow for C or C++ like code to be directly
executed on packets akin to Shared Object Rules or to add some abstracted
math language to it that gets parsed and directly executed. The other
alternative, of course, is to just use another detection system.

P.S -- full disclosure -- I'm the primary author of ChopShop.

On Sat, May 24, 2014 at 2:56 AM, anthony kasza <anthony.kasza at gmail.com>

> I'd love to see these operations built into Bro. However, considering
> Bro's focus on scale, individual c2 operations analysis (especially when
> applied to specific connections within a large pipe) may be better suited
> for something like chopshop or another framework focussed on individual
> connections. Any other opinions?
> -AK
> On May 23, 2014 10:52 PM, "M K" <mkhan04 at gmail.com> wrote:
>> My method was to take a string of bytes and convert them to integral
>> types I wanted.
>> So if I received a 'string' type in a function I could do:
>> local foo1 = bytestring_to_count(sub_bytes(string, 0, 4));
>> local foo2 = bytestring_to_count(sub_bytes(string, 4, 2));
>> local foo3 = bytestring_to_count(sub_bytes(string, 6, 2));
>> bar = foo1 ^ 0x12345678;
>> bah = (foo2 + foo3) & 0xFFFF;
>> if  ( bar == 0xDEADBEEF && bah > 0x1234 ) {
>> #do a barrel roll
>> }
>> On Sat, May 24, 2014 at 1:42 AM, Vern Paxson <vern at icir.org> wrote:
>>> > Bitwise operations on user defined stream fields for custom protocol
>>> Okay, these examples make sense to me.  Let me ask then about what such
>>> operators should look like.  M K originally sketched them as operating on
>>> integral types.  However, I'd think that if it's for manipulating blobs
>>> of C&C, then instead working on strings would be the right target ... ?
>>>                 Vern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20140527/9573620d/attachment.html 

More information about the Bro mailing list