Next: , Previous: weird functions, Up: weird Analysis Script


7.27.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.