Previous: Events generated by the standard scripts, Up: weird Module



7.24.9 Additional handlers for “weird” events

In addition to the above, generalized events, Bro includes two specific events that are defined by themselves so they can include additional parameterization:

rexmit_inconsistency (c: connection, t1: string, t2: string)
Invoked when a retransmission associated with connection c differed in its data from the contents transmitted previously. t1 gives the original data and t2 the different retransmitted data.

This event may reflect an attacker attempting to evade the monitor. Unfortunately, however, experience has shown that (i) inconsistent retransmissions do in fact happen due to (appalling) TCP implementation bugs, and (ii) once they occur, they tend to cascade, because often the source of the bug is that the two endpoints have become desynchronized.

The handler logs the message in the format "id rexmit inconsistency (<t1>) (<t2>)" . However, the handler only logs the first instance of an inconsistency, due to the cascade problem mentioned above.

Deficiency: The handler is not told which of the two connection endpoints was the faulty transmitter.


ack_above_hole (c: connection, t1: string, t2: string)
Invoked when Bro sees a TCP receiver acknowledge data above a sequence hole. In principle, this should never occur. Its presence generally means one of two things: (i) a TCP implementation with an appalling bug (these definitely exist), or (ii) a packet drop by Bro's packet capture facility, such that it never saw the data now being acknowledged.

Because of the seriousness of this latter possibility, the handler logs a message ack above a hole. Note: You can often distinguish between a truly broken TCP acknowledgment and Bro dropping packets by the fact that in the latter case you generally see a cluster of ack-above-a-hole messages among otherwise unrelated connections.

Deficiency: The handler is not told which of the two connection endpoints sent the acknowledgment.