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

针对随机组播地址的ping攻击案例

作者：易隐者 发布于：2012-9-25 11:22 Tuesday 分类：网络安全

       前段时间，某兄弟在用户处遇到一个问题，说是在无线环境下，生产系统中的条码系统经常卡机，迟迟难以定位，网上找到我，并将报文发给我，让我帮忙看看。
       根据他的描述，一开始我以为是个应用系统故障，准备建议其在生产客户端与服务器端同时抓包做对比分析，后来仔细看起报文时，发现了一个主机针对随机的组播IP地址发送ping请求报文，如下图所示： 

点击查看原图

我们查看其中某个报文的解码： 

点击查看原图

       这个主机的网络交互行为特征大致有以下几点：

1，该主机发送了大量的ping报文，但是正常情况下，生产主机不会发送跟生产业务无关的报文，包括ping报文；
2，ping报文的目的地址都是随机的组播地址；
3，ping组播地址的发包频率虽有变化，但是其发包高峰时可以达到毫秒以内的时间间隔

       结合上述三点，我们可以确定为该主机异常行为。

       主机对多播报文的处理流程决定了网内过多的多播报文会对主机和网络性能带来严重的影响。而目前这个很可能只是大规模爆发之前的预演，发包时间间隔较为随机，有些是几毫秒，有些几十秒，真正爆发时，以该数据包文件来看，这台主机可以做到每秒数万的报文，到时候，估计将会出现全网瘫痪的现象。

       一台机器足以单挑一个的网络了！ 

阅读全文>>

标签: 组播 多播 ping 攻击 行为特征 发包频率 随机组播地址

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

iPhone与Multicast DNS

作者：易隐者 发布于：2012-9-21 20:58 Friday 分类：案例讨论

        前两天看到CSNA论坛上有一个求助帖，原帖连接为：http://www.csna.cn/network-analyst-49133-1-1.html，故障现象大致为：网络经常出现断网情况，抓包发现断网时有大量的DNS包，楼主认为是IPHONE或IPAD在连接公司无线网络时出现的数据包。

       我下载了其数据包文件，并选其中的一个数据包文件进行了大致的分析：
1， 在数据包视图中查看其发包频率，如下图： 

点击查看原图

在1秒的时间内 发送了15542个IPv6的多播报文，这种发包频率，足以影响相关无线路由、交换机等设备的处理性能，而接收方对多播报文的处理流程决定了过多的多播报文对网络和主机的影响，大家可参考本人个人博客中《基于UDP组播实施分片攻击的可能性》一文。

2，我们查看其详细解码： 

点击查看原图

IPV6封装UDP 5353端口的DNS请求行为，经网络搜索相关信息，确认为Multicast DNS（组播DNS）报文；

       经查阅相关资料，苹果系列产品在本地局域网内缺少DNS服务器的环境下，使用Multicast DNS，实现名字和IP地址的解析，每个主机都知道自己的名字，并且会自动响应来自多播报文中针对该名字的请求。 使用Multicast DNS的设备大致工作过程如下：

1，在“.local.”子域下，挑选所需的名字；
2，使用Multicast DNS进行名字查询，看是否有主机已经使用了这个名字；
3，如果收到来自与其他主机的名字解析响应，则在“.local.”子域下重新选择一个名字，直至确认本地局域网内无其他设备使用该名字为止。

       大家可参考苹果支持主页中关于“Multicast DNS”的相关页面：http://support.apple.com/kb/TA20999?viewlocale=en_US；

       这些都明确说明这个报文是iPhone发出的Multicast DNS报文，但是异常之处在于设备发包的频率太快了，而楼主反馈说，“不是每次连接都出现这个问题，只是偶尔会出现”，这也从侧面说明这个异常行为应该是属于iPhone本身跟“Multicast DNS”有关的进程异常导致的，可能是iPhone的BUG亦未可知。

       我在搜索相关信息的时候，竟然找到了一篇跟MAC OS相关的DNS异常问题的帖子，应该属于相关内容了，感兴趣的可以自行查看下面连接：http://blog.sina.com.cn/s/blog_539a3a320100q5dq.html

阅读全文>>

标签: 交换机 分片 解码 故障 UDP 多播 DNS iPhone Multicast DNS 多播DNS 组播DNS IPv6

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

基于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) 浏览(12864)

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