BRO conn.log - connection flow direction wrong - non standard telnet port connection

Hello,

I am pretty new user of BRO and use it as a part of the Security Onion distributions. I currently came across a problem which I was hoping one of you might be able to help with.

When looking at some telnet connections on a non-standard TCP port I noticed that some data flows are reported in the wrong direction. When checked the conn.log files, all the entries in question had the same characteristics below:

  1. They would only appear in the archive (gzip) conn.*.log.zip files - not the current conn.log file.

  2. Entries would always be at the beginning of the zipped conn.*.log.zip file

  3. Conn_State field would say RSTR 4. History field would be DaFr (on most of them)

Below are some examples, as you can see the file name reflects from/to date/time, and the characteristics of the entries in question where flow direction is reversed are below:

zcat conn.16:27:17-17:00:00.log.gz | bro-cut -d ts proto conn_state history | grep RSTR

2013-10-25T16:27:12+0000 tcp RSTR DaFr

2013-10-25T16:27:12+0000 tcp RSTR DaFr

2013-10-25T16:27:12+0000 tcp RSTR DaFr

zcat conn.18:36:28-19:00:00.log.gz | bro-cut -d ts proto conn_state history | grep RSTR

2013-10-25T18:36:23+0000 tcp RSTR DaFr

2013-10-25T18:36:23+0000 tcp RSTR DaFr

2013-10-25T18:36:23+0000 tcp RSTR DaFr

zcat conn.18:36:28-19:00:00.log.gz | bro-cut -d ts proto conn_state history | grep RSTR

2013-10-25T18:36:23+0000 tcp RSTR DaFr

2013-10-25T18:36:23+0000 tcp RSTR DaFr

2013-10-25T18:36:23+0000 tcp RSTR DaFr

It almost seems that when conn.log file is being divided up and zipped this happens.

Just to give some context, we have a script running which telnets to multiple devices and polls certain variables and exits on a non-standard telnet ports.

Thanks,

Konrad

Are you dropping a lot of packets? It looks like Bro isn't seeing the beginning of these connections (syn packets) which makes it nearly impossible to determine the direction without guessing. Bro's current strategy for "fixing" reversed connections like this is by consulting the likely_server_ports variable but since it sounds like you are using non-standard ports it's unlikely that this would work.

I think the big question we need to answer is why you aren't seeing the SYN packets. Check for PacketFilter::Dropped_Packets notices in your notice.log and add "@load misc/capture-loss" to your local.bro script so that you will have a capture_loss.log which will give a holistic measurement of packet loss.

  .Seth

Hello Seth,

Thanks for looking into this.

I do not have notice.log file created in that particular timeframe. Also I
see that capture_loss.log files are there...see output below:

Session reported wrong direction:

zcat conn.00\:00\:00-01\:00\:00.log.gz | bro-cut -d ts uid proto conn_state
history | grep BuR4quUCRKe
2013-11-03T00:41:24+0000 BuR4quUCRKe tcp SH Fa

Capture_loss log file for the same timeframe as above:

zcat capture_loss.00\:00\:00-01\:00\:00.log.gz | bro-cut -d
2013-11-03T00:11:59+0000 900.000034 bro 0 669214
0.000%
2013-11-03T00:26:59+0000 900.000020 bro 0 675273
0.000%
2013-11-03T00:41:59+0000 900.000052 bro 0 672973
0.000%
2013-11-03T00:56:59+0000 900.000032 bro 0 681093
0.000%

I had to look at a data from different timeframe as my BRO logs got deleted
from the time frame I referenced in the original email.

Thanks,

Konrad

zcat conn.00\:00\:00-01\:00\:00.log.gz | bro-cut -d ts uid proto conn_state
history | grep BuR4quUCRKe
2013-11-03T00:41:24+0000 BuR4quUCRKe tcp SH Fa

Could you capture some packets from one of these connections and send it to me? There must be something else going on here.

2013-11-03T00:11:59+0000 900.000034 bro 0 669214
0.000%
2013-11-03T00:26:59+0000 900.000020 bro 0 675273

This looks good at least.

  .Seth