There are a number of generic events associated with TCP connections,
all of which have a single connection
record as their argument:
new_connection
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
connection_attempt
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
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
connection_rejected
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
TCP_INACTIVE
state. This can happen due to split routing,
in which Bro only sees one side of a connection.
connection_reset
connection_partial_close
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