> 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?
The notion of "service" is "what is the actual service [application] running
on the connection". It initially arose from the utility of associating
"ftp-data" with connections that otherwise might not be identified as such,
since they didn't use well-known ports.
Bro is moving towards more fully decoupling the notion of what application
protocol to analyze vs. what application is usually associated with a given
well-known port, so I think the split of service in the connection logs
will be helpful in this regard.
I confess (and probably reveal) my near total BRO ignorance, but isn't
service just mapped from port number in some (many?) cases?
In most cases, yes, but not in all.
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.
Hmmmm, perhaps this should be a new flag (to go along with 'L', and
the soon-to-depart 'U'), but I'm not sure it's worth it - do you have
an example in which this is particularly handy to have?
PS. any consideration of making the log format a config spec:
red_log_format: "%time %duration %service %oip %rip %bytes %rbytes ...."
maybe little value... just a thought.
I think a better way to do this is to make it easy for the user to supply
their own connection log printer directly.
Vern