Zeek - one of the strengths of the tool, the fine monitoring of connections

Hi !

I can’t count the number of times that using the “conn state” and “history” fields together has allowed me to accurately diagnose what was happening on my network. One can only praise Zeek’s documentation which indicates precisely what is happening.

Reference : https://docs.zeek.org/en/master/scripts/base/protocols/conn/main.zeek.html (as of 18 november 2024).

The field “conn_state” in “conn.log”: It shows the status of the connections.


S0    : Connection attempt seen, no reply |
S1    : Connection established, not terminated.
SF    : Normal establishment and termination. Note that this is the same symbol as for state S1.
        You can tell the two apart because for S1 there will not be any byte counts in the summary, 
        while for SF there will be.
REJ   : Connection attempt rejected.
S2    : Connection established and close attempt by originator seen (but no reply from responder).
S3    : Connection established and close attempt by responder seen (but no reply from originator).
RSTO  : Connection established, originator aborted (sent a RST).
RSTR  : Responder sent a RST.
RSTOS0: Originator sent a SYN followed by a RST, we never saw a SYN-ACK from the responder.
RSTRH : Responder sent a SYN ACK followed by a RST, we never saw a SYN from the (purported) originator.
SH    : Originator sent a SYN followed by a FIN, we never saw a SYN ACK from the responder, (hence the connection was “half” open).
SHR   : Responder sent a SYN ACK followed by a FIN, we never saw a SYN from the originator.
OTH   : No SYN seen, just midstream traffic (one example of this is a “partial connection” 
        that was not later closed).

The field “history” in “conn.log”: It records the state history of connections as a string of letters.


s     : a SYN w/o the ACK bit set
h     : a SYN+ACK (“handshake”)
a     : a pure ACK
d     : packet with payload (“data”)
f     : packet with FIN bit set
r     : packet with RST bit set
c     : packet with a bad checksum (applies to UDP too)
g     : a content gap
t     : packet with retransmitted payload
w     : packet with a zero window advertisement
i     : inconsistent packet (e.g. FIN+RST bits set)
q     : multi-flag packet (SYN+FIN or SYN+RST bits set)
^     : connection direction was flipped by Zeek’s heuristic
x     : connection analysis partial (e.g. limits exceeded)

        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’, ‘d’, ‘i’ and ‘q’ flags are recorded a maximum of one time in either direction regardless 
        of how many are actually seen. 
        ‘f’, ‘h’, ‘r’ and ‘s’ can be recorded multiple times for either direction 
        if the associated sequence number differs from the last-seen packet of the same flag type. 
        ‘c’, ‘g’, ‘t’ and ‘w’ are recorded in a logarithmic fashion: 
        the second instance represents that the event was seen (at least) 10 times; 
        the third instance, 100 times; etc.

Now let’s look at some examples of “conn.log” files.


#fields ts      uid     id.orig_h       id.orig_p       id.resp_h       id.resp_p       proto   service duration        orig_bytes      resp_bytes      conn_state      local_orig      local_resp      missed_bytes    history orig_pkts       orig_ip_bytes   resp_pkts       resp_ip_bytes
   tunnel_parents  geo.orig.country_code   geo.orig.region geo.orig.city   geo.orig.latitude       geo.orig.longitude      geo.resp.country_code   geo.resp.region geo.resp.city   geo.resp.latitude       geo.resp.longitude
  count   count   count   count   set[string]     string  string  string  double  double  string  string  string  double  double

1732057195.967454       Cx7xki3L7czAv3Hs4h      58.246.22.98    59143   162.212.157.188 80      tcp     -       3.238383        0       0
       RSTO    F       T       0       ShR     3       120     2       88      -       CN      SH      Shanghai        31.0442 121.4054        US      -       -       37.751  -97.822

In the above example, we can observe (according to the documentation):

The remote IP address tried to connect to port 80.

The “conn state” field returns “RSTO” which means “Connection established, originator aborted (sent a RST)”.

The “history” field indicates “ShR” which means that the originator sent a “Syn”, the server returned a “Syn/Ack” then the originator sent a “Reset”.

Let’s check another example :


1732057752.092479       Cw7oLJ1w30NJ9XiEsa      69.162.124.238  56902   162.212.157.188 443     tcp     ssl     0.128417        844     4294
    SF      F       T       0       ShADdfFr        14      1580    13      4958    -       US      -       -       37.751  -97.822 US      -
       -       37.751  -97.822

In the above example, we can observe that the originator tried to connect to port 443.

The “conn state” field shows “SF” which means “Normal establishment and termination”.

The “history” field indicates “ShADdfFr”. Let’s break this down:

  • Originator sent a “Syn”
  • Server responded with a “Syn/Ack”
  • Originator sent a “Ack” then “Data”
  • Server responded with “Data” then sent a “Fin”
  • Originator sent a “Fin”
  • Server sent a “Reset”

I hope these brief examples have shown you the extent of what the study of these fields can reveal.

Cheers.