new bro "CURRENT" release - 0.8a57

Vern Paxson vern at
Tue Dec 16 09:21:11 PST 2003

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


More information about the Bro mailing list