The first of the applications is the Finger ``User Information'' service [Zi91]. Structurally, Finger is very simple: the connection originator sends a single line, terminated by a carriage-return line-feed, specifying the user for which they request information. An optional flag requests ``full'' (verbose) output. The responder returns whatever information it deems appropriate in multiple lines of text, after which it closes the connection.
Bro generates a finger_request event whenever it monitors a complete Finger request. A handler for this event looks like:
event finger_request(c: connection,
user: string, full: bool)
Our site's policy for Finger requests includes testing for possible
buffer-overflow attacks and checking the user against a list of sensitive
user ID's, such as privileged accounts. See Appendix A
for a discussion of how the Finger analysis is integrated into Bro.
Bro currently does not generate an analogous finger_reply event. Two reasons for this are (1) we view the primary threat of Finger to come from the originator and not the responder, so adding finger_reply has had a lower priority, and (2) manipulating multi-line strings in Bro is clumsy at present, because Bro does not have an iteration operator for easily moving through a table[count] of string.
A final note: if the event engine finds that the policy script does not define a finger_request handler, then it does not bother creating Finger-specific analyzers for new Finger connections. In general, the event engine tries to determine as early as possible whether the user has defined a particular handler, and, if not, avoids undertaking the work associated with generating the corresponding event.