linking a wrong_fragment event to a connection

Hello everyone,

I ask this topic again trying to clarify my questions (and my English). I want to associate a summary of wrong fragments to the corresponding line in the connection summary.

I made a script to count the different fragment problems trigger by flow_weird event.

How can I know which connection has generated that wrong fragment event? The wrong fragment event only logs src, dst and network_time. This is not enough to link the fragment to a connection inside connection summary.

1247652196.907274 src_ip → dst_ip: fragment_with_DF

By the way, I read about active and passive timeouts on connections (“Flow-based TCP Connection Analysis” by Limmer and Dressler).
I don´t understand how this topic is treated in BRO. I found only one type of timeout (TCP_inactivity_timeout). Is this timeout the active timeout? Can I tune a passive timeout? Maybe I am missing others user tunable timeouts that can affect my results.

Maybe I am getting into the details of bro design, I want to understand what I am doing, and what I shouldn´t do to get the wrong fragment count inside the conn.bro file.

Veronica Estrada
Nakao Laboratory
The University of Tokyo

How can I know which connection has generated that wrong fragment event?

In general you can't. Most individual fragments do not possess transport
headers, so there is no well-defined connection associated with them.
*If* the fragment is part of a whole collection, then you can locate the
transport header at the beginning of the collection and use its ports -
but Bro may not have even seen this first part yet. So it only reports
the involved hosts. (It also could in principle report ports if the
problematic fragment happens to be the first *and* includes a full transport
header [which it doesn't have to], but Bro doesn't go out of its way to
do the extra work in this case.)

By the way, I read about active and passive timeouts on connections
("Flow-based TCP Connection Analysis" by Limmer and Dressler).
I don't understand how this topic is treated in BRO.

You'll need to explain how those timeouts are defined in that paper for
others to be able to comment on how Bro's connection timeouts relate to them.

    Vern

What is the correct way to tell bro to ignore any traffic between two machines? If I have World, Machine1, and Machine2, then I want to monitor:

     World <-> Machine1
     World <-> Machine2

but not Machine1 <-> Machine2. Thanks.

Mat

redef restrict_filters += {
  ["ignore_machine1_to_machine2"] = "not (host 1.2.3.4 and host 1.2.3.5)"
};

Don't do that inside of an event handler or function definition.

   .Seth

Thanks Seth. A slightly different question: how do I ignore traffic between hosts in a particular subnet? I want to ignore all chatter between machines in my cluster, and simply examine traffic between the cluster and the world.

Mat

I would do something similar to the earlier filter...

redef restrict_filters += {
  ["ignore_internal"] = "not (src net 1.2.3.0/24 and dst net 1.2.3.0/24)"
};

  .Seth

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, fragment_inconsistency, fragment_overlap,fragment_protocol_inconsistency etc…)? In that case, I will have the header with the information I need.

BTW, in the case of BRO processed KDDCup 99 data, all the wrong fragments belong to SF labeled UDP/ICMP connections (for UDP connections wrong fragment count is 3 and the others 1). I thought SF is printed for completely flows but I read in an old message of this list (nov 2004) that 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?

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

Thank you in advance for any help you can provide.
Veronica

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,
fragment_inconsistency,
fragment_overlap,fragment_protocol_inconsistency
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
vague notion.)

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
http://www.icir.org/vern/talks/vp-IDS-Pitfalls-DIMVA07.pdf .

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.

    Vern