[Bro] Bro bug?
hlein at korelogic.com
Sun Jan 19 10:38:40 PST 2014
On Sun, Jan 19, 2014 at 12:46:31PM -0500, Justin Azoff wrote:
> On Sun, Jan 19, 2014 at 05:22:10PM +0000, Kellogg, Brian D (OLN) wrote:
> > 1390143300.845103 Cma6473thsxripFj9k 220.127.116.11 3326 18.104.22.168 80 tcp - 0.092641 1056737769 0 RSTOS0 T 0 SaR 2 88 1 40 (empty) - US so-eth0
> So, with the field names, that is:
> duration 0.092641
> orig_bytes 1056737769
> resp_bytes 0
> conn_state RSTOS0
> local_orig T
> missed_bytes 0
> history SaR
> Which shows that bro calculated that there were 1056737769 bytes based
> on sequence numbers, but only actually saw 88 bytes.
> I think simply changing $size to $num_bytes_ip will fix your problems.
That's probably a decent workaround.
Another option would be to only trigger on connections that were fully
established - with conn_state of SF (possibly also RST0 and RSTR) - as
those should have the "most reliable" byte counts.
I think the problem in Brian's case comes from this not being a normally
established / torn down connection. conn_state RSTOS0 implies Bro saw
an incomplete connection attempt be torn down by an RST (by the orignal
sender, which is odd, and history SaR means the receiver sent not a
SYNACK, and not nothing, but a bare ACK, which is odder still... but
that is a story for another day*).
It could be argued that Bro should "know" that for certain failed /
incomplete connection types, ACK/SEQ math can be unreliable (maybe it
already does for some), and that SaR is a candidate for that (maybe that
has already been argued; there's probably good cases to be made both
[ *Snip esoteric ramble about the 4 way handshake, etc. ]
Hank Leininger <hlein at korelogic.com>
D24D 2C2A F3AC B9AE CD03 B506 2D57 32E1 686B 6DB3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 447 bytes
Desc: Digital signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20140119/42a2296c/attachment.bin
More information about the Bro