虚拟靶场抓到巨帧包!

教IT的小强

已于 2024-01-06 18:08:36 修改

阅读量251

点赞数

文章标签：网络 tcp/ip 网络协议

于 2023-08-26 11:30:00 首次发布

本文链接：https://blog.csdn.net/m0_59598029/article/details/132503827

版权

前言

在自己的虚拟化靶场中抓包，发现 wireshark 面板中的 Length 远大于 MTU，而明明在抓包网卡的MTU是1500，这是为什么呢？
将这个包的流量回放到 snort 的接收网卡上，发现 snort 并没有“接收”到这个包，这是为什么呢？

带着这两个为什么，开始接下来的探索吧！

餐前小菜

正餐开始前，必须先知道这些定义，如图1所示：

1649943732_625824b4a634a1e20fe7a.png!small?1649943732971

图1: 5个必知定义

1、Jumbo frames
：巨型帧，也叫巨帧。指的是链路层上负载超过1500字节的以太网帧，一般来说巨帧最多负载9000字节，其实帧的长度可以远大于9000。

2、TSO： TCP Segmentation
Offload，TCP分段卸载。指的是将TCP分段卸载到网卡来完成，这样本来由CPU处理的分段，现在全部交给网卡来做，减轻了网卡的负担。

3、MSS ：Maximum Segment Size，最大分段大小。指的是TCP层上所能通过的最大数据包大小，即TCP
payload大小，MSS = MTU - 20(IP Header) - 20(TCP Header) - 12(TCP Options)。

4、MTU ：Maximum Transmission
Unit，最大传输单元。指的是链路层上面所能通过的最大数据包大小，即链路层payload的大小。

5、TCP Segment Length ：TCP报文段的长度，TCP payload的实际长度。

正餐

帧长度为什么远大于1500？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ws1sX2DB-1692972557398)(https://image.3001.net/images/20220415/1650028234_62596eca8810bc0eba717.png!small?1650028234686)]

图2是虚拟机eth0网卡的MTU(1500)，图3是查询数据库时的流量，按Length倒叙排列，发现这个数据包的长度已经远大于1500了。

1649946131_62582e134adf3f8b2346d.png!small

图2：mtu=1500

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pTIliykV-1692972557399)(https://image.3001.net/images/20220414/1649946094_62582dee7dfd2cbdd18ce.png!small)]

图3：Length>>1500

我们通过前面的定义介绍了解到：其实 MTU 限制的是链路上最大数据包的大小 。

而在 TCP 协议上，有个 TSO (TCP分段卸载)的概念，这个是由网卡支持的，若网卡支持则说明，当发送大的 TCP 包时，不需要消耗 CPU
来处理分片，而是直接发送给网卡处理。而抓包软件捕获的仅仅是 CPU
处理的数据包，这个阶段在网卡处理之前，所以在捕获数据包的过程中包还没有被网卡分片，自然就不受 MTU 的限制了。

我通过测试多个版本的VMware虚拟机、PVE虚拟机，发现虚拟机默认情况下都是将 TSO 打开的： tcp_segmentation-
offload:on 。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fygsTWOJ-1692972557399)(https://image.3001.net/images/20220414/1649947427_6258332396ebd0057aa09.png!small?1649947427934)]

图4：查看虚拟机TSO的打开情况

那我们有什么办法把 TSO 关闭，实现虚拟机里抓包都小于MTU呢？

其实可以通过禁用TSO： ethtool -K eth0 tso off ，禁用TSO后发现抓的包都“正常了”。

1649947802_6258349a6945d410dc110.png!small?1649947802766

图5：禁用TSO抓包

但是要注意，并不是所有的虚拟机都支持 TSO 的卸载，网卡需要满足3个条件：

1. 首先需要物理网卡支持 TSO 卸载；

2. 其次需要支持使用 ethtool -K eth0 tso on 命令启用TSO；

3.最后需要 TCP checksum offloading 和 Scatter Gather （分散/聚集功能）支持。

为了更好理解3个条件，我们举个栗子:

1、我的宿主机是win10，如图6支持巨帧：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FupluKyZ-1692972557400)(https://image.3001.net/images/20220414/1649948323_625836a31ef5f04194573.png!small?1649948323784)]

图6：win10 默认巨型帧是设置的(默认关闭)

2、并不是所有的虚拟机(修改过内核)都支持通过ethtool命令关闭TSO，如图7：Cannot change tcp-segmentation-
offload。

1649948457_6258372998f11af6c34f0.png!small?1649948457995

图7：不支持ethtool关闭TSO

由于不满足3个条件中的第二条，所以这个虚拟机没法关闭TSO，依然会抓到巨帧包。

snort没解析巨帧包？

snort 的方 git 中有一条关于Jumbo frames的issue：

snort2.9.16 的snort.config中配置了巨帧[config
snaplen:9000]，但是当数据帧大于1500bytes时，snort仍会丢包。官方的解释是：只有snort3支持巨帧包的解析，其余的版本都不支持。

1650030079_625975ff5af5dcbdc6991.png!small?1650030079571

图8：snort官方issue

解析超长巨帧会造成处理单个数据包的时间变长，而 snort2.x
是单线程，当网络带宽变大时，单线程无法及时处理大量的数据包，导致大量丢包和资源的消耗。从官方给的 snort2.x 和 snort3.x
对比中可以知道：snort3.x 在 snort2.x
基础上做了很大的性能提升，支持多个数据包处理线程、tcp传输层协议处理等，snort3.x有能力支持巨帧包的解析。

总结

在虚拟环境下，默认支持TSO，所以会抓到巨帧包。在网卡支持的情况下，可通过卸载TSO，抓到正常的数据包。当然支持解析巨帧，加快了CPU到网卡的处理速度的同时，也增大了单个数据包处理的时延，因此snort2.x
性能还不足以支持巨帧的解析。

参考资料

Snort Jumbo Packets #130

[Snort2 VS
Snort3](https://www.cisco.com/c/en/us/support/docs/security/firepower-
ngfw/217617-comparing-snort-2-and-snort-3-on-firepow.html “Snort2 VS Snort3”)

c/en/us/support/docs/security/firepower-
ngfw/217617-comparing-snort-2-and-snort-3-on-firepow.html “Snort2 VS Snort3”)