[Bro] TCP normalization and reassembly decision

Shuai Hao haoscs at gmail.com
Mon Nov 13 21:10:35 PST 2017


Thanks for your sharing the example code, Christian!

It also explains that at least the rule 3 in Vern's paper cannot be
implemented since it has to be operated in in-line mode. But how the first
two rules?

For rule 1 (limit the buffer of per-connection), is the rule implemented in
current Bro and does the 100KB buffer of per-connection hold?

For rule 2 (randomly evict connections), given we typically have
capture_loss and dropped_packets which reflect Bro's behavior, is there any
rule on the connection-level when Bro evicts connections?

Thanks,

On Mon, Nov 13, 2017 at 8:44 PM, Christian Kreibich <christian at corelight.com
> wrote:

> Hi Shuai,
>
> On 11/13/2017 02:30 PM, Shuai Hao wrote:
>
>> In /src/analyzer/protocol/tcp/tcp.cc, I find a comment "we could be
>> fooled
>> by an inconsistent SYN retransmission. Where is a normalizer". So I assume
>> Bro doesn't come with a TCP normalizer. What is the consideration for such
>> decision? It will be not necessary, or it will be implemented in future?
>>
>
> A TCP normalizer, in the sense referred to here, is a middlebox that
> removes ambiguities in the traffic by actually modifying the packet flow
> and payloads in-path, to simplify the job of subsequent network monitors.
> So in order to implement this Bro would need to support in-path deployment,
> which isn't a priority for us.
>
> There's old (entirely unsupported) code for such a normalizer available
> here, if you'd like to experiment:
>
> http://icir.org/christian/downloads/norm-0.2.0.tar.gz
>
> There are also commercial products in this space that support varying
> extents of traffic normalization.
>
> Best,
> -C.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20171114/b4950deb/attachment.html 


More information about the Bro mailing list