[Bro] linking a wrong_fragment event to a connection
vern at icir.org
Thu Mar 18 10:46:33 PDT 2010
> Thanks for your kindly answer about fragment. So maybe I should focus on
> bad_TCP_checksum / bad_UDP_checksum and bad_icmp_checksum instead
> of excessively_large_fragment, excessively_small_fragment,
> etc..)? In that case, I will have the header with the information I need.
Yes, those all have some sort of flow information associated with them.
(Though I would skip bad_icmp_checksum, as for ICMPs the flow is a somewhat
> BTW, in the case of BRO processed KDDCup 99 data
Side note: I hope you're only looking at that data get a handle on using
Bro or such. Using it for research is a well-known pitfall; see
> when BRO encounters a flow mid-stream and that flow get shut down BRO uses
> SF label. You mentioned plans for adding Bro state tracking to solve it.
> What is the situation at the moment?
It's available, see the discussion "If you set the new control variable
record_state_history to T" in the CHANGES file.
> The paper I am talking about defines the timeouts that could affect the
> probability to split a flow during its lifetime:
> active timeout is full length of TCP connection passive timeout refers to
> idle times in active flows where no packet is transfer (it is called also
> the maximum packet gap).
Bro does the latter, since it needs to make the decision in real-time.
More information about the Bro