https://github.com/corelight/community-id-spec "When processing flow data from a variety of monitoring applications (such as Zeek and Suricata), it's often desirable to pivot quickly from one dataset to another."
A Community ID implementation for Wireshark. https://gitlab.com/wireshark/wireshark/-/merge_requests/281 On Mon, Aug 28, 2023 at 10:55 AM Josh Clark <j...@je-clark.com> wrote: > How controlled will the network be between the two capture locations? Are > there any firewalls, load balancers, proxies, NATs, or anything like that? > If there are, then whatever correlation you do will have to factor in the > specific configuration and device characteristics. > > If none of those are the case and correlation is still difficult, it may > be retransmissions or dropped packets that are hindering correlation. In > those cases, you’ll see the same sequence and acknowledgement numbers over > and over again, but associated with different packets. > > In general, the solution you’re using so far (checking sequence and > acknowledgement numbers) is really well suited to identifying segments of > TCP payload, but that payload isn’t necessarily tied to a packet. The best > individual identifier for a packet is the Identity field in the IP header ( > ip.id), and a lot of correlation solutions I’ve seen will take a hash of > multiple fields to craft a “packet signature”. > > Personally, as long as there are no firewalls, proxies, or NATs in the > way, I would hash together source IP, destination IP, source port, > destination port, and IP ID. Absolute sequence numbers could be used as > secondary validation, and I would also check the time stamp of the packet > to prevent accidental correlations when that field rolls over and restarts > (maybe just ensure that the time stamps of the packets are within 5 minutes > of each other). > > I hope that helps! > > Regards, > > Josh Clark > > On Mon, Aug 28, 2023 at 08:22 Brian Reichert <reich...@numachi.com> wrote: > >> This question isn't specific to Wireshark, but I couldn't find a >> good forum. By all means, I'm open to suggestions as to where it >> would be more appropriate to ask about this. >> >> Anyway: >> >> I'm trying to automate the reconciliation of a pair of packet >> captures of a TCP session. >> >> This is sort of a combination of: >> >> - reconstructing a TCP 'flow' as Wireshark currently does, and >> - correlating an individual packet within one capture with packet(s) >> in the second capture. >> >> The overall goal is to generate some insight on network latency. >> >> I'm very close, but not close enough. >> >> I naively though that I could 'just' chain sets of packets by >> comparing absolute sequence numbers, and the respective ACK numbers. >> >> But, given the example captures I have, this is proving to be not >> adequate. >> >> This is obviously an open-ended request for advice. I'd be happy >> for any I can get, including a 'go ask there' suggestion. >> >> Thanks! >> >> -- >> Brian Reichert <reich...@numachi.com> >> BSD admin/developer at large >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
