虚拟靶场抓到巨帧包!
2022-4-16 17:3:32 Author: www.freebuf.com(查看原文) 阅读量:8 收藏

freeBuf

主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

前言

在自己的虚拟化靶场中抓包,发现 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?

1650028234_62596eca8810bc0eba717.png!small?1650028234686

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

1649946131_62582e134adf3f8b2346d.png!small

图2:mtu=1500

1649946094_62582dee7dfd2cbdd18ce.png!small

图3:Length>>1500

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

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

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

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支持巨帧:

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.freebuf.com/articles/network/329275.html
如有侵权请联系:admin#unsafe.sh