7.4.1 The connection record

     type 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

The IP address of the host that originated (initiated) the connection. In “client/server” terminology, this is the “client.”

orig_p

The TCP or UDP port used by the connection originator (client). For ICMP “connections”, it is set to 0 icmp Analyzer.

resp_h

The IP address of the host that responded (received) the connection. In “client/server” terminology, this is the “server.”

resp_p

The TCP or UDP port used by the connection responder (server). For ICMP “connections”, it is set to 0 icmp Analyzer.

The orig and resp fields of a connection record both hold endpoint record values, which consist of the following fields:

size

How many bytes the given endpoint has transmitted so far. Note that for some types of filtering, the size will be zero until the connection terminates, because the nature of the filtering is to discard the connection's intermediary packets and only capture its start/stop packets.

state

The current state the endpoint is in with respect to the connection. The table below defines the different possible states for TCP and UDP connections. Deficiency:The states are currently defined as 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

The time at which the first packet associated with this connection was seen.

duration

How long the connection lasted, or, if it is still active, how long since it began.

service

The name of the service associated with the connection. For example, if $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

Additional information associated with the connection. For example, for a login connection, this is the username associated with the login.

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

How many times this connection has been marked as potentially sensitive or reflecting a break-in. The default value of 0 means that so far the connection has not been regarded as “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).