[Bro] Help with searching logs

[Castle, Shane]

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?

-- 
Shane Castle
Data Security Mgr, Boulder County IT


-----Original Message-----
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.\*23.7.65.224
> 2013-04-03T19:21:51+0000        ramah8M2Oc1     192.168.56.166  64888   23.7.65.224     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:
	http://tracker.bro.org/bro/ticket/730

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro.org/