When running bro in stand alone mode is there a size cutoff for it to
do anything with a pcap file?
In bro 2.0 and 2.1 if I run, on a small pcap (76k through 6mb):
bro -C -r ./input.pcap /usr/local/bro/share/bro/site/local.bro
it only creates
loaded_scripts.log
notice_policy.log
packet_filter.log
However, if I run the same commandline on a larger pcap 512mb it
produces more "normal" logs.
conn.log
http.log
etc...
I've looked through the pcaps in snort, wireshark, tcpdump, and tshark
and none of them have issues reading any of the small pcap files
(snort will also flag alerts where appropriate). There is app data
where expected in packet payloads and multiple setup/teardowns per
pcap.
I skimmed through the trace file and didn't see anything that looked
like an error.
Am I missing something simple? Does this have implications with
running bro in production?
When running bro in stand alone mode is there a size cutoff for it to
do anything with a pcap file?
No, small traces should produce the expected output. We have indeed a
larger number of unit tests that rely on that; see, e.g.,
testing/btest/scripts/base/protocols/smtp/basic.test for one using a
rather small SMTP trace.
My best guess is that's indeed something with your trace. Try some of
the small traces in testing/btest/Traces and see what they give you.
I've looked through the pcaps in snort, wireshark, tcpdump, and tshark
One difference between these and Bro is that Bro tracks the TCP state;
if there's trouble with that, Bro might abort processing, even though
the other tools continue with their packet-based analysis. Do you get
a conn.log? That should show up in any case.
There are 3-way handshakes and no conn log is produced. The pcaps used
for the tests worked correctly when I tried them.
However, the pcaps I'm testing on have a GRE tunnel in them. After
digging around a bit more it seems like this might be the issue. I
didn't look close enough in wireshark, and the rest of the tools do
the decapsulation before showing results
I might have some free cycles to poke at adding this functionality, it
may be entirely out of may capability at the moment but any help of
"if I were going to add it this is where it would need to go" would be
helpful in figuring out if I can do it or not.
I might have some free cycles to poke at adding this functionality, it
may be entirely out of may capability at the moment but any help of
"if I were going to add it this is where it would need to go" would be
helpful in figuring out if I can do it or not.
I think GRE tunnel decapsulation should look pretty similar to IP tunnel decapsulation which is coded in NetSessions::DoNextPacket() of Sessions.cc -- look for the switch statement cases for IPPROTO_IPV4/IPPROTO_IPV6. You might be able to simply lump IPPROTO_GRE in with that code block if you modify NetSessions::ParseIPPacket() to be able to extract the inner IP packet from a GRE encapsulation (possibly generating a some new "gre_packet_header" event with the parsed header fields) and also change the EncapsulatingConn constructor to explicitly require the type of tunnel as an argument. Enum values for the tunnel types are defined in types.bif; it would make sense to add a new GRE type there.
