Quick question on conn tracking

Zeek
1

Hey all,

So I'm getting bro and elasticsearch going, with one of the goals of finding flows with no service field. That being said I am seeing that long session, at least I THINK that's what I'm seeing, appear to be counted twice. From conn.log:

2016-09-28T12:29:39-0600 192.168.1.101 44083 31.13.76.101 443 tcp ssl 0.214346 460 170 S1 T F 0 ShADad 8 884 7 542 (empty) -

2016-09-28T12:44:39-0600 192.168.1.101 44083 31.13.76.101 443 tcp - 0.016678 31 0 RSTRH T F 0 fDrAr 2 135 3 132 (empty) -

I captured the data and I'm enclosing the pcap. Basically, ssl connection is established at 12:29:39 and is open until Facebook gets annoyed and FIN-ACK's the session at 12:44:39 (now we know they time out at exactly 15 minutes). However why does that show as entries as above? Thanks for any insight.

James

192.168.1.101.pcapng (3.33 KB)

2

I get the same in elasticsearch.
But its got nothing to do with it.

Bro seems to split the socket because
of the time inbetween the activity.

You can avoid this by longer timeouts.

It would be better to create a script that
keeps track of all ssl connections in
memory/broker.
  
I had to convert your dump to tcpdump
in order to read it in bro (git)

3

Thanks Danial. Is there a way to tell bro to have a longer timeout? Thank you.

James

4

/usr/local/bro/share/bro/base/init-bare.bro

## If a TCP connection is inactive, time it out after this interval. If 0 secs,
## then don't time it out.

5

Beautiful thank you....bet I need to redef these and stick it in my local.bro. Thanks again..helps me make this more awesome :slight_smile:

James

6

Wow, you're actually seeing 15 minute where there are no packets seen in the connection? I'm surprised that Facebook has such a long timeout on their frontend web servers. I would expect that a timeout that long would actually cause quite a few middle boxes quite a bit of consternation as well. :slight_smile:

  .Seth

7

Heh....spotify is even worse :stuck_out_tongue:

notice.log:1475161562.899483 CPEyXm4oD4iu0xu4v1 192.168.1.101 42263 193.235.203.66 4070 - - - tcp LongConnection::found 192.168.1.101 -> 193.235.203.66:4070/tcp remained alive for longer than 49m42s 2981.66 192.168.1.101 193.235.203.66 4070 - bro Notice::ACTION_LOG 3600.000000 F - - - - -

CRAZYTOWN!

James

8

It seems to pop up with a few types of history .. here RSTRH
104.70.5.52 (akemai/itunes) has ^fR