欢迎关注:1,欢迎关注本博客,你可点击右手边的【QQ邮件订阅】订阅本博客!2,本博客推出江湖救急计划,主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析,如有需要,请在江湖救急计划页面给我留言!

IP分片(IP Fragment)

作者:易隐者 发布于:2012-9-3 22:22 Monday 分类:网络分析

为什么要分片

       不同的链路类型能够支持的最大传输单元值(MTU: Maxitum Transmission Unit)主要是由相关RFC文档规定的,常见的以太网链路的MTU值为1500,如果需要转发的IP报文超出其转发接口的MTU值,则在转发该报文之前,需要将其分片,分为多个适合于该链路类型传输的报文,这些分片报文在到达接收方的时候,由接收方完成重组。

       各种常见链路类型的MTU值如下图所示: 

点击查看原图


报文的分片和重组

       我们先来看一下分片的过程,为了简单起见,我就用《TCPIP详解卷一》第11章《UDP:用户数据报协议》中关于IP分片的案例,应用进程将1473字节应用字段交给UDP处理,UDP加上8字节的UDP报头之后,交给IP层处理,IP层在转发之前,发现该报文长度超出转发接口的MTU,因此需要分片,分为两个IP分组,如下图所示: 

点击查看原图


       从上图可以看出原始的IP报文经过分片后,只有第一个分片报文是带有四层信息的,后续报文均不带四层信息,为做直观展示,我找了一个实际环境下抓取的分片报文,如下图所示: 

点击查看原图

       这是分片的第一个报文,我们可以看到该报文IP层封装的上层协议为ICMP协议,这是一个ping报文(上层协议信息),我们再来看一下后续分片报文的解码:

点击查看原图

       这是分片后续报文,我们能看到封装的是ICMP协议,但是封装的上层协议的具体信息就无法看到了。

       IP数据报被分片之后,所有分片报文的IP报头中的源IP、目的IP、IP标识、上层协议等信息都是一样的(TTL不一定是一样的,因为不同的分片报文可能会经过不同的路由路径达到目的端),不同的地方在于分片标志位和分片偏移量,而接收方正是根据接收到的分片报文的源IP、目的IP、 IP标识、分片标志位、分片偏移量来对接收到的分片报文进行重组

       接收方根据报文的源IP、目的IP、IP标识将接收到的分片报文归为不同原始IP数据报的分片分组;分片标志中的MF位(More Fragment)标识了是否是最后一个分片报文,如果是最后一个分片报文,则根据分片偏移量计算出各个分片报文在原始IP数据报中的位置,重组为分片前的原始IP报文。如果不是最后一个分片报文,则等待最后一个分片报文达到后完成重组。

分片带来的问题

1, 分片带来的性能消耗

       分片和重组会消耗发送方、接收方一定的CPU等资源,如果存在大量的分片报文的话,可能会造成较为严重的资源消耗;
       分片对接收方内存资源的消耗较多,因为接收方要为接收到的每个分片报文分配内存空间,以便于最后一个分片报文到达后完成重组。

2,分片丢包导致的重传问题

       如果某个分片报文在网络传输过程中丢失,那么接收方将无法完成重组,如果应用进程要求重传的话,发送方必须重传所有分片报文而不是仅重传被丢弃的那个分片报文,这种效率低下的重传行为会给端系统和网络资源带来额外的消耗。

3, 分片攻击

       黑客构造的分片报文,但是不向接收方发送最后一个分片报文,导致接收方要为所有的分片报文分配内存空间,可由于最后一个分片报文永远不会达到,接收方的内存得不到及时的释放(接收方会启动一个分片重组的定时器,在一定时间内如果无法完成重组,将向发送方发送ICMP重组超时差错报文,请大家参考本博客《ICMP重组超时》一文),只要这种攻击的分片报文发送的足够多、足够快,很容易占满接收方内存,让接收方无内存资源处理正常的业务,从而达到DOS的攻击效果。

4, 安全隐患

       由于分片只有第一个分片报文具有四层信息而其他分片没有,这给路由器、防火墙等中间设备在做访问控制策略匹配的时候带来了麻烦。
       如果路由器、防火墙等中间设备不对分片报文进行安全策略的匹配检测而直接放行IP分片报文,则有可能给接收方带来安全隐患和威胁,因为黑客可以利用这个特性,绕过路由器、防火墙的安全策略检查对接收方实施攻击;
       如果路由器、防火墙等中间设备对这些分片报文进行重组后在匹配其安全策略,那么又会对这些中间设备的资源带来极大的消耗,特别是在遇到分片攻击的时候,这些中间设备会在第一时间内消耗完其所有内存资源,从而导致全网中断的严重后果。

       基于以上原因,很多应用程序都尽量避免分片的产生,其通过将IP报文的分片标志中的DF位(Don’t Fragment)置一来实现,而这可能给应用带来一些难以预料的麻烦。下一篇我将介绍端系统如何处理这种状况,请大家关注。

分片补充

1,分片既有可能发生在端系统(发送主机)上,也可能发生在转发报文的路由器、防火墙等中间系统上
2,分片只发生在转发出接口上

跟分片有关的案例

        后续我会在本博客里添加一些跟分片有关的案例,有兴趣的同学可关注。

阅读全文>>

标签: ip分片 重组超时 IP标识 icmp差错 分片 ip fragment IPID UDP 分片攻击 分片偏移量 DF位 MF位 MTU 重组 fragment ICMP

评论(6) 引用(0) 浏览(75250)

基于UDP组播实施分片攻击的可能性

作者:易隐者 发布于:2012-8-27 18:36 Monday 分类:网络安全

        UDP是无连接的,这种特性决定了其可以通过组播或广播来进行业务数据的交付,同时我们也知道UDP不会像TCP那样将应用程序交付的大应用字段划分为适合网络传输的数据段(segment),UDP会将大应用字段直接交付于网络层处理,那么在网络层必然会面对分片的问题。

关于应用程序、UDP、IP之间交互的过程,我做了一个图示:

点击查看原图

应用层、UDP以及IP间的交互情况图示

       大的应用字段会被网络层分片后,在网络中传输,这些分片报文会在接收端的网络层重组后,提交给UDP和应用程序。

       我们接下来再来看一下协议栈在各层对数据帧/数据报的过滤过程:

点击查看原图

协议栈在各层对数据帧/数据报的过滤过程图示

       这个是根据《TCP/IP详解卷一》中的第十二章《广播和多播》总结出来的,在此不针对此图做详细描述,有兴趣的兄弟姐妹可以自行参考详解卷一第十二章相关的内容。

       我们接着来看一个实际用户工作环境下抓取的UDP 组播分片报文: 

点击查看原图

用户实际环境中的UDP多播分片报文

         因此,基于UDP组播实施分片攻击的可能性是存在

遭受这种攻击的假设场景:

       用户的某个业务(视频会议、语音、IPTV等)使用组播传输数据报文,黑客只需要构造一些永远无法重组的IP分片报文,以该业务用到的组播地址发送出去,那么所有属于这个多播组的业务主机都将会接收到这些精心构造的攻击报文,那么,可想而知这些多播组内的业务主机在处理的时候,将会出现资源耗尽以至于死机的情况,黑客从而达到拒绝服务的攻击效果。


 

阅读全文>>

标签: UDP 组播 分片攻击 多播 协议栈 拒绝服务攻击

评论(0) 引用(0) 浏览(8227)

Powered by 易隐者 基于emlog 皖ICP备12002343号-1