Node: Events handled by flow_weird, Next: , Previous: Events handled by conn_weird_addl, Up: weird Module



Events handled by flow_weird

flow_weird (name: string, src: addr, dst: addr)
is invoked for "weird" events that cannot be associated with a particular connection, but only with a pair of hosts, corresponding to a flow of packets from src to dst. Presently, all of these events deal with fragments.

flow_weird handles the following events:

excessively_large_fragment
A set of IP fragments reassembled to a maximum size exceeding 64,000 bytes. Note: Sizes between 64,000 and 65,535 bytes are allowed, strictly speaking, but are highly unlikely in legitimate traffic. Sizes above 65,535 bytes generally represent attempted denial-of-service attacks, due to IP implementations that crash upon receiving such impossibly-large fragment sets.

Default: WEIRD_LOG_ALWAYS.

excessively_small_fragment
A fragment other than the last fragment in a set was less than 64 bytes in size. Note: The standard allows such small fragments, but their presence may reflect an attacker attempting to evade the monitor by splitting header information across multiple fragments.

Default: WEIRD_LOG_ALWAYS.

fragment_inconsistency
A fragment overlaps with a previously sent fragment, and the two disagree on data they share in common. This event could reflect an attacker attempting to evade the monitor; it can also occur because Bro keeps previous fragments indefinitely (Deficiency: it needs to provide a means for flushing old fragments, otherwise it becomes vulnerable to a state-holding attack), and occasionally a fragment will overlap with one sent much earlier and long-since forgotten by the endpoints.

Default: WEIRD_LOG_ALWAYS.

fragment_overlap
A fragment overlaps with a previously sent fragment. As for fragment_inconsistency, this event can occur due to Bro keeping previous fragments indefinitely. This event does not in general reflect a possible attempt at evasion.

Default: WEIRD_LOG_ALWAYS.

fragment_protocol_inconsistency
Two fragments were seen for the same flow and IP ID which differed in their transport protocol (e.g., UDP, TCP). According to the specification, this is allowed [p. 24]RFC791, but its use appears highly unlikely.

Default: WEIRD_FILE, because it is difficult to see how an attacker can exploit this anomaly.

fragment_size_inconsistency
A "last fragment" was seen twice, and the two disagree on how large the reassembled datagram should be. This event could reflect an attacker attempting to evade the monitor.

Default: WEIRD_FILE, since it is more likely that this occurs due to a high volume flow of fragments wrapping the IP ID space than due to an actual attack.

fragment_with_DF
A fragment was seen with the "Don't Fragment" bit set in its header. While strictly speaking this is not illegal, and not impossible (a router could have fragmented a packet and then decided that the fragments should not be further fragmented), its presence is highly unusual.

Default: WEIRD_FILE, because it's difficult to see how this could reflect malicious activity.

incompletely_captured_fragment
A fragment was seen whose length field is larger than the fragment datagram appearing on the monitored link.

Default: WEIRD_LOG_ALWAYS.