Re: [Bro-Dev] timer delays between different events for same connection

2018-04-13 Thread Aashish Sharma
Ah! it is obvious now! 

Yep that was it. Its a relatively slow scan and I only extracted all activity
for this specific source IP out of timemachine. 

I didn't see this behavior in other test cases because there I pull scanners
based on ports so somewhat of more 'fluid' traffic. 

Thanks, 
Aashish 

On Fri, Apr 13, 2018 at 07:46:33AM -0400, Seth Hall wrote:
> 
> 
> On 13 Apr 2018, at 0:30, Aashish Sharma wrote:
> 
> > So I am seeing some weird stuff in my sample pcap of scanners. May be
> > too
> > obvious and I am just not seeing why/how of it.
> 
> It's a straight forward answer but not completely obvious. :)
> 
> > Q. Why would connection_attempt event kick in after 36 minutes and 6
> > seconds ? (
> > 06:13:48 - 05:37:42 ) ?
> 
> I bet that you have a jump in timestamps in your pcap.  Since Bro's internal
> clock is driven forward by seeing timestamps associated with packets it's
> possible that your pcap has a 36 minute jump in timestamps so Bro couldn't
> have possibly expired anything in the time before that because from its
> perspective there was an immediate jump in time.  You don't normally
> experience the effects of this behavior in traffic you're sniffing live
> because you will tend to have many packets every second so you see Bro's
> clock driven forward in very tiny increments as you would expect.  If you go
> a long time without receiving a packet is when stuff gets tricky.
> 
>   .Seth
> 
> --
> Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev


Re: [Bro-Dev] timer delays between different events for same connection

2018-04-13 Thread Seth Hall


On 13 Apr 2018, at 0:30, Aashish Sharma wrote:

> So I am seeing some weird stuff in my sample pcap of scanners. May be 
> too
> obvious and I am just not seeing why/how of it.

It's a straight forward answer but not completely obvious. :)

> Q. Why would connection_attempt event kick in after 36 minutes and 6 
> seconds ? (
> 06:13:48 - 05:37:42 ) ?

I bet that you have a jump in timestamps in your pcap.  Since Bro's 
internal clock is driven forward by seeing timestamps associated with 
packets it's possible that your pcap has a 36 minute jump in timestamps 
so Bro couldn't have possibly expired anything in the time before that 
because from its perspective there was an immediate jump in time.  You 
don't normally experience the effects of this behavior in traffic you're 
sniffing live because you will tend to have many packets every second so 
you see Bro's clock driven forward in very tiny increments as you would 
expect.  If you go a long time without receiving a packet is when stuff 
gets tricky.

   .Seth

--
Seth Hall * Corelight, Inc * www.corelight.com
___
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev