使用 Seq No 、 Ack No 和/或 Datasize 区分 TCP 连接
我通过使用 TCPDUMP 收集的数据包转储来聚合连接。我的代码是用 Ruby 编写的。 该代码将使用 4 元组（SrcIP、SrcPort、DstIP、DstPort）区分连接 现在，如果连接是在同一台机器之间，具有相同的 IP 和相同的端口，则通过以下方法区分连接。 1. 如果两次连接之间的时间超过2小时则为新连接 2. 如果我们已经看到 FIN 或 RST，那么新数据包来自新连接 3. 如果 SYN 数量超过 2 个（每个方向 1 个），则该连接是一个新连接。
我无法解决的情况如下 如果相同的两个主机（具有相同的 4 元组）之间的新连接在 2 小时内发生，并且 TCPDUMP 会丢弃之前的 RST 或 FIN 数据包，并且还会从两个连接中丢弃 2 个或更多 SYN 数据包。在这种情况下，我设置的上述条件都不起作用。唯一保留的信息是新组数据包的时间、序列号、确认号和数据大小。仅使用这些信息我就可以判断该连接是新连接还是旧连接？
我试图查看序列 No 中或 SeqNo 和 AckNo 之间是否存在某种模式，但似乎没有一个是明确的。
I am aggregating connections by going through collected packet dump,collected using TCPDUMP. My code is in Ruby.
The code will differentiate between connections using the 4-tuple ( SrcIP,SrcPort,DstIP,DstPort)
Now if the connections are between the same machine, having the same IP and the same port then the connections are differentiated by the following method.
1. If the time between the connections is more than 2Hrs then its a new connection
2. If we see we have already seen a FIN or a RST then the new packet is from a new connection
3. If the No of SYNs are more than two ( One in each direction) then the connection is a new connection.
The situation I am not able to address is the following
If new connection between the same two hosts (having the same 4-tuple) happened within 2Hrs and TCPDUMP dropped the previous RST or FIN Packets and it also dropped 2 or more SYN Packets from both the connections. In that case none of the above conditions that I have set will work. And the only set of Information that remains is the time of the new set of packets ,Seq Nos, Ack Nos and data size. Just using this information could I figure out if the connection is a new one or an old one?
I tried to see if there is a pattern in the sequence No or between the SeqNo and the AckNo but none seem to definite.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于 TCP（主要）使用滑动确认窗口，因此 SeqNo 和 AckNo 将是单调递增字段 - - 直到它们由于整数溢出而环绕。
此外，一个流量方向的 SeqNo 对应于另一流量方向的 AckNo，这提供了您可以检查的另一个不变量。
一个复杂的因素是 SeqNo 最初被选择为随机的，以减少中间人攻击；因此，具有相同参数的新会话可能会选择比之前可见的序列号更大的初始序列号，并使您的算法感到困惑。
Because TCP (primarily) uses a sliding acknowledgement window, the SeqNo and AckNo will be monotonically increasing fields -- until they wrap around due to integer overflow.
Also, the SeqNo from one direction of traffic corresponds to the AckNo of the other direction of traffic, providing another invariant that you can check.
One complicating factor is that the SeqNo are initially chosen to be random to reduce the likelihood of man in the middle attacks; so, a new session with otherwise identical parameters might pick initial sequence numbers that are larger than the previously visible sequence numbers, and confuse your algorithms.