实验目的

先思考几个问题：

TCP建立链接时，数据包有来有回才是网络可连通的标志。就是说，A端向B端发送了需要确认的包后，B端首先需要先收到这个包，然后读取收到包的TCP协议头中的[ Sequence Number ]、[ Acknowledgment Number ]。检查有[SYN]时，则需要返回[ACK]以通知A端确认收到了。补充，[ Sequence Number ]在协议中称之为synchronize。
[ Sequence Number ]、[ Acknowledgment Number ] 因为收到的时间先后都有一个原始raw序号，这个是相对于操作系统TCP流的，而每次完整的链接中，也有一个相对值。一般Wireshark在包列表窗口中显示的是相对序号。如何查看raw序号？
[ Sequence Number ]、[ Acknowledgment Number ] 是一般是成对存在的，每一个[ACK]的前面都有一个[SYN],那么如何找到这个成对存在的[SYN]+[ACK] ?
[ACK]常见而[SYN]不常有，找出深藏了的变种[SYN]。变种成员包括[PSH]/[FIN]/[RST]，它们也需要有一个[ACK]确认。证明给我看？
实验过程环节提供了数据包的实例附件。

温习与疑问初探

下面是一个完整的请求过程，以及示例截图：

No.1/No.2/No.3是TCP建立连接包：No.2是对No.1的[ACK]确认，No.3是对No.2的确认。握手过程是两组[SYN]+[ACK],没毛病。其中No.2是同时具有的。这种合并的现象是占有大多数比重的，它是TCP协议规范的标准。
No.7/No.8/No.9是TCP断开连接包：No.8是对No.7的[ACK]确认，No.9是对No.8的[ACK]确认。挥手过程是两组[SYN]+[ACK]，没毛病。其中No.8是同时具有的。No.7/No.8的[FIN]就是变种[SYN],它们需要一个确认包。
- TCP建立连接包一般是3个包，而断开连接包有3个也有4个，区别是可以将合并的No.8分开成2个传送。
No.4/No.5/No.6是链接建立之后开始正式数据传输的部分：但它还是基于TCP协议的，所以[ACK]确认还是伴随着存在。No.5是对No.4的确认，No.6是对No.5的确认。而No.6的确认是后面的No.7。更多详见附件包。

wireshark使用技巧之数据包关系树标记

wireshark_No_column

注意动图中数据包列表窗口中的No.这列在选择不同数据包时的变化：

[ 左中括号表示这是一次完整的请求过程，只要你选中任意一个包它就会通过 [ 将相关的数据包从列表中帮你快速的映射连接起来。
- 如果包不连续则会使用虚线表示跳过。
- 如图它表示的是客户端TCP:61333 <---> 服务端TCP:8088 之间的请求过程。当你下次再请求这个接口时，客户端的端口将会变化，因为链接已经正常的通过断开连接包传递过程断开了。
- 过滤一次完整的会话中的所有的数据包：只需要 tcp.port == client.tcp.port。添加这种过滤条件后，就会将无关的造成不连续的包过滤排除掉。这也是最小化分析问题的一个方法。
√ 对号标记：表示它是你选中数据包的配对包，即[SYN]+[ACK]，只有选择的包为[ACK]时，才会触发另一个包被标记。
-> 和 <- 箭头表示应用层请求、响应的方向，选中其中一个，另一个也会以相反箭头出现标记：属于wireshark对应用层的进一步解码分析，此示例中是http请求，如果是使用和https协议就跟踪不出来了。
- 这里只分析了一次简单的接口请求，而且是从请求端是非浏览器的系统向服务端的请求过程。
• 实心点：表示这个是真正的数据包（包含应用层的数据）即数据流。
- 不连续的实心点验证了同一时间段主机还有其它链接。
- 它不仅仅是TCP链接建立、确认的包。通过包的大小也可以判断。如下实心示例，显示了实心点的一般可以进行追踪流，加密链接无法追踪。如图当选中了<-箭头标记的这个包后，wireshark触发了匹配实心标记。

实战开始

本示例所用分析包，下载： http_post_request_20220709.zip

client_cap_wireshark.pcapng是客户端的抓包

server_cap_tcpdump.pcap 是服务端的抓包

网络拓扑：

Client 192.168.1.100 (公网IP:210.51.248.1)

Server 172.16.1.100 (公网IP:36.51.251.1)

问题现象
在服务端请求接口返回的403报错响应码与实际一致，而在客户端请求时却返回了404。这是什么原因？
接口调用返回效果

分析过程

重新发请求，在客户端和服务端抓包。

对比整个连接过程

连接的建立、断开都正常，只有返回包有差别。

问题帧的深入对比

完整的帧对比结果：

客户端收到的数据已经不是从服务端返回的数据包了。但由于数据包的TCP层及以下层是正常的，它就能被正常的当作本次连接中的数据包。

而不正常的部分是应用层（HTTP协议）已经被填充了404数据，而且为了保持长度一致，还填充了0000。

分析结论

存在数据包篡改。

可能存在waf（安全设备）将403或405（405的数据包示例类似）这种异常请求当作风险后，返回了特定数据包，以避免潜在的暴力攻击试错。

结论总结

防范篡改：应用层篡改可以通过应用层加密码防范，比如https就是对http协议的加密，加密后的应用层肉眼不可读取有效信息。那加密后能否被篡改呢？理论上可以，这还要看篡改后的数据在通信的双方是否认可。因为如果加密的密钥变化了，就会对通信的双方认为是无效数据包，从而中断通信。因而一般是在密钥丢失并被利用后，才会有篡改的风险。暴力解密破解，则需要大量的时间，破解信息的时效性价值已经没有了。这样就防范了中间人攻击（篡改），确保传输过程的安全。
此方式不能保证接收包的双方的身份有效性，即Server、Client都是合法的，而非伪造的，它的解决方案是双向认证，此时则需要一个第3方CA来辅助server或client确认对方就是对方种合法性。
P2P通信过程中，只能保证链路安全和端点合法，就能实现通信安全。
- 数据包在传输的链路上上被复制、镜像时，应用层加密能保证数据是原始性。
- 端点的身份认证能确保某一方的身份有效。

比如https中使用的ssl证书保证了服务端的身份有效性，确保用户连接的服务端就是对方，而非伪造出来的。

扩展：

如何把上面的离线的篡改包修改回正常的403状态？

搜索关键字：vi + xxd ：可以简单修改二进制文件编码。