Basic Alerts/Email questions

Zeek
1

I've been working with Bro for about a week focused on IDS/IPS functionality.

I'm starting small and took this snip of code from someone else asking how to get email alerts and put it in my local.bro

hook Notice::policy(n: Notice::Info) &priority=0
        {
        add n$actions[Notice::ACTION_EMAIL];
        }

I went through some documentation here:

https://www.bro.org/sphinx-git/scripts/base/frameworks/notice/main.bro.html

specifically the section labeled “Notice::Type” with ~40 different types listed starting with Notice::Tally.

This seems to be what is now emailed, although there are very few email notices being generated, and only from a few of the categories. Weird::Activitiy and Scan::Port_Scan

I also saw code like this somewhere

redef Notice::emailed_types += {
# FTP::Bruteforcing,
  FTP::Site_Exec_Success,
  HTTP::SQL_Injection_Attacker,
  HTTP::SQL_Injection_Victim,
# SMTP::Blocklist_Error_Message,
# SMTP::Blocklist_Blocked_Host,
# SMTP::Suspicious_Origination,
  SSH::Password_Guessing,
  SSH::Login_By_Password_Guesser,
  TeamCymruMalwareHashRegistry::Match,
  Intel::Notice,
  Intel::DOMAIN,
  Intel::CERT_HASH,
  Intel::FILE_HASH,
};

which seems to correlate to this documentation

https://www.bro.org/sphinx/bro-noticeindex.html

So I also threw that code into my local.bro

It doesn't seem to do anything. Is there a way I can check? Is it redundant with the hook code above to send an email for any notice?

2

hook Notice::policy(n: Notice::Info) &priority=0
       {
       add n$actions[Notice::ACTION_EMAIL];
       }

I don't think you want to do this. It will result in all notices being emailed.

It doesn't seem to do anything. Is there a way I can check? Is it redundant with the hook code above to send an email for any notice?

Notice::emailed_types is a pre-implemented mechanism if you only need coarse grained decisions about what to email. You can see how it's implemented in base/notice/main.bro. You can either easily use that or define your own Notice::policy hook to implement any other more complicated handling that you might want.

/usr/local/bro/share/bro/policy/protocols/ftp/detect.bro

Everything looks fine there to me....so why does FTP::Bruteforcing error but FTP::Site_Exec_Success not?

Are you loading the policy/ftp/detect-bruteforcing.bro script? If you aren't loading the script but you are trying to access identifiers defined in the script it won't work.

Weird:Activity – I have 25 SYN_after_partial alerts. Not particularly useful

I wouldn't typically put any huge attention to Weird logs or notices. They're helpful but typically not in day to day activity.

Scan::Port_Scan - 3 alerts. Substantially less than are actually occurring.

Measured how?

Aside from that I have 1 SQL injection alert from Bro.
Meanwhile I have 100s of SQLi alerts registered in snort.

I would pay attention to that one from Bro. It's likely higher value to you than the 100's from Snort.

I looked in /http/detect-sqli and it appears that it's just a regex. So the regex doesn't match 90+% of the sqli attacks seen on my network?


Bro is doing SQL injection detection based on a larger number of attacks either coming from an attacker or going to a victim. It was originally written to find SQL injection based data extraction (and has worked phenomenally well for that at a number of large sites). You can see individual requests that appear to be HTTP SQL injection requests in the "tags" field in the http.log. If you grep your http.log for URI_SQLI you will see the individual requests.

You seem to be approaching Bro from the perspective that it's a different version of Snort. Please try to let go of thinking about network monitoring and intrusion detection with the mindset of Snort where one signature generates one notice for a sequence of bytes. Spend a long time digging through the logs that it's generating, it's likely that you'll get a lot of pleasant surprises and you will learn a lot about your network that you didn't already know.

  .Seth

3

Hi Seth,

Thanks for the reply.

Aside from that I have 1 SQL injection alert from Bro.
Meanwhile I have 100s of SQLi alerts registered in snort.

- Found the problem here.

from detect-sqli.bro const sqli_requests_threshold: double = 50.0 &redef;

50 is just too high for my environment as the attacks get shut down before they reach that threshold. I redefined it to a lower value.

I'll skip the rest of the previous email and focus on the real message here.

You seem to be approaching Bro from the perspective that it's a different version of Snort. Please try to let go of thinking about network monitoring and intrusion detection with the mindset of Snort where one >signature generates one notice for a sequence of bytes. Spend a long time digging through the logs that it's generating, it's likely that you'll get a lot of pleasant surprises and you will learn a lot about >your network that you didn't already know.

You are 100% correct. I could list a number of different articles I've read recently, some of them by you in fact, that convey the same sentiments.

I'm already a believer and will continue to use Bro, but for management who will never directly interact with it, I need Bro to be meaningful to them. Whether that's Snort-like alerts, metrics, heuristic data, etc. I just went with alerts because it seemed like the easiest to get going straight away.

I've been combing through github.com/trending/bro for some scripts that I can add. I've done as many training exercises as I can find, including the ones offered on bro.org as well as some from other sites, including ones that deal with logging like you mention https://www.bro.org/bro-workshop-2011/solutions/logs/

So that's where I am. I will certainly continue working with the logs. In addition to that if you or anyone else have ideas on where I should be focusing my time for a new Bro install please let me know.

Thanks,
Eric

4

50 is just too high for my environment as the attacks get shut down before they reach that threshold. I redefined it to a lower value.

You have something in place already actively watching for attacks and shutting off attackers?

I'm already a believer and will continue to use Bro, but for management who will never directly interact with it, I need Bro to be meaningful to them. Whether that's Snort-like alerts, metrics, heuristic data, etc. I just went with alerts because it seemed like the easiest to get going straight away.

This is certainly where things get complicated because what management should be watching for is an engaged and vigilant incident response team. If that team has tools that cause them to be more engaged and more vigilant then that's great. Unfortunately most of the graphs that management will want to see won't actually reflect the reality of the activity for the incident responders and incident finders/hunters which most of the industry has split out from incident response at this point (which I still think is unfortunate).

I've been combing through github.com/trending/bro for some scripts that I can add. I've done as many training exercises as I can find, including the ones offered on bro.org as well as some from other sites, including ones that deal with logging like you mention https://www.bro.org/bro-workshop-2011/solutions/logs/


A fun one to load in case you haven't noticed it yet is the one that catalogs touches to Microsoft's Dr. Watson service. It will log hardware getting attached to system and process crashes among some other things.
  https://github.com/broala/bro-drwatson

Make sure you follow the directions and clone that repository recursively because there is another repository that it needs to pull in for hardware information.

So that's where I am. I will certainly continue working with the logs. In addition to that if you or anyone else have ideas on where I should be focusing my time for a new Bro install please let me know.

Great! Definitely let us know if you have questions. I know there are a lot of logs and it can take a long time to fully grok them all.

  .Seth