sorry,there’re something wrong with my mailer this morning.
Thank you for your answer
How does bro be aware of the close of ftp data connection if she can’t capture the corresponding tcp session packet? via the interactive info appeared in the ftp control connection?
And ，To dynamically capture some certain traffic without including all packet, it feels feasible to create a new thread/process to run another bro to capture and analyze，but is this process so long as to miss some packets in that certain session?
So how does it dynamically add the filter string to capture the
temporary traffic?
It doesn’t. Dynamically changing the BPF filter is too expensive as
it would need to be recompiled every time (and the filter would
quickly get huge).
If you want Bro to analyze the content of ftp-data sessions, you
need to manually override the pcap filter to include all packets,
e.g., by running with “-f tcp”.
How does bro be aware of the close of ftp data connection if she can't
capture the corresponding tcp session packet?
By default Bro captures *all* TCP control packets (SYNs/FINs/RSTs)
and will therefore know about the ftp-data connection. However, it
does not capture any payload packets of the data connection.
And ??To dynamically capture some certain traffic without including all
packet, it feels feasible to create a new thread/process to run another bro
to capture and analyze
The second Bro still would have the same problem that it needs to
adapt its filter on the fly. And yes, the latency of the
communication would quite likely lead to missed packets.
But we are working on another solution to the problem: we're in the
process of interfacing Bro with our time machine[1]. Bro will be
able to query the TM for the ftp-data connection once is has parsed
the control sessions.