zoukankan      html  css  js  c++  java
  • 由于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

  • 相关阅读:
    poj 1328 Radar Installation (贪心)
    hdu 2037 今年暑假不AC (贪心)
    poj 2965 The Pilots Brothers' refrigerator (dfs)
    poj 1753 Flip Game (dfs)
    hdu 2838 Cow Sorting (树状数组)
    hdu 1058 Humble Numbers (DP)
    hdu 1069 Monkey and Banana (DP)
    hdu 1087 Super Jumping! Jumping! Jumping! (DP)
    必须知道的.NET FrameWork
    使用记事本+CSC编译程序
  • 原文地址:https://www.cnblogs.com/lome/p/4231720.html
Copyright © 2011-2022 走看看