[Bro] Help with searching logs
scastle at bouldercounty.org
Thu Apr 4 07:51:02 PDT 2013
So, this was not included in 2.1? I'm thinking "git clone --recursive git://git.bro.org/bro.git" will get me a new copy that includes this, right?
Data Security Mgr, Boulder County IT
From: Seth Hall [mailto:seth at icir.org]
Sent: Wednesday, April 03, 2013 19:23
To: Castle, Shane
Cc: 'Michael Bower'; 'Bro Mailing List'
Subject: Re: [Bro] Help with searching logs
On Apr 3, 2013, at 4:47 PM, "Castle, Shane" <scastle at bouldercounty.org> wrote:
> Looks like resp_bytes is not being properly shown sometimes. Hmm, missed_bytes seems to be large here, too. Sigh - I still don't know what's going on. If missed_bytes is nonzero, the orig and resp bytes can't be trusted. More work and research.
> Here's the unfiltered output:
> scastle at nsm:~/scripts$ zcat /nsm/bro/logs/2013-04-03/conn.19:00:00-20:00:00.log.gz | bro-cut -d | grep 192.168.56.166.\*126.96.36.199
> 2013-04-03T19:21:51+0000 ramah8M2Oc1 192.168.56.166 64888 188.8.131.52 80 tcp - 24.008354 0 1214734460 RSTR T 0 hArR 2 92 3 160 (empty)
This is what I get for not reading the whole email. Bro has/had an issue with middle boxes sending RST packets to kill TCP connections (great firewall of China being a primary offender) where it would use the sequence number from the RST packet instead of the sequence number from the initial syn or syn-ack. It resulted in these connections like you have here with very few packets and huge data sizes. It's fixed in master and if you want more context to the problem you can refer to the ticket where we tracked the issue and fix:
International Computer Science Institute
(Bro) because everyone has a network
More information about the Bro