I'm helping to customize an existing deployment of Bro and while I think I'm
collecting all the file info correctly, I'm not hitting any matches when I run
the hashes against cymru's database. I was wondering if someone could confirm
that none of these hashes match either. I've run them against the DNS,Whois
and web queries and had no luck. I work at a very open place and I find it
almost impossible that not one of the 1.7M hashes match. In the event there
are no matches, could someone point me to some sample pcap files so I can test
If someone wanted to help cross correlate my findings, I could send offline a
.gz of 1.7M hashes from a few hours of collection.
Thanks again for any help or assistance
We'd like to start bro with a tcpdump filter of, for example, -f 'net
188.8.131.52/24 or port 443'. We use broctl to manage the bro process. Where
is the appropriate place to add the desired filter so that broctl appends
it to any instantiation of a bro process?
Thanks for your help
Hello, new here
I'm using bro 2.2 and I connect to bro using broccoli to receive events.
I can manage connecting to bro-worker and receive events, not sure if it's
the correct way to receive event from bro but connecting to the manager
port didn't retrieve any event whatsoever,
the problem is that when I receive events at speeds higher than 2Mbps the
parent of the bro-worker (not the broccoli application) memory expands
rapidly and can reach 10Gb in a minute.
Disconnecting the broccoli application immediately frees all memory of the
worker (10Gb to 100Mb in less than a second).
Quick question, can you change the default file extraction directory for
files being extracted in a script. After some poking I came across where
this was specified in /opt/bro/share/bro/base/files/extract/main.bro with
## The prefix where files are extracted to.
const prefix = "./extract_files/" &redef;
If I try to do something like this in my script:
# Set extraction folder
redef prefix = "/var/opt/bro/spool/extract_files";
I am met with the following:
error in ./scripts/file-ext.bro, line 22: "redef" used but not previously
internal warning in ./scripts/file-ext.bro, line 22: Can't document redef
of prefix, identifier lookup failed
Can someone help me understand how to define this attribute or otherwise
influence where the files are extracted to? I would rather not manually
define it in the main.bro file.
Doug Burks was quick to point out that i didn't export LIBS or LDFLAGS.
I would have NEVER guessed this... thanks a thousand times over for this
tidbit. Configure finished just fine. Making now. Will update once i've
got it up and load balanced.
export LDFLAGS="-Wl,--no-as-needed -lrt"
export LIBS="-lrt -lnuma"
On Thu, Aug 28, 2014 at 6:52 PM, Doug Burks <doug.burks(a)gmail.com> wrote:
> Hi Joe,
> When I packaged Bro 2.3 and PF_RING 6.0.2, I had to do the following:
> export LDFLAGS := $(LDFLAGS) -Wl,--no-as-needed -lrt
> export LIBS := $(LIBS) -lrt -lnuma
> Depending on your configuration, you may also need to include
> -lpthread in your LIBS.
> On Thu, Aug 28, 2014 at 5:52 PM, Joe Blow <blackhole.em(a)gmail.com> wrote:
> > Hey all,
> > I'm having a really tough time getting PF_RING working with Bro in a
> > threaded fashion. I have PF_RING compiled and working fine (tcpdump test
> > works fine with Transparent mode = 2):
> > PF_RING Version : 6.0.2 ($Revision: exported$)
> > Total rings : 0
> > Standard (non DNA) Options
> > Ring slots : 4096
> > Slot version : 16
> > Capture TX : No [RX only]
> > IP Defragment : No
> > Socket Mode : Standard
> > Transparent mode : No [mode 2]
> > Total plugins : 0
> > Cluster Fragment Queue : 0
> > Cluster Fragment Discard : 0
> > Bro is version 2.3 (sha1 - 79397be0e351165d44047b044d29b5e6580532cc
> > bro-2.3.tar.gz)
> > OS is CentOS 6.4 running 2.6.32-358.11.1.el6.x86_64
> > When I try and configure against my PF_RING libraries, I get this:
> > ./configure --with-pcap=/opt/pfring
> > Build Directory : build
> > Source Directory: /root/src/bro-2.3
> > -- The C compiler identification is GNU
> > -- The CXX compiler identification is GNU
> > -- Check for working C compiler: /usr/bin/gcc
> > -- Check for working C compiler: /usr/bin/gcc -- works
> > -- Detecting C compiler ABI info
> > -- Detecting C compiler ABI info - done
> > -- Check for working CXX compiler: /usr/bin/c++
> > -- Check for working CXX compiler: /usr/bin/c++ -- works
> > -- Detecting CXX compiler ABI info
> > -- Detecting CXX compiler ABI info - done
> > -- Found sed: /bin/sed
> > -- Found Perl: /usr/bin/perl
> > -- Found FLEX: 2.5.35
> > -- Found BISON: /usr/bin/bison
> > -- Found PCAP: /opt/pfring/lib/libpcap.so
> > -- Performing Test PCAP_LINKS_SOLO
> > -- Performing Test PCAP_LINKS_SOLO - Failed
> > -- Looking for include files CMAKE_HAVE_PTHREAD_H
> > -- Looking for include files CMAKE_HAVE_PTHREAD_H - found
> > -- Looking for pthread_create in pthreads
> > -- Looking for pthread_create in pthreads - not found
> > -- Looking for pthread_create in pthread
> > -- Looking for pthread_create in pthread - found
> > -- Found Threads: TRUE
> > -- Performing Test PCAP_NEEDS_THREADS
> > -- Performing Test PCAP_NEEDS_THREADS - Failed
> > CMake Error at cmake/FindPCAP.cmake:61 (message):
> > Couldn't determine how to link against libpcap
> > Call Stack (most recent call first):
> > cmake/FindRequiredPackage.cmake:26 (find_package)
> > CMakeLists.txt:52 (FindRequiredPackage)
> > -- Configuring incomplete, errors occurred!
> > I'm banging my head against this, but I believe this is because bro can't
> > find the threading library to link to. Could someone point me in the
> > direction? Do I need other threading libraries? Static linking?
> > Cheers,
> > JB
> > _______________________________________________
> > Bro mailing list
> > bro(a)bro-ids.org
> > http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
> Doug Burks
> Need Security Onion Training or Commercial Support?
We have an install of bro running on a single machine with PF_RING load balancing.
Previously we were seeing a huge amount of dropped traffic — in the realm of ~90% average packet loss per hour. The history column in our `conn.log` was trash as expected, with only one or two letters per connection.
After some tweaking (adding memory & upping # of bro processes & changing PF_RING buffer size), the logs look much better and the packet loss is drastically reduced, to about 0.5%-1% loss per hour. However, both `broctl netstats` and `cat /proc/net/pf_ring/*eth0*` report some packet loss still.
Is the sub-1% packet loss we’re seeing expected/optimal or are there additional tweaks that we could add to push this down to 0%?
### some notes ###
> both `tcpdump -nn -s0 -vv -i eth0 -w /dev/null` and the pfcount.c utility from pf_ring report 0% packet loss. It’s not until we start using bro that we start seeing dropped packets.
> we’re currently using 16 bro processes pinned to 16 of 32 total processors
> PF_RING buffer size is currently 65536
> packet loss does seem to go down during low-traffic hours but during the day when traffic is 2.5-3 gbps is when the dropped packet count peaks (while still being a small percentage of the overall traffic)
Let me know if you guys have any thoughts on this, thanks!
- - -
Washington University in St. Louis :: Information Security
I'm having a really tough time getting PF_RING working with Bro in a
threaded fashion. I have PF_RING compiled and working fine (tcpdump test
works fine with Transparent mode = 2):
PF_RING Version : 6.0.2 ($Revision: exported$)
Total rings : 0
Standard (non DNA) Options
Ring slots : 4096
Slot version : 16
Capture TX : No [RX only]
IP Defragment : No
Socket Mode : Standard
Transparent mode : No [mode 2]
Total plugins : 0
Cluster Fragment Queue : 0
Cluster Fragment Discard : 0
Bro is version 2.3 (sha1 - 79397be0e351165d44047b044d29b5e6580532cc
OS is CentOS 6.4 running 2.6.32-358.11.1.el6.x86_64
When I try and configure against my PF_RING libraries, I get this:
Build Directory : build
Source Directory: /root/src/bro-2.3
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found sed: /bin/sed
-- Found Perl: /usr/bin/perl
-- Found FLEX: 2.5.35
-- Found BISON: /usr/bin/bison
-- Found PCAP: /opt/pfring/lib/libpcap.so
-- Performing Test PCAP_LINKS_SOLO
-- Performing Test PCAP_LINKS_SOLO - Failed
-- Looking for include files CMAKE_HAVE_PTHREAD_H
-- Looking for include files CMAKE_HAVE_PTHREAD_H - found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Performing Test PCAP_NEEDS_THREADS
-- Performing Test PCAP_NEEDS_THREADS - Failed
CMake Error at cmake/FindPCAP.cmake:61 (message):
Couldn't determine how to link against libpcap
Call Stack (most recent call first):
-- Configuring incomplete, errors occurred!
I'm banging my head against this, but I believe this is because bro can't
find the threading library to link to. Could someone point me in the right
direction? Do I need other threading libraries? Static linking?
I need to run the following command "racluster -r
argus.2014.08.19.10.30.01.0.gz -s stime daddr -s stime saddr daddr
trans" but to display only events from 10:00am to 10:15am.
How can I accomplish this?
I'm developing a program that dumps selected traffic to a tap device
which bro is listening on. This works great. However to increase
performance I'm trying to use receive side scaling, splitting the packet
stream into multiple queues according to ips, ports etc. This results in
packet reordering which confuses bro and the data is not analyzed and
assembled correctly. Other programs such as wireshark and tcpflow are
able to assemble the traffic correctly so all data is there. Typically
small packets such as acks seems to arrive before larger packets.
I have been searching for bro configurations that affect the tcp
reassembly process but have so far not found anything that makes the
situation better. Is there any particular configurations I should look at?
Anyone have experience with RSS and have any ideas how the packet
reordering issue can be mitigated?