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