The changes notes above don't mention the <addl> field. Is that just
an oversight in the notes,
Yes, just an oversight in the notes.
Will <service> still contain port numbers? Or will "other-nnnnn" become
simply "other"? (that would be my preference)
Good point. As implemented, it continues to be other-nnnnn, but I think
just plain "other" makes more sense, since we now can finally cleanly separate
the notion of service from the notion of port.
Although I don't know what the "neighbor net" U flag even means, I wonder
if this is the time to drop that, as the BRO manual says the whole notion
is historical.
The notion of "neighbor" is still used a bit in the policy scripts
(in scan.bro, in particular - different rules apply to scan detection
for activity from neighbors than from others), but arguably this should
be structured in a different fashion (a general notion of networks that
are allowed to scan), and in fact this has bitten us operationally in
the past, when a infected neighbor scanned us.
Will <service> still contain port numbers? Or will "other-nnnnn" become
simply "other"? (that would be my preference)
Good point. As implemented, it continues to be other-nnnnn, but I think
just plain "other" makes more sense, since we now can finally cleanly separate
the notion of service from the notion of port.
It's cleaner, but is it really separated internally, or just in the logs?
I confess (and probably reveal) my near total BRO ignorance, but isn't
service just mapped from port number in some (many?) cases? Even if
so, the separation is valuable and clearly necessary where not so,
but I wonder if it wouldn't be useful to have some indication of those
connections that BRO has determined the service of (via inspection)
versus merely inferring the service from a port:name lookup table.
Put another way (my interest), it's my impression that sometimes the
service field contains additional information and sometimes it doesn't.
Is that correct? If so, would indicating this in the log be worthwhile?
Mark
PS. any consideration of making the log format a config spec: