mirror of
https://github.com/zeek/zeek.git
synced 2025-10-02 14:48:21 +00:00
82 lines
3.1 KiB
Text
82 lines
3.1 KiB
Text
TCP connection logs are generated by tcp.bro. The summaries are written
|
|
to stdout, one line per connection:
|
|
|
|
start-time duration protocol orig-bytes resp-bytes \
|
|
local-addr remote-addr state flags additional
|
|
|
|
start-time: timestamp of when the connection's first packet was
|
|
observed
|
|
|
|
duration: time until connection finished, in seconds, or '?' if
|
|
not determined
|
|
|
|
protocol: TCP protocol, if well-known port; or portmapper request
|
|
|
|
orig-bytes: total bytes sent by originator. Computed from difference
|
|
between starting and ending sequence numbers, so sometimes
|
|
wrong (if wrong, the values tend to be erroneously large)
|
|
|
|
resp-bytes: same for bytes sent by connection responder
|
|
|
|
local-addr: IP address of local end of connection
|
|
remote-addr: IP address of remote end of connection
|
|
Note that these would make more sense as originator/responder,
|
|
but for historical reasons they're defined in terms of
|
|
"local" and "remote", where "local" is specified by the
|
|
"local_nets" set in hot.bro. To pull out the originator
|
|
and responder addresses requires looking at the "flags"
|
|
field to see whether the connection originated locally.
|
|
|
|
state: final connection state (see below)
|
|
|
|
flags: some characteristics of the connection. The most important is
|
|
the 'L' flag, which if present indicates that the connection
|
|
was initiated by the local address (see above); otherwise
|
|
it was initiated by the remote address.
|
|
|
|
additional: protocol-specific additional information, such as the FTP
|
|
session identifier, telnet user name, finger request, or
|
|
portmapper results.
|
|
|
|
The scripts "hot-report" and "mon-report" (in the aux/scripts/ directory)
|
|
generate readable versions of these connection summaries. They include
|
|
a mnemonic indicating the connection's state. Here is the list of
|
|
abbreviations used:
|
|
|
|
Symbol Name Meaning
|
|
------ ------- -------------------
|
|
} S0 Initial SYN seen, no reply seen ("unanswered")
|
|
> S1 Initial SYN handshake seen ("established")
|
|
|
|
> SF Established and normal FIN handshake seen
|
|
for 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, while for SF there will be.
|
|
|
|
[ REJ Initial SYN elicited RST in reply ("rejected")
|
|
|
|
}2 S2 Established and FIN from originator only seen
|
|
}3 S3 Established and FIN from responder only seen
|
|
|
|
>] RSTO Established, originator sent a RST to terminate
|
|
>[ RSTR Established, responder sent a RST to terminate
|
|
|
|
}] 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 originator
|
|
|
|
>h SH Originator sent a SYN followed by a FIN,
|
|
we never saw a SYN ack from the responder
|
|
(so "half" open)
|
|
<h 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
|
|
|
|
The sundry weird states can arise from broken TCPs, but also from split
|
|
routing in which Bro just sees one side of a connection.
|
|
|
|
For UDP, if we see a request but no reply, that's state S0 ("}"); a request
|
|
followed by a reply is SF (">"); and a reply but no request is SHR ("<h").
|