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

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

由于之有已建议用户在主干换了普通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