Attach Barnyard2 to Bro2

I am attempting to use Barnyard2 to feed events from Suricata to Bro2. It looks like Barnyard2 wants to access Bro on 47757/tcp. Bro is not currently listening to that port. And Im not sure how to get it listening, or if thats just the old port it used to listen to. I attempted to have barnyard connect to 47760 in standalone mode, and 47761 or 47762 or 47763 in clustered mode. In all instances Barnyard seems to connect to Bro, and then unexpectedly crashes. Am I missing something? Should bro be listening to 47757/tcp?

Any help would be great!

Thanks,

Jeremy

I am attempting to use Barnyard2 to feed events from Suricata to Bro2. It looks like Barnyard2 wants to access Bro on 47757/tcp. Bro is not currently listening to that port.

Should bro be listening to 47757/tcp?

Only if you’re running a command-line bro. 47757/tcp is the default listen port for running bro command-line style.

And Im not sure how to get it listening, or if thats just the old port it used to listen to. I attempted to have barnyard connect to 47760 in standalone mode

47760/tcp is the default listen port of the bro instance of BroControl’s standalone node.

and 47761 or 47762 or 47763 in clustered mode.

47761/tcp is the listen port of the bro manager node when using BroControl to manage a closer. It probably makes most sense to configure Barnyard2 to connect to this port if you’re running a Bro cluster.

In all instances Barnyard seems to connect to Bro, and then unexpectedly crashes. Am I missing something?

What versions of Bro and Barnyard2 are you using (and any particular configure flags for Barnyard2, like —enable-ipv6) ? IIRC I think you will need at least Bro 2.1 and Barnyard 2.1.10.

I was able to get something simple working w/ latest Bro and Barnyard git master branches. The only extra thing to do in Bro that’s not obvious is make sure the manager node has code to accept Barnyard alerts (putting it in site/local.bro is the simple way):

   @load policy/integration/barnyard2
   redef Communication::nodes += {
       ["local"] = [$host=127.0.0.1, $class="barnyard", $events=/Barnyard2::barnyard_alert/, $connect = F]
   };

Another limitation of the Barnaryd2 Bro output plugin is that if it tries to send events regarding non-TCP/UDP/ICMP ports, it may crash. See [1] for a potential patch for that, which doesn't seem to have been reviewed or merged in to Barnyard2 yet.

- Jon

[1] http://mailman.icsi.berkeley.edu/pipermail/bro-dev/2013-January/005607.html

Thanks Jon, I’ll give that a try.

Jeremy

That seems to be working well. I had to upgrade barnyard, and I also patched barnyard2 with the patch listed. Barnyard appears to be pushing the alerts into Bro. At least it has not crashed :).

But I’m not sure where those alerts end up being logged in bro.

/mnt/iscsi/bro/logs/current# ls

communication.log dhcp.log dpd.log ftp.log known_hosts.log smtp.log software.log stderr.log syslog.log weird.log

conn.log dns.log files.log http.log known_services.log socks.log ssl.log stdout.log tunnel.log

I haven’t seen any new files show up.

I am hopeful that I can tie the two IDSs together in the same set of logs and rotations. So that when I analyze the logs, they are both from the same time period.

Jeremy

It produces a barnyard2.log.

Did you redef Communication::nodes to register Bro to receive the barnyard events? E.g. in site/local.bro put code like the following:

@load policy/integration/barnyard2
  redef Communication::nodes += {
      ["local"] = [$host=127.0.0.1, $class="barnyard", $events=/Barnyard2::barnyard_alert/, $connect = F]
  };

- Jon

I did. I have also put it back into standalone mode to see if that did it… No luck.

/opt/bro2/share/bro/site# cat local.bro
##! Local site policy. Customize as appropriate.
##!
##! This file will not be overwritten when upgrading or reinstalling!

This script logs which scripts were loaded during each run.

@load misc/loaded-scripts

Apply the default tuning scripts for common tuning settings.

@load tuning/defaults

Load the scan detection script.

@load misc/scan

Log some information about web applications being used by users

on your network.

@load misc/app-stats

Detect traceroute being run on the network.

@load misc/detect-traceroute

Generate notices when vulnerable versions of software are discovered.

The default is to only monitor software found in the address space defined

as “local”. Refer to the software framework’s documentation for more

information.

@load frameworks/software/vulnerable

Detect software changing (e.g. attacker installing hacked SSHD).

@load frameworks/software/version-changes

This adds signatures to detect cleartext forward and reverse windows shells.

@load-sigs frameworks/signatures/detect-windows-shells

Uncomment the following line to begin receiving (by default hourly) emails

containing all of your notices.

redef Notice::policy += { [$action = Notice::ACTION_ALARM, $priority = 0] };

Load all of the scripts that detect software in various protocols.

@load protocols/ftp/software
@load protocols/smtp/software
@load protocols/ssh/software
@load protocols/http/software

The detect-webapps script could possibly cause performance trouble when

running on live traffic. Enable it cautiously.

#@load protocols/http/detect-webapps

This script detects DNS results pointing toward your Site::local_nets

where the name is not part of your local DNS zone and is being hosted

externally. Requires that the Site::local_zones variable is defined.

@load protocols/dns/detect-external-names

Script to detect various activity in FTP sessions.

@load protocols/ftp/detect

Scripts that do asset tracking.

@load protocols/conn/known-hosts
@load protocols/conn/known-services
@load protocols/ssl/known-certs

This script enables SSL/TLS certificate validation.

@load protocols/ssl/validate-certs

Uncomment the following line to check each SSL certificate hash against the ICSI

certificate notary service; see http://notary.icsi.berkeley.edu .

@load protocols/ssl/notary

If you have libGeoIP support built in, do some geographic detections and

logging for SSH traffic.

@load protocols/ssh/geo-data

Detect hosts doing SSH bruteforce attacks.

@load protocols/ssh/detect-bruteforcing

Detect logins using “interesting” hostnames.

@load protocols/ssh/interesting-hostnames

Detect SQL injection attacks.

@load protocols/http/detect-sqli

Network File Handling

Enable MD5 and SHA1 hashing for all files.

@load frameworks/files/hash-all-files

Detect SHA1 sums in Team Cymru’s Malware Hash Registry.

@load frameworks/files/detect-MHR

@load policy/integration/barnyard2
redef Communication::nodes += {
[“local”] = [$host=127.0.0.1, $class=“barnyard”, $events=/Barnyard2::barnyard_alert/, $connect = F]
};

I’m not sure then. You can check Bro’s communication log to see if it looks like a connection is actually established; Barnyard2’s log should also indicate whether it connected. The other thing I can think of would be if there’s no alerts actually being generated. How are you running Barnyard2 ? Is it pointed at the right place w/ unified2 alert files that are being populated?

- Jon

I found it. Barnyard was pointing at the server’s public IP address. As soon as I told Barnyard to point at 127.0.0.1, Bro started logging the Barnyard alerts. Thanks for all your help!!

Jeremy