Bro conn log history questions

Zeek
1

Sometimes I see multiple R flags in the conn.log history field. Example (field order alphabetized due to attempts to prettify JSON):

{
conn_state: “RSTO”
duration: 3.856864
history: “FhAdRR”
“id.orig_h”: “REDACTED”
“id.orig_p”: 3793
“id.resp_h”: “REDACTED”
“id.resp_p”: 5900
local_orig: false
local_resp: true
missed_bytes: 0
orig_bytes: 0
orig_ip_bytes: 160
orig_pkts: 4
proto: “tcp”
resp_bytes: 12
resp_ip_bytes: 152
resp_pkts: 3
ts: 1527874960.128133
tunnel_parents:
uid: “C83wr8ZHFD8PK5lsl”
}

I’m not certain how to interpret this. I assume that means Bro detected multiple RST packets from the originator, but that also contradicts the documentation:

Multiple packets of the same type will only be noted once (e.g. we only record one “d” in each direction, regardless of how many data packets were seen.)

(from https://www.bro.org/sphinx/scripts/base/protocols/conn/main.bro.html)

Additionally, I sometimes see an H flag in the conn.log. I would only expect to see a SYN-ACK from the responder, so I’m wondering why Bro’s heuristics didn’t flip the connection. Example:

{
conn_state: “RSTO”
duration: 10.980346
history: “HadfR”
“id.orig_h”: “REDACTED”
“id.orig_p”: 5228
“id.resp_h”: “REDACTED”
“id.resp_p”: 51157
local_orig: false
local_resp: true
missed_bytes: 0
orig_bytes: 148
orig_ip_bytes: 140
orig_pkts: 2
proto: “tcp”
resp_bytes: 611
resp_ip_bytes: 712
resp_pkts: 7
ts: 1527878613.810056
tunnel_parents: Array
uid: “CU7Jnp4p9P9YCbIXy”
}

2

Sometimes I see multiple R flags in the conn.log history field. Example (field order alphabetized due to attempts to prettify JSON):
I'm not certain how to interpret this. I assume that means Bro detected multiple RST packets from the originator, but that also contradicts the documentation

Seems like a case of the docs being wrong/outdated. I've changed it:

## If the event comes from the originator, the letter is in
## upper-case; if it comes from the responder, it's in
## lower-case. The 'a', 'c', 'd', 'i', 'q', and 't' flags are
## recorded a maximum of one time in either direction regardless
## of how many are actually seen. However, 'f', 'h', 'r', or
## 's' may be recorded multiple times for either direction and
## only compressed when sharing a sequence number with the
## last-seen packet of the same flag type.

So yeah, I'd interpret multiple 'R' in the history field as "saw at
least that many RST packets from originator that did not share the
same sequence number as the last RST".

Additionally, I sometimes see an H flag in the conn.log. I would only expect to see a SYN-ACK from the responder, so I'm wondering why Bro's heuristics didn't flip the connection.

Last I recall, it won't flip roles on upon just first witnessing a
SYN-ACK. Some thoughts/history related to that at [1].

So, just glancing at the TCP code seems like the it may record the
history before deciding to flip the roles in at least one situation:
if it first sees a SYN-ACK, it could record 'H", but then later see a
SYN from the peer and decide to flip the roles at that point.

- Jon

[1] [BIT-1236] - Bro Tracker