码迷,mamicode.com
首页 > 其他好文 > 详细

由于PADT伪造攻击带来的大面积掉线原因分析

时间:2015-01-18 14:18:55      阅读:261      评论:0      收藏:0      [点我收藏+]

标签:

今天一早接到一个客户电话,说他有一个交换机下面的用户,大面积和上线下线。

由于之有已建议用户在主干换了普通VLAN交换机。所以这次出现问题概率较小,只在一条支路的交换机下面。

下面我对这个情况的发生做一下分析:

PPPoE认证分为两个阶段:

第一阶段:发现阶段

    1.客户端以向FFFF-FFFF-FFFF广播发送PADI数据包寻找AC,即服务端

    2.服务端回复一个PADO单播帧;

    3.农牧民端回复一个PADR单播请求,期望进行会话

    4.服务端回复一个PADS数据包,同意进行下一步协商(包中携带一个sessionid,作为用户的凭证之一)          

第二阶断:会话阶段

    双方使用PPP的LCP协议协商链路,NCP进行用户名密码检验,双方完成通讯。     

    在第一阶段pppoe会话重要依据就是双方的mac地址,在和sessionid  

    在用户下线的时候,用户会发送PADT数据包进行协商,断开会话连接

大家可以想象一下:病毒模拟发包的方式,向服务端发送PADT数据包?服务端以为是客户端请求下线,就会断开客户端,导致客户端掉线,多可怕的事啊。

具体数据包看附图

有人要问了,病毒没有客户端与服务端通讯的seddionid,如何断开?这个问题,我晚点再给大家解释,大家先看图

 

技术分享

 

图上第一段是客户机正常下线的数据图片。

过程是客户端向服务端发送一个PADT,然后服务端收到PADT包,然后再回馈一个PADT包,客户端下线,这个过程服务端只收到一个PADT数据包的。

 

图上第三段是大面积掉线用户的数据图片。

大家仔细看,服务端收到两个PADT包,多了一个PADT?这要如何解释?

原因是病毒模拟客户端向服务端发送PADT,服务端回馈一个PADT,此时按理如果是由客户端自己主动发起的断开,他是不会再回馈一个PADT包的。

可是我们服务端确实是收到了两个PADT,这是因为第一个不是我们的客户端发送的(是病毒发送的),所以客户端以为是服务端主动断开,所以再回复一个PADT,才有上面的2个PADT包。

我仔细看了一下日志,大部分用户都是2个PADT的数据包,印证了这一点。

 

接下去,我向大家解释一下,为什么没有sessionid,病毒为什么能模仿发送数据包

发送PADT起码要知道客户端MAC和sessionid,我在抓包的时候发现:中毒的客户机,一秒钟发起5000多个ARP请求,而且是获取其他客户机MAC地址的ARP数据包。

这说明病毒一直在扫描内网的MAC,这个因为是二层通讯,这人以很简单可以获取的,而且在三层是禁止不了的。

接下去说一下sessionid吧

由于session是0xFFFF,也就是65536,网上有人说,病毒要断开一个客户端,要发送65536个数据包?

其实不然的,病毒没有这么傻吧?断开一个客户端,要这么麻烦,6万多个数据包,也得发送好一会儿。

病毒其实可以模拟一个pppoe认证过程的,自己就会获取一个sessionid,或者根本不需要,因为本身就是pppoe 上网的,直接获取。

大家都清楚,PPPOE的sessionid是累加的,这个看日志就知道了,所以病毒只要往他的MAC地址库里面取出来的地址(这个数量就很少了吧),然后发送session为当前sessionid的数值就可以了

想想,是不是太可怕了?

又有人要问了,这样之前上网的不就没事?确实是,但是你总要下线吧,下线后,你的sessionid就在病毒扫描范围内了,有甚者,全网扫描

有人要问了,这个要怎么防呢?其实这是二层通讯,除非你每个端口用VLAN隔离,才可以完全避免啊,

其实只要增加VLAN交换机使用,8口的才50多一个,以后还会更便宜,出了问题,影响的面积就不会是全网,不但有些用户不受影响,而且也好找

如果有遇到这个问题要咨询详细处理的,可以加我的Q561454825

 

由于PADT伪造攻击带来的大面积掉线原因分析

标签:

原文地址:http://www.cnblogs.com/lome/p/4231720.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!