Next: , Previous: Definitions of connections, Up: Generic Connection Analysis



7.3.3 Generic TCP connection events

There are a number of generic events associated with TCP connections, all of which have a single connection record as their argument:

new_connection
Generated whenever state for a new (TCP) connection is instantiated.

Note: Handling this event is potentially expensive. For example, during a SYN flooding attack, every spoofed SYN packet will lead to a new new_connection event.


connection_established
Generated when a connection has become established, i.e., both participating endpoints have agreed to open the connection.


connection_attempt
Generated when the originator (client) has unsuccessfully attempted to establish a connection. “Unsuccessful” is defined as at least ATTEMPT_INTERVAL seconds having elapsed since the client first sent a connection establishment packet to the responder (server), where ATTEMPT_INTERVAL is an internal Bro variable which is presently set to 300 seconds. Deficiency:This variable should be user-settable. If you want to immediately detect that a client is attempting to connect to a server, regardless of whether it may soon succeed, then you want to handle the new_connection event instead.

Note: Handling this event is potentially expensive. For example, during a SYN flooding attack, every spoofed SYN packet will lead to a new connection_attempt event, albeit delayed by ATTEMPT_INTERVAL.


partial_connection
Generated when both connection endpoints enter the TCP_PARTIAL state This means that we have seen traffic generated by each endpoint, but the activity did not begin with the usual connection establishment. Deficiency:For completeness, Bro's event engine should generate another form of partial_connection event when a single endpoint becomes active (see new_connection below). This hasn't been implemented because our experience is network traffic often contains a great deal of “crud”, which would lead to a large number of these really-partial events. However, by not providing the event handler, we miss an opportunity to detect certain forms of stealth scans until they begin to elicit some form of reply.

State Meaning
TCP_INACTIVE The endpoint has not sent any traffic.
TCP_SYN_SENT It has sent a SYN to initiated a connection.
TCP_SYN_ACK_SENT It has sent a SYN ACK to respond to a connection request.
TCP_PARTIAL The endpoint has been active, but we did not see the beginning of the connection.
TCP_ESTABLISHED The two endpoints have established a connection.
TCP_CLOSED The endpoint has sent a FIN in order to close its end of the connection.
TCP_RESET The endpoint has sent a RST to abruptly terminate the connection.
UDP_INACTIVE The endpoint has not sent any traffic.
UDP_ACTIVE The endpoint has sent some traffic.

Table 7.1: TCP and UDP connection states, as stored in an endpoint record



connection_finished
Generated when a connection has gracefully closed.


connection_rejected
Generated when a server rejects a connection attempt by a client.

Note: This event is only generated as the client attempts to establish a connection. If the server instead accepts the connection and then later aborts it, a connection_reset event is generated (see below). This can happen, for example, due to use of TCP Wrappers.

Note: Per the discussion above, a client attempting to connect to a server will result in one of connection_attempt, connection_established, or connection_rejected; they are mutually exclusive.


connection_half_finished
Generated when Bro sees one endpoint of a connection attempt to gracefully close the connection, but the other endpoint is in the TCP_INACTIVE state. This can happen due to split routing, in which Bro only sees one side of a connection.


connection_reset
Generated when one endpoint of an established connection terminates the connection abruptly by sending a TCP RST packet.


connection_partial_close
Generated when a previously inactive endpoint attempts to close a connection via a normal FIN handshake or an abort RST sequence. When it sends one of these packets, Bro waits PARTIAL_CLOSE_INTERVAL (an internal Bro variable set to 10 seconds) prior to generating the event, to give the other endpoint a chance to close the connection normally.


connection_pending
Generated for each still-open connection when Bro terminates.