[Bro-Dev] $history extensions - zero windows, logarithmic counts

Vlad Grigorescu vlad at es.net
Fri Jun 15 15:16:21 PDT 2018

On Fri, Jun 15, 2018 at 9:54 PM, Vern Paxson <vern at corelight.com> wrote:

> > it unclear on the logarithmic
> > counts. Take, for instance SaDtTtT. If I'm reading this correctly, I
> think
> > that means 10-99 retransmissions from orig, followed by 10-99 from resp,
> > then more retransmissions from orig (enough to reach a total of 100-999),
> > and similarly more from resp.
> Correct in principle.  (1) These would be 1-9 followed by enough to
> get to 10-99, since a single retransmission is already a 't' / 'T', and
> (2) lower letters are responders rther than originators.

Ah, right. Thanks for clearing that up.

> > Maybe we add the
> > new letters, but don't repeat them and also add new fields for exact
> > bytecounts?
> I'm not following this.  If we add new letters that don't repeat *and* we
> add new fields, why do we need the letters given that the fields are there?

My thought for this was simply if it mattered *where* in the state history
the trouble occurred. For instance, if I'm seeing retransmissions at the
very end of a connection, that might indicate that one side abruptly
terminated the connection (I'd see this with things like fail2ban inserting
an iptables rule to block a brute-forcer). Similarly, if I see a zero
window at the start of a connection, that would tell me that the buffer was
full due to another connection or connections, as opposed to filling up due
the connection I'm looking at.

I'm having a tough time thinking up additional use-cases without having
some sample data, so perhaps the best course is to add what you proposed,
and then revisit it if we feel like anything's missing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20180615/6cac959d/attachment.html 

More information about the bro-dev mailing list