[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