Check out the new USENIX Web site. next up previous
Next: FTP Up: Application-specific processing Previous: Application-specific processing

Finger

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.



next up previous
Next: FTP Up: Application-specific processing Previous: Application-specific processing

Vern Paxson
Sat Dec 6 01:53:24 PST 1997