Next: , Previous: weird functions, Up: weird Module



7.24.4 Events handled by conn_weird

conn_weird (name: string, c: connection)
Invoked for most “weird” events. name is the name of the weird event, and c is the connection with which it's associated.

conn_weird handles the following events, all of which have a default action of WEIRD_FILE:

active_connection_reuse
A new connection attempt (initial SYN) was seen for an already-established connection that has not yet terminated.
bad_HTTP_reply
The first line of a reply from an HTTP server did not include HTTP/version.
bad_HTTP_version
The first line of a request from an HTTP client did not include HTTP/version.
bad_ICMP_checksum
The checksum field in an ICMP packet was invalid.
bad_rlogin_prolog
The beginning of an Rlogin connection had a syntactical error.
bad_RPC
A Remote Procedure Call was ill-formed.
bad_RPC_program
A portmapper RPC call did not include the correct portmapper program number.
bad_SYN_ack
A TCP SYN acknowledgment (SYN-ack) did not acknowledge the sequence number sent in the initial SYN.
bad_TCP_checksum
A TCP packet had a bad checksum.
bad_UDP_checksum
A UDP packet had a bad checksum.
baroque_SYN
A TCP SYN was seen with an unlikely combination of other flags (the URGent pointer).
blank_in_HTTP_request
The URL in an HTTP request includes an embedded blank.
connection_originator_SYN_ack
A TCP endpoint that originated a connection by sending a SYN followed this up by sending a SYN-ack.
data_after_reset
After a TCP endpoint sent a RST to terminate a connection, it sent some data.
data_before_established
Before the connection was fully established, a TCP endpoint sent some data.
excessive_RPC_len
An RPC record sent over a TCP connection exceeded 8 KB.
excess_RPC
The sender of an RPC request or reply included leftover data beyond what the RPC parameters or result value themselves consumed.
FIN_advanced_last_seq
A TCP endpoint retransmitted a FIN with a higher sequence number than previously.
FIN_after_reset
A TCP endpoint sent a FIN after sending a RST.
FIN_storm
The monitor saw a flurry of FIN packets all sent on the same connection. A “flurry” is defined as 1,000 packets that arrived with less than 1 sec between successive FINs. Deficiency: Clearly, this numbers should be user-controllable.
HTTP_unknown_method
The method in an HTTP request was not GET, POST or HEAD.
HTTP_version_mismatch
A persistent HTTP connection sent a different version number for a subsequent item than it did initially.
inappropriate_FIN
A TCP endpoint sent a FIN before the connection was fully established.
multiple_HTTP_request_elements
An HTTP request included multiple methods.
multiple_RPCs
A TCP RPC stream included more than one remote procedure call.
NUL_in_line
A NUL (ASCII 0) was seen in a text stream that is expected to be free of NULs. Updateme: Currently, the only such stream is that associated with an FTP control connection.
originator_RPC_reply
The originator (and hence presumed client) of an RPC connection sent an RPC reply (either instead of a request, or in addition to a request).
partial_finger_request
When a Finger connection terminated, it included a final line of unanalyzed text because the text was not newline-terminated.
partial_ftp_request
When an FTP connection terminated, it included a final line of unanalyzed text because the text was not newline-terminated.
partial_ident_request
When an IDENT connection terminated, it included a final line of unanalyzed text because the text was not newline-terminated.
partial_portmapper_request
A portmapper connection terminated with an unanalyzed request because the data stream was incomplete.
partial_RPC
An RPC was missing some required header information due to truncation.
pending_data_when_closed
A TCP connection closed even though not all of the data in it was analyzed due to a sequence hole.
possible_split_routing
Bro appears to be seeing only one direction of some bi-directional connections . This can also occur due to certain forms of stealth-scanning.
premature_connection_reuse
A TCP connection tuple is being reused less than 30 sec after its previous use. (The standard requires waiting 2 * MSL = 4 minutes [p. 27] [RFC-793].)
repeated_SYN_reply_wo_ack
A TCP responder that replied to an initial SYN with a SYN-ack has subsequently sent a SYN without an acknowledgment.
repeated_SYN_with_ack
A TCP originator that sent an initial SYN has subsequently sent a SYN-ack.
responder_RPC_call
The responder (and hence presumed server) of an RPC connection sent an RPC request (either instead of a reply, or in addition to a reply).
rlogin_text_after_rejected
An Rlogin client sent additional text to an Rlogin server after the server already presumably rejected the client's service request.
RPC_rexmit_inconsistency
An RPC call was retransmitted, and the retransmitted call differed from the original call. This could reflect an attempt by an attacker to evade the monitor. Note: This type of inconsistency checking is not available for RPC replies because the transmission of the reply in general marks the end of the RPC connection, and the monitor deletes the connection state shortly afterward.
RST_storm
The monitor saw a flurry of RST packets all sent on the same connection. See FIN_storm for the definition of “flurry.”
RST_with_data
A TCP RST packet included data. This actually is allowed by the specification [4.2.2.12] RFC-1122. Deficiency: This event should include the data.
simultaneous_open
The monitor saw a TCP simultaneous open, i.e., both endpoints sent initial SYNs to one another at the same time. While the specification allows this [p. 30] RFC-793, none of the protocols analyzed by Bro should be using it.
spontaneous_FIN
A TCP endpoint sent a FIN packet without sending any previous packets. This event can reflect stealth-scanning, but can also occur when Bro has recently started up and has not seen other traffic on a connection and hence does not know that the connection already exists.
spontaneous_RST
A TCP endpoint sent a RST packet without sending any previous packets. As with spontaneous_FIN, this event can reflect either stealth scanning or a Bro start-up transient.
SYN_after_close
A TCP endpoint sent a SYN (connection initiation) after sending a FIN (connection termination), but before the connection fully closed.
SYN_after_partial
A TCP endpoint in a “partial” connection sent a SYN.
SYN_after_reset
A TCP endpoint sent a SYN after sending a RST (reset connection).
SYN_inside_connection
A TCP endpoint sent a SYN during a connection (or partial connection) on which it had already sent data.
SYN_seq_jump
A TCP endpoint retransmitted a SYN or a SYN-ack, but with a different sequence number.
SYN_with_data
A TCP endpoint included data in a SYN packet it sent. Note, this can legitimately occur for T/TCP connections [RFC-1644].
TCP_christmas
A TCP endpoint sent a SYN packet that included the RST flag (a nonsensical combination). The term “Christmas packet” has been used in this context (particularly if other flags are set, too) because the packet's flags are “lit up like a Christmas tree.”
UDP_datagram_length_mismatch
The length field in a UDP header did not match the length field in the IP header. This could reflect an attempt by an attacker to evade the monitor.
unpaired_RPC_response
An RPC reply was seen for which no request was seen. This event could reflect a Bro start-up transient (it started running after the request was sent).
unsolicited_SYN_response
A TCP endpoint sent a SYN-ack without first receiving an initial SYN. This event could reflect a Bro start-up transient.