Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"ts+duration" for TCP flow is missing more than just ACK #846

Open
philrz opened this issue Mar 5, 2020 · 0 comments
Open

"ts+duration" for TCP flow is missing more than just ACK #846

philrz opened this issue Mar 5, 2020 · 0 comments

Comments

@philrz
Copy link

@philrz philrz commented Mar 5, 2020

I've been recently doing some comparisons between how Zeek perceives flows (via conn records) vs. Wireshark. I first mentioned the issue described here on Slack.

Early in my studies, I came across the fine print in the docs about Zeek's duration:

For 3-way or 4-way connection tear-downs, this will not include the final ACK.

However, I've found some PCAPs where Wireshark/tshark identifies TCP flows that include packets timestamped out beyond ts+duration, and sometimes these "extras" are more than just mere ACKs.

The attached PCAP shows three such examples.

after-close.pcap.gz

I first ran it through my "stock" Zeek v3.1.0 test environment (zeek -C -r after-close.pcap local). Here's the conn records for the three flows in JSON format for ease of viewing:

{
  "_path": "conn",
  "conn_state": "SF",
  "duration": "177.375569",
  "history": "ShADadgtgfFr",
  "id": {
    "orig_h": "192.168.0.51",
    "orig_p": 56370,
    "resp_h": "80.239.174.117",
    "resp_p": 443
  },
  "local_orig": null,
  "local_resp": null,
  "missed_bytes": 16656,
  "orig_bytes": 1354,
  "orig_ip_bytes": 3506,
  "orig_pkts": 41,
  "proto": "tcp",
  "resp_bytes": 35154,
  "resp_ip_bytes": 37126,
  "resp_pkts": 38,
  "service": "ssl",
  "ts": "1425567047.013408",
  "tunnel_parents": null,
  "uid": "Cjukde4hlTiXc7qm8"
}
{
  "_path": "conn",
  "conn_state": "SF",
  "duration": "177.557645",
  "history": "ShADadfFr",
  "id": {
    "orig_h": "192.168.0.51",
    "orig_p": 59552,
    "resp_h": "80.239.174.116",
    "resp_p": 443
  },
  "local_orig": null,
  "local_resp": null,
  "missed_bytes": 0,
  "orig_bytes": 7097,
  "orig_ip_bytes": 8521,
  "orig_pkts": 27,
  "proto": "tcp",
  "resp_bytes": 5887,
  "resp_ip_bytes": 7131,
  "resp_pkts": 24,
  "service": "ssl",
  "ts": "1425574220.361991",
  "tunnel_parents": null,
  "uid": "CPoo8b2dsaAPB7gtal"
}
{
  "_path": "conn",
  "conn_state": "SF",
  "duration": "7.33016",
  "history": "ShADadFft",
  "id": {
    "orig_h": "192.168.0.51",
    "orig_p": 33304,
    "resp_h": "46.246.28.85",
    "resp_p": 443
  },
  "local_orig": null,
  "local_resp": null,
  "missed_bytes": 0,
  "orig_bytes": 2595,
  "orig_ip_bytes": 3499,
  "orig_pkts": 17,
  "proto": "tcp",
  "resp_bytes": 5837,
  "resp_ip_bytes": 6708,
  "resp_pkts": 16,
  "service": "ssl",
  "ts": "1425628285.873552",
  "tunnel_parents": null,
  "uid": "C8XImM3LEkUfsOyHg4"
}

You can then bring up the flows for comparison in Wireshark by opening the PCAP file and using filters shown for each respective conn record:

  • tcp.stream eq 0

ts + duration = 1425567224.388977. Here we observe an additional packet timestamped 1425567224.428169 that's a pure RST.

  • tcp.stream eq 1

ts + duration = 1425574397.919636. Here we observe three additional packets: A FIN+ACK, pure ACK, a pure RST.

  • tcp.stream eq 2

ts + duration = 1425628293.203712. Here we observe four additional packets: Three pure ACKs and one PSH+ACK. Perhaps this one can be considered compliant with the doc since they're all ACKs of one form or another, though the docs seem to imply a single ACK might be all that would be missed.

Conclusion: Personally, I think it'd be great if Zeek's time fields could describe the span of the whole flow to the same extent Wireshark sees it, but the fact the duration docs include that disclaimer leads me assume there's technical reasons why it's not feasible to do so. Assuming that's still the case, then it seems the docs could benefit from more details about how Zeek perceives TCP closure and the additional classes of packets that may therefore be out beyond the ts + duration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.