Friday, October 16, 2015

Bro in the Classroom

This past Wednesday, I was lucky enough to be asked to lead an evening class at DePaul University on using Bro. The students in the class are preparing for an annual cyber defense competition called CCDC. This  competition is actually where I cut my teeth defending realistic computer  networks. I had the opportunity to participate through multiple years of competition, one of which we even made it to the national level. After graduating I also had a chance to experience CCDC from the other side while participating on the red team. Last Wednesday, for the first time, I had a chance to see the other side of a university course while leading the class.

I was given three hours time for the class which I split 60/40 between lecture and hands-on lab time. The lecture material presented foundation topics  needed to understand what Bro does and how it works. A decent  understanding of protocol design, event based systems, system administration, and network forensics are all required before thinking about Bro. These topics were covered briefly, followed by Bro specific material. I also briefly discussed ElasticSearch and ELK and how those projects integrate with Bro (the ElasticSearch log writing code is now a plugin).

I've published the slides I presented for the lecture as well as the lab (which includes the step-by-step commands needed to set up Bro and ELK).

Instructing a class was an experience; instructing a class remotely was definitely a challenge, and I thank everyone for their patience with my ignorance of remote meeting software. I really enjoyed it and hope all the students gained *some* knowledge from the material even if it was only from my opinionated tangential rants about RFCs and HTTP.

Tuesday, September 1, 2015

Bro Plugins Part II: Redis

Plugins Part II
Plugins in Bro have been around for a while, however they are starting to move outside of the "core" and are now beginning to resemble Apache modules. I think this is wise for a few reasons. One, as Bro becomes popular certain features need to stay in the core and certain features need to definitely not be in the core. This is the same reason why numpy or pandas libraries aren't included in Python by default. They offer fantastic solutions to specific problems but not everyone needs or wants them. Two, as more people start to use Bro and want to customize it an issue around trusted extensions and capabilities arises. Moving to a plugin architecture will push the burden of vetting code to the Bro operator and away from the Bro development team. Third, an external plugin architecture provides a nice landscape for a package manager, which has been on the Bro todo list for a little while.
To test out the Redis plugin, simple clone the Bro repository recursively as typically done, configure and build Bro, change to aux/plugins, and run "make build-redis". Lastly, you'll need to set your BRO_PLUGIN_PATH environment variable the location of aux/plugins. To compile the plugin you'll need a few development header files installed but if all was successful you should see a dynamically loaded Redis plugin when you run:

bro -N 2>&1 | less -S
All the configurable options for the plugin are located in aux/plugins/redis/scripts/init.bro, which is bootstrapped by aux/plugins/redis/scripts/__load__.bro as one would expect.

If you then start the Redis server on the same host you are running Bro on and invoke Bro with the script aux/plugins/redis/scripts/Bro/Redis/logs-to-redis.bro you should eventually see protocol logs which would have been sent to Redis dumped to stdout. Currently, I could only get the plugin to execute the Redis PING command for each log entry Bro was ready to write.

It will be interesting...
It will be interesting for reading/writing to/from memory instead of disk. Imagine using Redis as a LRU cache to store things like HTTP user-agents seen egressing a network or creating a hot (Redis) and cold (ElasticSearch) storage system for complex hash maps of connection tuples and service types. Check out this sort of old article outlining how HipChat did it.

It will be interesting to use for logging. Redis is often used as a broker back end in scalable applications and I think having logs written to it is a big first step in building larger scale systems which act on network activity. Other processes and systems may be able to ingest Bro logs much quicker than if reading from flat files or having to hook into Bro specific client libraries.

It will be interesting for the Input framework. Having Redis as a back end could also allow easier integration between third party intelligence providers. For example, external Python scripts could be used to parse network indicators from those flashy [adjective] [noun] titled threat reports vendors publish and push those threat indicators into Redis for Bro to ingest and notify against.

In Conclusion    
It's good to see Bro playing nice with other open source project. The JSON log writer was a huge boon for those indexing logs with ElasticSearch and Mongo. Plugins of these types will assist in more wide spread use and adoption of Bro outside of research labs.

Sunday, August 16, 2015

Exploring Rabbit Holes

First off, thanks to @brucedang for getting me back into this blog. I started writing this thing for myself in hopes of keeping track of what I've done with Bro and how I learned it. It's rewarding to hear other people find it useful too.

I was tossing around a few ideas for a blog post and decided to grep through scripts/ for modules to discuss. If you search Github for "module" you can find them, but the command I used to do so was:
grep -R '^module' ./* | cut -d':' -f2 -s | sort -u | less -S

I came across a few things I hadn't heard of or didn't remember digging into before. The KRB module was new to me. It's for Kerberos protocol analysis. Other modules were more familiar to me but I haven't grokked the code in them. Things such as:
  • Known
  • Weird
  • Files
  • PE
  • AppStats

I also found a confusing module called Threading. I found this confusing because I was under the impression Bro was single threaded. The documentation for setting up a Bro cluster discusses CPU pinning for workers. What was this threading module used for?

I grepped through scripts/ again for any references to this module with:
grep -R '^module Thread' ./*
One hit. In scripts/base/init-bare.bro. This file is hard coded (linking to lines in Github generally isn't immutable, so search for 'add_input_file("base/init-bare.bro");') to load as long as Bro isn't run in "bare" mode (a mode where Bro loads a minimal set of scripts). So I opened this file and found a very small amount of Bro script belonging to that module's namespace. In the module's export declartion was a single re-definable constant called "heartbeat_interval". It was set to 1.0 seconds. There were also some comments stating that changing this value will likely break some things.

Interesting. So I searched through scripts/ again, this time looking for references to "heartbeat_interval". I found zero use of the value. So why was it defined at every Bro invocation?

At first I thought it must be dead code. Perhaps the module was left over from an unfinished feature or perhaps it was from a feature that was available in an older version but longer supported. Large C++ projects are often notorious for having dead code. But this is the Bro team; I should have known better.

I went to Github again and looked through the blames around that line in inti-bare. The definition of heartbeat_interval was done in a merge named "topic/robin/input-thread-merge". I was still confused. So I grepped through src/ to try to find where this value was used. This time I found a few different .cc files.

Again going back to Github and looking at the blames for these files I found the heartbeat_interval variable is used in the Input framework. Going back to the Input framework documentation, the use of threads for reading data into Bro is described. Thus the mystery was solved. Threads are used for reading in files from disk for Bro to use such as in the Intel framework. I had encountered the use of threads in the Input framework before but didn't truly know how they worked until now.

Pretty neat. 

This is how I found one of the many interesting pieces of Bro. If you poke around the scripts and core source enough, you find a huge amount of interesting code and concepts.