9 Replies Latest reply on Jun 30, 2016 4:13 PM by d_j

    Bro IDS Sensor - Which types to forward to SIEM?


      I'm forwarding bro events from SecurityOnion sensors to Nitro, but they have a high volume (BRO_CONN, etc).  What subset of bro data types have folks found useful to forward?


      I'm most interested in adding correlation intelligence to the other data in the SIEM, and using the bro data for incident / alarm forensics.  (Who did what, when.)


      Thank you.

        • 1. Re: Bro IDS Sensor - Which types to forward to SIEM?

          I haven't got mine going yet but will be thinking about the same thing once I do get it going. Can you post how you did it from Security Onion? Thanks

          • 2. Re: Bro IDS Sensor - Which types to forward to SIEM?

            Sure thing.  You want to configure syslog-ng on SecurityOnion to forward Bro events to Nitro (or any other system accepting syslog).  The key is to only forward Bro events, not other things that ELSA and other tools want as well.  Note that if you also want to forward OS logs from SecurityOnion, you need to send them to another Nitro syslog port or to another receiver.  You can only configure one source IP as a syslog data source per receiver.


            On the SecurityOnion server running bro, edit the file /etc/syslog-ng/syslog-ng.conf


            Search for "destination d_elsa" and right before it paste the following lines: (substituting your receiver's IP for 123.456.789.012)


            destination d_siem { network("123.456.789.012" transport("udp")); };


            log {


























                    log { destination(d_siem); };



            Save the conf file and restart syslog-ng with the command "service syslog-ng restart"


            On Nitro, add a new data source to the receiver.  Choose the following options:

            Data Source Vendor: Bro Network Security Monitor

            Data Source Model: Bro Network Security Monitor (ASP)

            Data Format: Default

            Data Retrieval: SYSLOG


            You may not wish to enable logging because if Bro is monitoring an active circuit, it can generate a LOT of events.


            I'm not yet certain of the event type order, as I don't see everything I should in Nitro.  I'm guessing the parser is dropping stuff it doesn't recognize.  Feedback is welcome.


            Give it a shot and let me know if you find any particular subset of events more useful than others.  I'm still interested in an answer to my original question.



            • 3. Re: Bro IDS Sensor - Which types to forward to SIEM?

              Thanks. I got it working but for some reason it didn't like the word 'network' in the first line starting with destination. I had to change that to syslog and it was good to go.


              The only parser I had in policy editor for Bro was for the dns.log so I enabled that. Also in the data source, I set the option for Support Generic Syslog to "Log 'unknown syslog' event". When I check out the dashboard, I the data for DNS populates as I think it should and there is a crap load in unknown events (which I assume is all the other logs that I don't have parsers for). Maybe thats where the data you don't see is.


              Were all the parsers in policy editor for you or did you make them?

              • 4. Re: Bro IDS Sensor - Which types to forward to SIEM?

                After some discussion with Intel support, the only pre-defined parser is for Bro DNS logs, so what you see is what you get.  I believe I saw some other types of event parsers that could be applied to Bro, so I'll look at that next and share if I come up with anything.


                In the meantime, using just the "source(s_bro_dns);" will cut down on traffic and log storage.  The other events won't get corelated (of course) until a parser is applied.


                At the least I'd like to get s_bro_conn (connections) parsed, as that will tell me who is talking to what, when.


                Thanks for engaging.  If we can get just one more type parsed I'll consider this a success.

                • 5. Re: Bro IDS Sensor - Which types to forward to SIEM?

                  So I wrote the parser for the conn log. Thus far, I have seen benefit in using it within my network. I have included it below.


                  (?P<time>\d+\x2e\d+)*\x09(?P<uid>[0-9a-zA-Z]+)\x09(?P<src_ip>[^\x09]+)\x09(?P<sr c_port>\d{1,5})\x09(?P<dst_ip>[^\x09]+)\x09(?P<dst_port>\d{1,5})\x09(?P<protocol >[^\x09]+)\x09(?P<service>[^\x09]+)\x09(?P<duration>\d+\x2e\d+)\x09(\d+)\x09(\d+ )\x09(?P<conn_state>[0-9a-zA-Z]+)\x09(\w+)\x09(\w+)\x09(\w+)\x09(?P<history>[0-9 a-zA-Z]+)\x09(\d+)\x09

                  • 6. Re: Bro IDS Sensor - Which types to forward to SIEM?

                    What part of the conn log are you parsing?  I ask because this is a typical line in my conn log:




                    or this:




                    Can you post some samples of what you're parsing?


                    Thanks for posting the regex!



                    • 7. Re: Bro IDS Sensor - Which types to forward to SIEM?

                      I took the first three records from the log, a snippet is below. Looking at yours, they look the same.





                      I ended up doing the DHCP log as well... regex below.


                      (?P<time>\d+\x2e\d+)*\x09(?P<uid>[0-9a-zA-Z]+)\x09(?P<src_ip>[^\x09]+)\x09(?P<sr c_port>\d{1,5})\x09(?P<dst_ip>[^\x09]+)\x09(?P<dst_port>\d{1,5})\x09(?P<src_mac> [^\x09]+)\x09(?P<assigned_ip>[^\x09]+)

                      • 8. Re: Bro IDS Sensor - Which types to forward to SIEM?

                        I attempted to create a new parser using your conn regex, but when I insert the regex or a copy of a log to parse into the editor, I get: parser error.JPG


                        Any ideas why?


                        Thank you,



                        • 9. Re: Bro IDS Sensor - Which types to forward to SIEM?

                          I have no idea. Below are screenshots of my setup.


                          Screen Shot 2016-06-30 at 5.09.17 PM.pngScreen Shot 2016-06-30 at 5.09.52 PM.pngScreen Shot 2016-06-30 at 5.10.04 PM.pngScreen Shot 2016-06-30 at 5.10.13 PM.png