[Bro] delayed bro operation / update

Frank Meier franky.meier.1 at gmx.de
Tue Jul 7 05:11:11 PDT 2015


Hi,

just as a follow up: I experimented with a patched version of tcpslice 
which opens pcaps and sends them to a fifo. 
When there are no more pcaps, it blocks, but keeps the fifo open. Bro 
reading from that fifo will also block 
until data is sent. With this setup I get the same results as if I 
merged the pcaps before processing them
with bro. So my worries about timers in bro were uncalled-for.

If anyone is interested in this, just drop me a mail.

Franky


On Mo, Apr 27, 2015 at 9:29 , Frank Meier <franky.meier.1 at gmx.de> wrote:
> Hi.
> 
> On Fr, Apr 24, 2015 at 4:23 , Seth Hall <seth at icir.org> wrote:
>> 
>>>  On Apr 24, 2015, at 5:16 AM, Frank Meier <franky.meier.1 at gmx.de> 
>>> wrote:
>>>  
>>>  A policy forces me to run bro in a separate network. So the 
>>> captured PCAPs are
>>>  transfered to the bro network for logging purposes. How would I 
>>> handle delays
>>>  in feeding bro with the PCAPS? Would connections spanning multiple 
>>> PCAPs be a
>>>  problem?
>> 
>> This is a problem that PacketBricks[1] will be able to solve 
>> eventually.  It’s not there yet, but eventually you’ll be able 
>> to create a load balancing architecture with persistent 
>> Bro/Snort/Suricata/etc processes and tell PacketBricks to read PCAPs 
>> as you get them in place (and, yes, I did just say clustered PCAP 
>> processing!).  Unfortunately this scenario is not quite ready in 
>> PacketBricks.
>> 
> 
> Thanks, I will have a look into that!
> 
> Franky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150707/ae3916a1/attachment.html 


More information about the Bro mailing list