conn.log - What does cc=1 mean?

Zeek
1

Hello list,

This is my first post - just another network monkey, been playing around with bro for the last year or so, writing some custom policy files to try and do some large scale analysis.

Can anyone tell me what the “cc=1” means at the end of a line for conn.log output?

I’m getting output lines like this:

1307664147.729018 0.103712 1.2.3.4 5.6.7.8 https? 1839 443 tcp 1865279311 ? RSTOS0 X cc=1

The ‘sent bytes’ is “1865279311”, which seems awfully high, and received are 0. A quick survey looks like most entries that have a large byte count with sent or received and 0 in the other direction have the state set to “RSTOS0” and the flags set to “X cc=1”.

I believe one of the main factors causing this is damaged PCAPs (limited snaplength, possibly dropped packets). However if I can exclude the damaged records, I can still carry on with some analysis.

Thanks,

-David

2

I have seen these lines mostly on failed connections (could be either due to missing packets in the capture file or genuine setup failures). The cc=1 is from the connection compressor being enabled for this run. There is some good documentation on what the connection compressor does and what enabling it means in src/ConnCompressor.cc in the source tree.

I turn off connection compressor for some of my analysis since you lose some information when there are syn retries. Have you looked at some of the connections which have the cc=1 tag to see if they are just setup failures or your trace is missing packets or there is something else weird with those connections?

Sridhar

3

1307664147.729018 0.103712 1.2.3.4 5.6.7.8 https? 1839 443 tcp 1865279311 ?
RSTOS0 X cc=1

The 'sent bytes' is "1865279311", which seems awfully high, and received are
0.

Yeah, the byte count for RSTOS0 connections is unreliable. The reason is
that RSTOS0 means "the connection originator sent a SYN followed a while
later by a RST, with no SYN-ACK from the other side". In that situation,
Bro's best guess as to the byte count for the connection is the difference
in sequence numbers between the RST and the SYN. *Sometimes* that's correct,
but often there's no particular relationship between those two values, in
which case you get the equivalent of a garbage 32-bit value for the size.

I believe one of the main factors causing this is damaged PCAPs (limited
snaplength, possibly dropped packets)

Note, that's probably not what's causing the above. Bro generally detects
damaged PCAPs and refrains from analyzing them. Dropped packets can lead
to some degree of confusion, but RSTOS0 more often means that the originator
either had no luck (responder never answered, and eventually the origiantor
tore down the connection with a RST because of this), and/or the originator
was scanning.

    Vern