Capturing the raw trace...

Zeek
1

OK, so I understand that to really debug BRO one needs tcpdump stuff rather than BRO's connection records.

Discussing how to get a continuous supply of tcpdump stuff, Tim Rupp and I have come up this this idea ...

picture.jpg

2

Nice picture. :slight_smile: But try the -w option first; it records all of
Bro's input into a trace file.

Robin

3

Doh! RTFM! I actually spent some time *reading* the tcpdump man page (on tcpdump.org) and discovered that the '-G 3600' option will rotate the -w log files every hour. Humm, my Linux tcpdump 3.8 doesn't seem to have a -G option. Looks like I need tcpdump 3.9?

I will run tcpdump on a different system from BRO. I happen to have two systems connected to the border traffic fire-hose. I will be able to wait for BRO to trigger on a bogus outbound port scan and then go look for the raw dump file. So far, BRO hasn't triggered on any bogus outbound port scans since I sent my original mail. Humm, this must be a Heisenbug.

Thanks,
Randy

exists? Does BRO have some secret way of preserving the libpcap
output (er, the BRO input)?

Nice picture. :slight_smile: But try the -w option first; it records all of
Bro's input into a trace file.

Well, we need to manage the trace file. When BRO is checkpointed daily, will a new trace file be created?

4

Found it in tcpdump. Looks like it's not in the recent stable tarballs
though; I needed to compile from CVS.

Use the -G flag with an appropriate -w flag

for example, to create a new dump file every 10 seconds:

  tcpdump -G 10 -i eth0 -w "%Y-%m-%d_%H:%M:%S"

will create files that look like

  2007-10-10_14:10:14
  2007-10-10_14:10:24
  2007-10-10_14:10:34
  2007-10-10_14:10:44
  2007-10-10_14:10:54

Note that the time interval to -G isn't 100% accurate, but it's close
enough.

So LBL needs to push out 3.9 so that the world can rejoice in -G : )

Thanks,
-Tim

Randolph Reitz wrote:

5

the -w log files every hour. Humm, my Linux tcpdump 3.8 doesn't seem
to have a -G option. Looks like I need tcpdump 3.9?

(Yes, I think it's a pretty recent addition.)

Running a tcpdump in parallel is certainly a good thing if you have
the resources for that.

Well, we need to manage the trace file. When BRO is checkpointed
daily, will a new trace file be created?

You can use the mechanisms in rotate-logs.bro to rotate the trace
file with all the other logs by adding it to the aux_files set.
(When Bro rotates the files in aux_files, it will automagically do
the right pcap magic for the trace file.)

Robin

6

Randolph Reitz wrote:

OK, so I understand that to really debug BRO one needs tcpdump stuff
rather than BRO's connection records.

Discussing how to get a continuous supply of tcpdump stuff, Tim Rupp
and I have come up this this idea ...

Before we go off and invent the above, I'm asking if this already
exists? Does BRO have some secret way of preserving the libpcap
output (er, the BRO input)?

Thanks,
Randy

If you're looking to write pcaps out to disk, you can use something like
Time Machine (1), or Daemonlogger (2)

1: http://www.net.t-labs.tu-berlin.de/research/tm/
2: http://www.snort.org/users/roesch/Site/Daemonlogger.html

If you're interested, we can discuss off-list :slight_smile:

-Matt Cuttler

7

So LBL needs to push out 3.9 so that the world can rejoice in -G : )

FYI, LBL is no longer in the tcpdump development business. That's done
by folks at tcpdump.org, and has been for a while.

    Vern