[Bro] Something is not clear to me concerning reporting

[ian]

On 2012-10-17 18:40, Vlad Grigorescu wrote:
> Hi, Ian.

<snip just to reduce the size>

> 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,
> };
>

Thanks, I will look into that.  I think the non-standard cluster 
configuration I have running (one worker per interface with distinct 
names) seems to be working for my dmz/internet works.  I really need to 
sit down and review the all the logs for the specific worker associated 
with my external interface and see what is there.  That will be 
tonight’s job.  I may have to do as you suggest and look into the 
scripts.  I have only been running bro for a couple of days now to get 
familiar with it.

>>> 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?

To be fair – it was late for me.  I just did a quick unpacking of the 
logs and grep’ed.

Well, what I am really trying to do is log all connections to 
particular ports on a particular interface which I deem is of critical 
importance.  This might be a scripting lesson for me to tackle (assuming 
the connections are not currently being recorded for whatever reason) or 
alarm modification.  I can also depend on pf to keep doing this – it 
probably makes more sense just to keep pf doing this as it does 
currently for me.  I was just concerned (confused) because the summary 
is listing connections to/from the internal/dmz networks for DNS, OSSEC, 
standard proxy/WWW ports but not for the external interface (or so it 
seems) and I wondered why.  I should say that I am seeing incoming 
connection reports for HTTP/HTTPS in the summary – just not the rest.


>
>> 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.

I will.

Thanks,

Ian