delayed bro operation

Zeek
1

Hi.

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?

My first idea is to crank up all the timeouts like this:

redef tcp_inactivity_timeout = 5 days;
redef udp_inactivity_timeout = 5 days;
redef icmp_inactivity_timeout = 5 days;
redef default_file_timeout_interval = 5 days;

What performance penalty will I suffer? I guess the RAM usage will grow,
because connections, which were not cleanly terminated, would hang around
for a long time.

Are there any examples for this kind of setup? How would you search for this?

Have a nice weekend!

Franky

2

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.

redef tcp_inactivity_timeout = 5 days;
redef udp_inactivity_timeout = 5 days;
redef icmp_inactivity_timeout = 5 days;
redef default_file_timeout_interval = 5 days;

You could always try, but I get the sense you won’t be terribly happy with the result.

1. GitHub - bro/packet-bricks: A netmap-based packet layer for distributing and filtering traffic.

  .Seth

3

Hi.

4

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

5

Hah! That’s an interesting approach.

  .Seth

6

sounds intreresting. Would it be possible for you to make that tcpslice patch available?

Thanks!

//Kristoffer

7

I addressed a similar problem by writing a little C program that takes pcaps and pushes them onto a virtual network interface, for bro to monitor… Now let me see if I can find that code.

8

Hi Jim!

I addressed a similar problem by writing a little C program that takes pcaps and pushes them onto a virtual network interface, for bro to monitor… Now let me see if I can find that code.

we thought about that, but the disadvantage is, that all the timestamps get lost. Also we had a lot of problems with lost packets.

Franky

9

Hi Frank:

My application was a bit different - was receiving live pcaps from a multitude of sensors, and pushing them all in realtime onto the virtual interface, so the timestamp offset was negligible - this was also fairly low bandwidth - obviously, different applications require different tools.