虚拟靶场抓到巨帧包!
虚拟靶场抓到巨帧包!
前言
在自己的虚拟化靶场中抓包，发现 wireshark 面板中的 Length 远大于 MTU，而明明在抓包网卡的MTU是1500，这是为什么呢？ 将这个包的流量回放到 snort 的接收网卡上，发现 snort 并没有“接收”到这个包，这是为什么呢？
带着这两个为什么，开始接下来的探索吧！
餐前小菜
正餐开始前，必须先知道这些定义，如图1所示：
图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？
图2是虚拟机eth0网卡的MTU(1500)，图3是查询数据库时的流量，按Length倒叙排列，发现这个数据包的长度已经远大于1500了。
图2：mtu=1500
图3：Length>>1500
我们通过前面的定义介绍了解到：其实MTU 限制的是链路上最大数据包的大小。
而在 TCP 协议上，有个 TSO (TCP分段卸载)的概念，这个是由网卡支持的，若网卡支持则说明，当发送大的 TCP 包时，不需要消耗 CPU 来处理分片，而是直接发送给网卡处理。而抓包软件捕获的仅仅是 CPU 处理的数据包，这个阶段在网卡处理之前，所以在捕获数据包的过程中包还没有被网卡分片，自然就不受 MTU 的限制了。
我通过测试多个版本的VMware虚拟机、PVE虚拟机，发现虚拟机默认情况下都是将 TSO 打开的：tcp_segmentation-offload:on。
图4：查看虚拟机TSO的打开情况
那我们有什么办法把 TSO 关闭，实现虚拟机里抓包都小于MTU呢？
其实可以通过禁用TSO：ethtool -K eth0 tso off ，禁用TSO后发现抓的包都“正常了”。
图5：禁用TSO抓包
但是要注意，并不是所有的虚拟机都支持 TSO 的卸载，网卡需要满足3个条件：
1. 首先需要物理网卡支持 TSO 卸载；
2. 其次需要支持使用 ethtool -K eth0 tso on 命令启用TSO；
3.最后需要 TCP checksum offloading 和 Scatter Gather （分散/聚集功能）支持。
为了更好理解3个条件，我们举个栗子:
1、我的宿主机是win10，如图6支持巨帧：
图6：win10 默认巨型帧是设置的(默认关闭)
2、并不是所有的虚拟机(修改过内核)都支持通过ethtool命令关闭TSO，如图7：Cannot change tcp-segmentation-offload。
图7：不支持ethtool关闭TSO
由于不满足3个条件中的第二条，所以这个虚拟机没法关闭TSO，依然会抓到巨帧包。
snort没解析巨帧包？
snort 的方 git 中有一条关于Jumbo frames的issue：
snort2.9.16 的snort.config中配置了巨帧[config snaplen:9000]，但是当数据帧大于1500bytes时，snort仍会丢包。官方的解释是：只有snort3支持巨帧包的解析，其余的版本都不支持。
图8：snort官方issue
解析超长巨帧会造成处理单个数据包的时间变长，而 snort2.x 是单线程，当网络带宽变大时，单线程无法及时处理大量的数据包，导致大量丢包和资源的消耗。从官方给的 snort2.x 和 snort3.x 对比中可以知道：snort3.x 在 snort2.x 基础上做了很大的性能提升，支持多个数据包处理线程、tcp传输层协议处理等，snort3.x有能力支持巨帧包的解析。
总结
在虚拟环境下，默认支持TSO，所以会抓到巨帧包。在网卡支持的情况下，可通过卸载TSO，抓到正常的数据包。当然支持解析巨帧，加快了CPU到网卡的处理速度的同时，也增大了单个数据包处理的时延，因此snort2.x 性能还不足以支持巨帧的解析。