Debugging Bro Scripts Where action = Notice::ACTION_EMAIL

Zeek
1

I spent quite a bit of time and effort trying to figure out. Dropping
a note out to the community to hopefully help the next guy.

Over in this thread
http://mailman.icsi.berkeley.edu/pipermail/bro/2012-August/005811.html

I couldn't figure out why this script
http://mailman.icsi.berkeley.edu/pipermail/bro/2012-August/005812.html

would not send an email alert via the Notice framework.

I was testing the script on a small pcap file. I thought that
debugging approach would enable me to quickly, easily, and reliably
check to see if my new bro script was working as intended.

Here's the problem with that development/debugging approach. The
first few lines in the function email_notice_to (found in
frameworks/notice/main.bro specifically) check to see if you are
reading traffic from a trace file, and then silently disable email
alerting if you are. This turned out to be very frustrating to debug.

To confirm that my script was working as expected, I had to change the
following lines in frameworks/notice/main.bro:

function email_notice_to(n: Notice::Info, dest: string, extend: bool)
        {
       if ( reading_traces() || dest == "" )
               return;

to the following:

function email_notice_to(n: Notice::Info, dest: string, extend: bool)
        {
# if ( reading_traces() || dest == "" )
# return;

If you plan to test a new script where you expect it to send an email
via the Notice framework, I recommend that you send traffic that ought
to should trigger an email alert over the wire.

That's not a viable option for me, so commenting out the lines above
is a better approach.

Would also recommend that either the bro documentation make note of
this "feature" or that the resulting notice.log print a message to
indicate that email alerting was disabled because it isn't reading
traffic from a live network capture.

-Chris

2

One more note:

A line like

redef Notice::mail_dest = "alert@email.com";

in a custom Bro script doesn't appear to override the value specified
by the MailTo variable set in etc/broctl.cfg .

It appears that either your email alerts from the notice framework are
sent to the value specified by MailTo, or they don't get sent out at
all.

-Chris

3

Yes, this is an unfortunate side effect to automatically changing settings through BroControl. I believe that the documentation has been updated for 2.1 to clarify which variables are affected. I still don't think we are completely sure the direction this will go long term, but it is definitely unclear at the moment.

  .Seth

4

Why are you looking to send an email while reading a tracefile? The same notice will be in the notice.log.

I do agree that we should output a reporter message if someone tries to send an email while reading a tracefile though, we just can't sneak that feature into 2.1 but I'll file a ticket for it.

  .Seth

5

Seth,

Might be a useful feature if someone were to integrate bro as a Cuckoo
box plugin or in a sandnet of some sort. Just a thought.

Liam

Of Seth Hall

6

Good point. I'll think about this some more.

  .Seth

7

Not sure how much of a pain this idea would be to implement, but it
would be great if all email went to the address specified by MailTo,
unless you specifically override that value in a custom bro script.
That way a bro script could have something similar to a local MailTo
variable and all notices sent out from that custom script would be
sent to the new email address.

-Chris

8

I wasn't confident that an email would fire from my bro script, so I
wanted to test it with a tracefile first. I knew that the tracefile
contained the network conditions I was interested in, so this seemed
like a reasonable way to verify my script. The fact that I didn't see
any email while I was testing the script led me to believe that either
I was doing something wrong, or that part of the notice framework was
broken. Either way, I wouldn't have had much confidence that my
script was doing what I wanted it to do, so what would be the point in
using it in a live capture scenario?

-Chris

9

You will still see the Notice::ACTION_EMAIL action attached to your notice in notice.log.

I do agree though that we need to revisit the decision of how email is handled. You may be right that the correct decision is to get rid of those two lines like you did. We just need to think about it a bit more.

Thanks!
  .Seth