Hi, Ian.
So, lets say that I have tcp ports 587 and 993 exposed on my firewall. I have bro running as a cluster on all interfaces. I see logs about well known SSL/HTTP/HTTPS ports but no anomalies in the hourly summaries. No alerts in email either (that I have seen). Now I do need to cruise through all the rotated compressed logs to check and see if something was recorded.
Are you referring to the connection summary e-mails? Notices are not reported there.
I think there's some difference in terminology. In Bro-land, scripts can generate notices. These vary in severity from informative (e.g. an MD5 hash was calculated for a file downloaded over HTTP) to critical (e.g. Bro just saw a social security number cross the wire in plaintext). Notices that are deemed particularly important are associated with the alarm action, which sends them to the alarm file.
You can customize what actions should be taken when a notice is generated. By default, though, notices just get logged to notice.log in your log directory (usually /usr/local/bro/logs). Similarly, connections get logged to conn.log, SMTP messages get logged to smtp.log, etc. If you'd like to be e-mailed when a particular notice occurs, you can redefine Notice::emailed_types in your local.bro (usually at: /usr/local/bro/share/bro/site/local.bro).
For example:
redef Notice::emailed_types += {
SSH::Password_Guessing,
};
The second thing I am wondering about is that there are no references to interfaces where the traffic was seen. For example, I have no IPv6 but I see unknown IPv6 traffic in the summary. Tools like:
http://isc.sans.edu/tools/ipv6.html#form
can be used to attempt to glean the MAC address to some degree. But I cannot quickly tell which interface the packet came on to help decide where the threat lies between internal/dmz/external networks. I can make some really good guesses but it might be nice to spell it it in the logs.
This is a fairly non-standard setup. The more common setup that I'm aware of is running Bro at a single network boundary - generally at the border. That being said, what you could do is setup your workers so that each set monitors a type of interface (e.g. worker-dmz-01, worker-internal-01…worker-internal-03, etc.). One thing to keep in mind is that you'll see packets multiple times.
Ok, I did a little looking into the 993 reporting. Turns out there is something that shows up in the known.certs for the day but nothing else. I think I need to be patient and do some remote testing from an external source to verify that alarms are indeed working. Also, I did some looking for 587 and got nothing. No connections, no state, no certs - nothing.
I'm not really sure what you're expecting to see if you just monitor 993 and 587. You won't see more than connections and SSL certificate information. What alarms are you expecting to receive?
P.S. the IPv6 issue stands - still cannot quickly tell where the state if the TCP connection lies without SNORT for example….
Have you looked in conn.log? You should be able to see information for both sides of the v6 connection, and that should at least tell you if you're dealing with link-local, expected v6 space on your network, or something else.
Hope that helps,
--Vlad