Next: Definitions of connections, Previous: Generic Connection Analysis, Up: Generic Connection Analysis
connection
recordtype conn_id: record { orig_h: addr; # Address of originating host. orig_p: port; # Port used by originator. resp_h: addr; # Address of responding host. resp_p: port; # Port used by responder. }; type endpoint: record { size: count; # Bytes sent by this endpoint so far. state: count; # The endpoint's current state. }; type connection: record { id: conn_id; # Originator/responder addresses/ports. orig: endpoint; # Endpoint info for originator. resp: endpoint; # Endpoint info for responder. start_time: time; # When the connection began. duration: interval; # How long it was active (or has been so far). service: string; # The service we associate with it (e.g., "http"). addl: string; # Additional information associated with it. hot: count; # How many times we've marked it as sensitive. };
A connection record record holds the state associated with a connection, as shown in the example above. Its first field, id, is defined in terms of the conn_id record, which has the following fields:
orig_h
orig_p
resp_h
resp_p
The orig
and resp
fields of a connection
record both hold endpoint
record values, which consist
of the following fields:
size
state
count
, but should instead be an enumerated type; but Bro does not yet support enumerated types.
Note: UDP “connections” do not have a well-defined structure, so the states for them are quite simplistic. See Definitions of connections for further discussion.
The remaining fields in a connection
record are:
start_time
duration
service
$id$resp_p
is tcp/80
, then the service will be
"http"
. Usually, this mapping is provided by the global variable, perhaps via the endpoint_id
function; but
the service does not always directly correspond to
$id$resp_p
, which is why it's a separate field. In particular,
an FTP data connection can have a service
of "ftp-data"
even though its $id$resp_p
is something other than tcp/20
(which is not consistently used by FTP servers).
If the name of the service has not yet been determined, then this field is set to an empty string.
addl
Deficiency: A significant deficiency associated with the addl
field is that it is simply a string
without any further structure. In practice, this has proven too restrictive. For example, we may well want to associate an unambiguous username with a login session, and also keep track of the names associated with failed login attempts. (See the login
analyzer for an example of how this is implemented presently.) What's needed is a notion of union
types which can then take on a variety of values in a type-safe manner.
If no additional information is yet associated with this connection, then this field is set to an empty string.
hot
Note: Bro does not presently make fine-grained use of this field; the
standard scripts log connections with a non-zero hot
field,
and do not in general log those that do not, though there are exceptions.
In particular, the hot
field is not rigorously maintained
as an indicator of trouble; it instead is used loosely as an indicator
of particular types of trouble (access to sensitive hosts or usernames).