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

can't reassemble entire packet when get [tcp acked unseen segment] #335

Open
linpengstc opened this Issue Apr 12, 2019 · 1 comment

Comments

Projects
None yet
2 participants
@linpengstc
Copy link

linpengstc commented Apr 12, 2019

When analyse traffic mirror, I always get the content_gap event and zeek will not reassemble the entire package.
I think the reason is the ACK arrived before the the data package,

image
When I analyse the pcap in wireshark, I can see the a ACK marked as [TCP ACKed unseen segment]. Wireshark can reassemble the entire http package, but bro can't
pcap.zip

I provide my pcap and bro script, run bro -r http_pkg7 http_header.bro

image

@jsiwek

This comment has been minimized.

Copy link
Member

jsiwek commented Apr 15, 2019

There's two bits of info that are relevant here:

  1. The TCP reassembly process in Zeek/Bro always moves forward and adjusts expectations based on the ACKs it sees. If an ACK is seen before the opposite TCP's associated data, then that is treated as a content gap at the moment the ACK is seen and that space in the global sequence is considered as being analyzed already. Any further data seen in the already-analyzed sequence space is just discarded.

  2. The HTTP analyzer isn't particularly resilient to content gaps. If it gets a content gap that is not entirely contained within an HTTP message body, it will not attempt to re-synchronize and analyze any further content.

Point (1) is more relevant than (2) here because this particular pcap doesn't have further content, but I mention it just in case you do run into it. I think both issues are non-trivial to address anytime soon:

To better deal with (1) we'd likely need more buffering mechanisms in the TCP reassembly process to understand the past reassembly history/state and delay reporting gaps -- maybe not a great thing to add to a system aimed more at real-time analysis. Ideally, the capture setup would would show us the data before the associated ACKs of that data.

Improvements to (2) likely won't happen until HTTP/MIME analyzers get re-written. You may be able to find some use in detecting this type of problem via the http_message_done event's http_message_stat parameter, which has an interrupted field that is true if a content gap interrupted the analysis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.