Bro SMB and segfaulting

Zeek
1

Hey all!

  I compiled Vlad’s topic from github to try it out. It runs fine on low speed environments but when I drop it on a high speed sensor it blows up. The link the sensor is on runs at between 600Mbit and 2.5Gbit. When I was doing the testing it was running at around 700Mbit and 1.7M PPS. Normal Bro 2.3.1 runs fine with no traffic being dropped at the ring. I am running pf_ring vanilla. The box runs 1 manager, 2 proxies, and 10 workers. The box is a dual 10 core HT with 128GB of RAM. All workers are pinned to real processors. The sensor starts and begins writing logs and then the disk IO goes to 100% and stops writing. It also starts dropping packets from the ring immediatly. Then the workers segfault and I have to stop it because when they go into crazy town they tie up the disk IO. The conn log and the syslog.log are much larger than the smb logs. I tried turning off logging on some of the other busy log files in case it is a disk IO problem. It didn’t make a difference. I write a LOT of logs on normal 2.3.1 and the IO usage is ver low.

Has anyone had any luck running the SMB analyzer on high a high speed link? Is there anything I can provide to help figure out the root cause?

Thanks

Mike
@TOoSmOotH

2

Hint - do you send syslog somewhere else i.e. to some external logging
server? Is it possible that Bro can see the syslog packets? I'm
asking, because you said syslog.log is large. Make sure you're not
creating a positive feedback loop - Bro produces logs, logs gets send
on the wire, Bro sees logs, logs these logs :wink: and that creates new
logs about the logs, etc.

3

You could build Bro with debug.
rm -rf build.
./configure --enable-debug
make install

Start bro with your setup and use gdb to attach to the running process :

gdb -p

When it segfaults … gdb will wake up and you can post the trace using “t” command (stack trace) .